Trying to teach AC IR Remote YBE1FB1F to MOES IR Blaster (UFO-R11/TS1201 via Z2M)

mlemoine · October 18, 2025, 4:08am

Hello everyone,

I’m new to Home Assistant, but by checking tutorials and videos, I’ve been able to setup my HA Green to host Zigbee2MQTT and add my MOES IR Blaster (ZigBee Model: TS1201, Model: MOES UFO-R11).

I know it works fine because I can use it to turn the TV On and Off (Yeah!). So I have at least that going for me!

However, when trying to get it to control my Gree AC, it doesn’t want to do anything.

I’ve been using my YBE1FB1F IR Remote. When switching the IR Blaster to learn code, it does receive a (rather long) base64 IR code. However, when I play it back, nothing happens.

For now, I’ve been mostly trying to get the Off signal to work, I assume once I know how to get one of them to work, I should be able to do the others I need.

My goal is to create a json code file for smart_ir and use that to control my AC. None of the existing files for Gree seem to work and I can find much information on the IR codes for that remote model.

Any additional help would be appreciated. I’ve seen mentions of the device working with ZHA, I suppose my next step will be to try that (I haven’t committed one way or another yet). Although, Z2M looks like the more versatile option from what I’ve read.

I don’t know if talking about other hubs is allowed (I’ll remove this paragraph if it’s not), but I had very similar results with the same IR Blaster on my Hubitat. However, since there aren’t anything resembling smartIR I could find for HE, I decided to give Home Assistant a try and I have to say, it looks good up to now.

ETA:
The remote is most certainly “smart”. It has a screen detailing what states it believes the AC is in. And it most probably sends the whole state it expects the AC to be with each button press. I can see the whole config reset at once if multiple buttons were pushed without reaction for the first ones.

Multiple remotes can control multiple mini-splits without issues, so I would assume the codes are still fairly consistent and it’s not about one remote being tied to a single mini-split or something.

However, each button press is different. For example, here are several “learned codes” from successive press on the On/Off button:
I added a mention whether the remote was going from On to Off or the opposite. I can see no distinctive patterns, so it kinds of looks like the IR code isn’t decoded properly from the signal.

Off -> On
B1ojiRGhAhgCgAMBbgaAA8AP4AcHQB/gBxPgDw/gEyvAG8AHQEPACwM6TqECQA/gKwNAQ0AD4Dc7Abuc4W0XQLdAv0ADQAtAA8AL4TMXQEfgLwPAf0AH4W8XQHvAA8DHQA9AC+FXF8BnQGvgAwPgAxfhBxfgAyfgTwvAf+APB+FXF+AP1wtuBqECGAKhAhgCoQI=

On -> Off
B1sjcBGfAhoCgAMDcwafAsAL4AsH4Bcf4AMz4BMrwBvAB0A3wAsDRU6fAkAP4CsDQENAA+AzO0A/Acmc4W0XQLdAf0ADQAtAA8AL4TMXQEfgLwPAf0A/4W8XQIPAA0CHQANAD0AH4VcXwGdAa+ADA8AXQAfhBxfgAyfgTwtAd0Bb4A8H4VcXQHvgCwMLcwafAhoCnwIaAp8C

Off -> On
B1cjbxGfAhsCgAMBcQaAA8AP4AcHQB/gBxPgDw/gEyvAG8AHQEPACwNNTp8CQA/gKwNAQ0AD4Dc7AaSc4W0XQLdAv0ADQAtAA8AL4TMXQEfgLwPAf0AH4W8XQHvAA8DHQA9AC+FXF8BnQGvgAwPgAxfhBxfgAyfgTwvAf+APB+FXF+AP1wtxBp8CGwKfAhsCnwI=

On -> Off
BzwjgRGjAhYCgAMDcAajAsAL4AsH4Bcf4AMz4BMrwBvAB0A3wAsDN06jAkAP4CsDQENAA+AzO0A/Ab6c4W0XQLdAf0ADQAtAA8AL4TMXQEfgLwPAf0A/4W8XQIPAA0CHQANAD0AH4VcXwGdAa+ADA8AXQAfhBxfgAyfgTwtAd0Bb4A8H4VcXQHvgCwMLcAajAhYCowIWAqMC

