Issue with controlling Western OM air conditioner using ESP32-S3 and MicroPython IR transmitter

[poya-kob]

Hello everyone,

I’m trying to build an IR remote controller for my air conditioner using MicroPython on an ESP32-S3-WROOM-1.
I tested the code with my TV and it worked fine, but when I try the exact same process with my air conditioner, it doesn’t respond at all.

Here’s what I did:

First, I captured the IR code from the AC’s remote.

Then I replayed the captured signal using the ESP32.

I used a 2N2222 transistor with a 5V power supply for the IR LED.

I also tried both an IR transmitter module and a simple IR diode.

From my phone’s IR blaster (tested via an app), the AC worked — it matched with Westinghouse brand and responded correctly.

With the ESP32 setup, however, the AC did not respond. The only thing I could achieve was turning it off, but turning it on is what I really need.

Question:
Why would the ESP32 IR transmitter work with my TV but not with the AC? Is there something different about AC IR protocols (like Western OM / Westinghouse) that I’m missing? Any suggestions or troubleshooting tips would be appreciated.

[ned-pcs]

From what I've read, AC units often use very long code sequences. Are you sure that you're capturing the whole thing?

[poya-kob]

Yes, I used the micropython_ir/ir_rx/acquire.py script to capture the signal, and I increased the edges value to 300.
Here is a sample of the captured signal:

Waiting for IR data...
000 3014
001 1564
002 446
003 1128
004 449
005 1127
...
195 393

Unsupported protocol. Panasonic?

[peterhinch]

Please note the caveats about micropython_ir/ir_rx/acquire.py. The utility is really only suitable for short, simple bursts.

[Josverl]

I agree with Ned:
Your TV works because TV protocols are short, simple, and tolerant.
Air‑conditioner (AC) remotes almost always use long, stateful, multi‑frame protocols with strict timing, required carrier frequency, full “state” encoding (mode, temp, fan, swing, power), and a checksum.

Replaying a naïvely “captured” raw signal (especially from a demodulated IR receiver) often drops bytes, distorts timing, omits repeats, or uses the wrong carrier/duty cycle. You likely sent only an OFF frame successfully (often a simpler or more tolerant code), while ON requires the complete valid state frame (and sometimes 2 identical frames, or a frame + its bitwise complement).

[poya-kob]

Hi, and thank you so much for your incredibly insightful answer. This explains exactly the problem we've been facing for days.
​I'm trying to control a specific Air Conditioner unit with an ESP32 and MicroPython. We've hit the exact wall you described: we can control a simple TV, but the AC unit fails, except for one time when it successfully turned OFF.
​Here are the clues we have gathered so far:
​The AC Brand: The unit is branded "Western OM", but the display panel has the model number GBKJ-KFRD36GY.
​The "Working" Remote App: We discovered that a "Westinghouse" remote profile in a smartphone IR app can successfully control the AC.
​Partial Success with a Library: Using a MicroPython IR library, the AC unit responded only once to a command generated by the KELVINATOR protocol (it turned the unit OFF, but never ON again).
​Raw Signal Captures: We have successfully captured multiple raw signals (the mark/space timings in microseconds) for different states (ON at 16°C, OFF, temp down, etc.) from both the original remote and the successful smartphone app. The signals are very long (often 200+ pulses).
​My Question is:
Based on these clues (especially the Westinghouse/Kelvinator connection and the panel model), do you have any idea what specific protocol this might be a variant of? Is there a known checksum algorithm for this family of ACs?
​I am now following the path of reverse-engineering the protocol by analyzing the raw captures, exactly as you and others have suggested. Any specific advice on what to look for in these long, stateful AC signals would be immensely helpful.
​Thank you again for your help!

[Josverl]

No, I have no personal experience with this.

I have asked copilot to find materials, including links to information sources so you (and myself) can check, read and learn.
It also generated fully untested code that you can use for inspiration, and it even generated some MicroPython code, that supposedly could read the pulses using the esp32.RMT.

However it blissfully overlooked this note in the docs :

The current MicroPython RMT implementation lacks some features, most notably receiving pulses. RMT should be considered a beta feature and the interface may change in the future.

It's in a GIST in case you want to read.
https://gist.github.com/Josverl/d544cbaba33f29b6659b2cf185bd5039

You can do the same , but as shown above , do not trust blindly