An ESP32 can turn a conventional infrared air conditioner into a temperature-driven controller without modifying the AC itself. The basic signal path is simple: a room-temperature sensor feeds the ESP32, the firmware decides whether cooling is required, and an IR LED transmits the same kind of frame the handheld remote would send.
The difficult part is not producing infrared light. It is keeping the control loop stable while working with an appliance whose IR protocol may encode the remote’s complete state in every transmission.
A robust design therefore needs three boundaries: a temperature band that prevents rapid decision changes, a minimum interval between control actions, and a local AC state model that always produces a coherent IR frame.
A single threshold creates command chatter
Consider the simplest rule:
if temperature >= 28 C:
send AC ON
else:
send AC OFFA real sensor does not remain at one exact value. Airflow, sensor resolution, placement, and normal room fluctuations can make readings move repeatedly across 28 °C:
27.9 -> OFF
28.1 -> ON
27.8 -> OFF
28.0 -> ONThis is undesirable even if the AC has its own internal protections. The ESP32 keeps transmitting contradictory commands, the indoor unit may beep or change state repeatedly, and the controller becomes sensitive to measurement noise instead of actual room conditions.
Hysteresis separates the threshold that requests cooling from the threshold that releases it.
For example:
temperature >= 30 C -> request cooling
temperature <= 26 C -> release cooling
26 C < temperature < 30 C -> keep previous stateThe controller now has memory. A reading of 28 °C does not determine the output by itself; the previous cooling state also matters.
A compact state transition looks like this:
if cooling == false and temperature >= 30:
cooling = true
if cooling == true and temperature <= 26:
cooling = falseThis dead band prevents small oscillations near one threshold from producing a stream of IR commands.
Temperature sampling and IR transmission are different time scales
A room sensor can be sampled more often than the AC needs a new command. Those two activities should not be coupled so that every valid reading produces an IR frame.
The firmware can sample periodically, filter or validate the reading, update the desired control state, and transmit only when the desired AC state actually changes.
The structure is closer to:
sample sensor
|
v
validate reading
|
v
apply hysteresis
|
v
did desired AC state change?
| |
no yes
| |
v v
do nothing check command interval
|
v
send IR stateA minimum command interval adds another guard. It prevents a bad sensor, a reboot loop, or an application bug from flooding the receiver with frames.
That interval is a controller policy, not a replacement for the AC manufacturer’s operating protections. The ESP32 is still issuing remote-control requests; the appliance remains responsible for its own compressor, fan, and refrigeration control.
AC infrared messages are often stateful
Television remotes commonly expose commands that behave like individual button events. Air-conditioner remotes are often different. Many AC protocols transmit a representation of the remote’s current state, including fields such as power, operating mode, target temperature, fan speed, swing settings, and checksums.
That changes the firmware model.
Suppose the ESP32 intends to change only the target temperature from 24 °C to 25 °C. A protocol-specific library may still need to transmit a complete state resembling:
power = on
mode = cool
temperature = 25
fan = auto
swing = offSending a captured raw frame for “25 °C” without tracking the rest of the intended state can accidentally restore other settings embedded in that capture.
Libraries such as IRremoteESP8266 provide protocol-specific AC classes and a generic AC state abstraction for supported protocols. The protocol must still match the actual remote and indoor unit; there is no universal frame that works across all brands and models.
Local state can diverge from the physical AC
Infrared control is normally one-way. After the ESP32 transmits a frame, it does not automatically receive an acknowledgement from the AC.
That creates an important failure mode:
ESP32 believes: AC = ON, COOL, 24 C
physical AC: OFFSeveral events can produce this mismatch:
- the IR LED was not aimed correctly;
- an object blocked the signal;
- the ESP32 rebooted and lost its previous state;
- someone used the original handheld remote;
- the transmitted protocol or model variant was wrong.
The automation should therefore treat its AC state as an intended state, not indisputable feedback from the appliance.
If the system must coexist with the original remote, adding an IR receiver can improve synchronization by observing compatible remote traffic and updating the ESP32’s local model. This still depends on the protocol being decodable and on the receiver seeing the transmission.
Another option is periodic state reassertion, but it should be used deliberately. Repeated transmission can restore the intended configuration after a missed frame, yet it can also overwrite a manual change made by a person.
Sensor placement can dominate controller behavior
The sensor should represent room air, not the ESP32 board temperature or a narrow stream of cold air from the indoor unit.
A sensor placed directly in the AC outlet path can report a rapid temperature drop while the rest of the room remains warm. The controller may release cooling too early, then request it again after the local cold plume disappears.
Placement near a warm power regulator, enclosure wall, window, or direct sunlight can bias the opposite direction.
The control band must be selected together with sensor placement and room thermal behavior. A four-degree hysteresis band may be acceptable in one installation and unnecessarily wide in another. The important property is that the two thresholds are separated far enough that normal short-term measurement variation does not constantly change the requested state.
Filtering can help with noisy measurements, but filtering and hysteresis solve different problems. Filtering reduces short-term variation in the input; hysteresis prevents output state changes until a different boundary is crossed.
The IR LED output stage needs electrical margin
An IR LED is a current-driven load. The ESP32 GPIO should provide the logic signal, while the LED current should be set by a suitable driver stage and current-limiting resistor when the required transmit current is beyond what should be sourced directly from the GPIO.
A typical arrangement is:
ESP32 GPIO
|
v
transistor or MOSFET driver
|
v
IR LED + current limiting resistor
|
v
power rail / groundThe exact resistor, transistor, supply voltage, and pulse current depend on the selected IR LED and driver circuit. Those values should come from component electrical limits rather than a copied schematic with unknown parts.
The optical path matters as much as the electrical path. The indoor unit’s IR receiver must see enough modulated infrared energy at the expected carrier and timing. A circuit that works from 20 cm on a breadboard may not have enough margin across a room.
A controller should separate sensing, policy, and protocol encoding
The firmware becomes easier to reason about when three concerns remain separate:
temperature sensing
|
v
control policy
(hysteresis + timing)
|
v
desired AC state
|
v
protocol encoder
|
v
IR transmitterThe sensing layer produces a validated temperature. The policy decides whether cooling is requested. The AC state layer converts that decision into power, mode, temperature, fan, and other settings. Only the protocol layer turns those settings into the brand-specific infrared waveform.
This separation prevents a sensor threshold from becoming entangled with Panasonic-, Daikin-, LG-, Samsung-, or other protocol-specific code. It also makes it possible to replace the sensor or change the hysteresis band without rewriting the IR encoder.
The resulting control rule is small, but its boundaries are explicit: temperature changes do not automatically mean IR transmissions, an IR transmission represents a coherent AC state, and the ESP32’s state is only the controller’s current belief unless feedback confirms the appliance state.
That distinction is what turns a temperature-triggered remote into a stable embedded control system rather than a GPIO that repeatedly replays infrared commands.