Off -> On
B1EjeBGfAhwCgAMBcAaAA8AP4AcHQB/gBxPgDw/gEyvAG8AHQEPACwM3Tp8CQA/gKwNAQ0AD4Dc7AcOc4W0XQLdAv0ADQAtAA8AL4TMXQEfgLwPAf0AH4W8XQHvAA8DHQA9AC+FXF8BnQGvgAwPgAxfhBxfgAyfgTwvAf+APB+FXF+AP1wtwBp8CHAKfAhwCnwI=

On -> Off
B2gjhBGeAhsCgAMDcQaeAsAL4AsH4Bcf4AMz4BMrwBvAB0A3wAsDPU6eAkAP4CsDQENAA+AzO0A/Ab+c4W0XQLdAf0ADQAtAA8AL4TMXQEfgLwPAf0A/4W8XQIPAA0CHQANAD0AH4VcXwGdAa+ADA8AXQAfhBxfgAyfgTwtAd0Bb4A8H4VcXQHvgCwMLcQaeAhsCngIbAp4C

Off -> On
B1YjeBGpAhECgAMBaQaAA8AP4AcHQB/gBxPgDw/gEyvAG8AHQEPACwMvTqkCQA/gKwNAQ0AD4Dc7Acuc4W0XQLdAv0ADQAtAA8AL4TMXQEfgLwPAf0AH4W8XQHvAA8DHQA9AC+FXF8BnQGvgAwPgAxfhBxfgAyfgTwvAf+APB+FXF+AP1wtpBqkCEQKpAhECqQI=

On -> Off
B0ojdBGdAh0CgAMDcwadAsAL4AsH4Bcf4AMz4BMrwBvAB0A3wAsDUU6dAkAP4CsDQENAA+AzO0A/Aaic4W0XQLdAf0ADQAtAA8AL4TMXQEfgLwPAf0A/4W8XQIPAA0CHQANAD0AH4VcXwGdAa+ADA8AXQAfhBxfgAyfgTwtAd0Bb4A8H4VcXQHvgCwMLcwadAh0CnQIdAp0C

dtrott · October 18, 2025, 10:03am

I did a little bit of googling and it looks like the Gree is a “smart” remote.

I have two AC units (an LG and a Midea).

The remote for the LG is dumb.
The remote for the Midea is “smart”.

The dumb remote only has 7 buttons and each button always sends the same code, it was easy to record them and play them back to do useful automations (I use a Broadlink RM3 Mini).

The smart remote works differently, it remembers the complete state it has sent to the AC and has different codes for On and Off.

After trying to analyze the codes I was able to figure out some of the patterns, but I eventually had to give up. The best I could do was record “off” and several preset “on” states, but it wasn’t very useful.

Cutting to the chase, you could try recording the On/Off button twice, i.e.:
Start the recording and press the on/off button.
Then start a new recording and press the button again.

Theoretically one of those will be the “on” and the other will be the “off”.

Try sending each to the AC and see what happens.

Maybe only the off will work.
Maybe both will work but the on will change to a certain temperature.

mlemoine · October 18, 2025, 1:30pm

Thanks for the additional info, I will try that. The remote has a screen which details the state the remote currently “believes” the AC is in (as far as I’ve seen, most AC remotes do that).

I have made sure to record the On/Off button when going from whatever current On mode to Off. But I’ll try recording it twice and see if either does anything.

But the AC usually emits a beep when it receives a code (even one that matches its current config, as far as I can tell), and it does emits any beep with my learned code.

When playing with the dumb TV remote, I’ve also noticed that when learning code different parts of the UI display a slightly different code. Sometimes starting with a B, sometimes not. I’ll have to take a look at that as well.

mlemoine · October 18, 2025, 5:25pm

FYI: I have tried reading the IR code for the on/off button multiple times in a row. I don’t see a repeat of the codes, it looks like every code is always quite different, as if there was a counter or a checksum or something. I can’t even find part of the pattern that repeats.

But the remotes are not uniquely paired with a mini-split, I can use the same remote to control all the mini-splits in the home. So I don’t think this is completely stateful or strongly encrypted.

I’m really thinking the IR receiver might be interpreting the signal wrong, maybe a matter of encoding or frequency. I’m not quite sure what the next step would be though…

mlemoine · October 19, 2025, 3:27am

For the record, I have added to the top post an example of “learned codes” from successive press on the On/Off button. I can see no distinctive patterns, so it kinds of looks like the IR code isn’t decoded properly from the signal.

I’m not quite sure what the next step should be from here… Maybe try with a different IR Blaster? The Broadlink seems to be the device of choice, but they are IP/WiFi based as far as I can tell, and I would very much prefer something ZigBee/Z-Wave (or some other local IoT specific protocol).

mlemoine · October 24, 2025, 3:42am

Ok, I’ve bought a BroadLink RM4 and configured it.
A few things:

I can command my HeatPump from the Broadlink app. This works rather well. Not all commands are supported, but I haven’t dug too much into it. I’m looking for Proof of Concept, not refined solution.
I haven’t been able to make SmartIR work with it yet, but one thing at a time.
I can use the HA Broadlink integration to learn codes (e.g., the Off code) and that works fine too.
I tried to use the Broadlink to teach codes to the MOES (copy-pasting the learned code directly, emitting the code from the Broadlink app, or from the HA integration by sending the learned command), none of these work.

I definitely feel like there must be some configuration for the MOES that I’m not doing correctly. Wrong firmware? Wrong frequency? But I’ll need to dig deeper into that.

Being able to teach the codes to the Broadlink from HA by parroting the command definitely makes me feel that it should be possible to do the same with the MOES. I just need

Examples of the Off codes learned by the Broadlink and the MOES (both learned from the same press of the remote):

"Broadlink": "JgBIAgABIJASFBQSFTYUEhQTFBIUExQTFBITFBM2FRITFBQSFBMUEhUTExMUEhQTFBMUNhMTFBMTExQTFBMTExQ2ExMVNhMTFBIUNhQSFQACgBQSFRMTExQSFBMUEhQUEhQTExQTFBMUEhQTFBIUNhU2ExMTExQTExQTExQTFBIUExQTFBITFBMTFBIVNhQ2EjcTAAUCAAEfkBQSFRMUNRQTFBIUExMUExMUExMTFTUUExQSFBMUEhUTExMUEhQTExMVExM2FBMTExUSFBMTExQSFBMVNRQ2FBIUExU1FBMUAAKAFBMTExQTFBIVEhQTExMUEhUTExMUExMTFBIVExMTExMUExQTFBMTExQSFBMTFBQSFBMUEhQUExMUEhQ2FBIUFBMABQEAAR6RFBMUEhQ2FRITFBMTExMUExQTFBITNxQTExMVEhQTEhQUEhQUExMUExMTFDYUExQSFBMTExUSExQUNRQ2FDYUExQSFDYUEhQAAoEUEhQTFBMUExMTFBIVEhQTFBIUExQSFRMTExQSExQTExUSFBMUEhQTFBMUEhQTEzYUExMUFBIUExMTFDYVEhQ2FAAFAAABH5ETExUSFBMUEhQTExMVEhQTExMUEhQTExQUExMTFBIUExQTFBIUExQSFRMSFBQSFBMUEhUSFBMUNRQTFTQVExQ1FBMUNRUTEwACgBUTExMTFBMTFREVExMTFBIUExUSFBMTExQSFBQTExMTFBMTExUTExMUEhQTFBIVEhQTExMUExQTFBIUNhQSFBMUAA0F",
"MOES": "B1sjehGqAhACgAMDYgaqAsAL4AsH4Bcf4AMz4BMrwBvAB0A3wAsDMk6qAkAP4CsDQENAA+AzO0A/Ac2c4W0XQLdAf0ADQAtAA8AL4TMXQEfgLwPAf0A/4W8XQIPAA0CHQANAD0AH4VcXwGdAa+ADA8AXQAfhBxfgAyfgTwtAd0Bb4A8H4VcXQHvgCwMLYgaqAhACqgIQAqoC"

The difference in length kind of tells me that the MOES doesn’t receive the whole signal. Anyone with an idea on how to convert to something I can send to the MOES, I would definitely appreciate.

I’m opened to any idea or suggestion. I would very much prefer a solution with the MOES than the Broadlink (they’re much less expensive, for one, and I’ll need a few of them).

dtrott · October 25, 2025, 3:38am

I tried analyzing the two codes in your post on Oct 23rd.
I can’t make any sense of the MOES code.

However the “Broadlink” code appears to have similar timing to the NEC ** protocol, however the NEC protocol only sends 4 bytes and that block decodes to 16 bytes (4 chunks of 4 bytes) specifically:

4,4,32,80     0,192,0,224     4,4,32,96     0,0,0,32

Thats about as far as I can go with the analysis without knowing more about the protocol.

** - Google For: NEC Infrared Transmission Protocol

mlemoine · October 25, 2025, 3:42am

Update of the day:

I googled a bit more and found this write up and python tool: broadlink_to_tuya.py · GitHub

Which, purportedly works to convert codes learned by the Broadlink to codes for the MOES. Good news: it works for the TV! Bad news: doesn’t work for the AC

I’ve also tried this tool Convert SmartIR Broadlink commands to Tuya · GitHub, but it didn’t seem to do anything and just re-output the Broadlink code (which obviously doesn’t work).

Also, the converted AC code is too long to use the build-in send command of the MOES, so I had to go through a mqtt.publish action (Moes UFO-r11 error: Message too long?)

I’ve also tried to make the Broadlink learn the code the MOES emits for the TV remote it’s not the same code I initially converted. So it looks like something might be amiss in either the conversion process or the hardware (or IR is just finicky and does have quite a bit of margin). Either way, since the AC commands are much more complex, it looks this might be the reason the codes don’t work.

At this point, I’m starting to wonder if my MOES I’m not simply at a bad spot where the signal from the MOES doesn’t reach the AC…

I’ll see if I can try something else tomorrow.

If anyone want to help, I’m not afraid to do the work (as you can see), but I’d definitely like a bit of guidance…

mlemoine · October 25, 2025, 4:24am

Thanks for your reply.
Yeah, I think the MOES compresses or somehow transforms the signal before sending it.

I’ve actually found Documentation of Tuya's weird compression scheme for IR codes · GitHub which seems to be a quite detailed write up on what MOES/Tuya do with their IR codes.

I want to go back to it to read properly and see what I can get out of it. But I don’t have the time right now.

The remote has the following buttons/options documented:

Power: On/On (1 bit)
Wifi: On/Off (1 bit) [Unsupported by my AC, but the remote doesn’t know that, it has no choice but to send that flag]
Vertical swing: 7 pos (3 bits)
Humidity: Useful only the dehumidify mode, replaces Target Temp by Target Hudimity => 9 pos, 4 bits
Horizontal swing: 7 pos (3 bits)
Timer: Off + up to 24h by .5h increments => so 49 pos (6 bits)
Sleep: 4 pos (2 bits)
Light: On/Off (1 bit)
Fan 8: pos (Quiet, Auto, Turbo + 5 levels) (3 bits)
Mode: 5 pos (3 bits)
Special Modes: 5 pos (3 bits)
Target Temp: 16°C to 30°C by 1°C incr. => so 14 pos (4 bits)
I Feel Mode + temp (I’m not sure about the range but let’s say it’s the same as the target temp) Off + 16°C to 30°C by 1°C incr. => 15 pos (4 bits)

That gives me 3,872,332,800 possible codes, and would require exactly 32 bits with the most efficient packing possible. It could fit in a single chunk of 4 bytes but I doubt they did it that way.

A slightly less efficient packing could still get us down to 34 or 32 bits by combining Power, Modes & Special Modes. And encoding the rest without overlap. Which seems much simpler to handle.

From what I could found, NEC only has the capacity for 8 bits of data. There is a fixed address of 8 bits, and the rest is redundancy, as a form of error detection.

So I don’t the manufacturer could use NEC directly. Too much stuff to send…

dtrott · October 25, 2025, 5:11am

Assuming that the broadlink_to_tuya.py code you previously linked is correct the transformation is just just a multiplication, specifically

Tuya specifies the timing in microseconds.
Broadlink specifies it in “units” of 32.84 microseconds (roughly 269/8192 milliseconds) **

** - I can’t find why/where these numbers originally came from (they are listed in tons of places, but I can’t find the origin).

So the conversion is just:

Base64 Decode the Broadcom
Strip the header.
Multiply the value by 32.84
Compress the byte stream.
Base64 Encode.
Append a new header.