Irremoteesp8266: Haier YR-H10 codes

[nygma2004]

This is the follow-up of my comment left on Issue#404 after it got closed.

I am trying to build a remote for his Haier AC. The remote is YR-H10. I built the hardware and the software about 1 month ago. I have been testing it with my Philips TV and it was working. So I am confident that the IR sending part works (I am driving the LED via a 2N2222 from a Wemos D1 mini).
There is no power supply issue, I checked and the EPS is not rebooting when sending the signal out. I also checked the IR LED with a camera, and I can see it flashing.

I am using 2.3.3 version of the library. When I run the dump software I am getting the following dump for the power off function:
uint16_t rawData[149] = {2952, 3124, 2952, 4500, 524, 1696, 524, 586, 526, 1694, 522, 586, 526, 584, 526, 1692, 526, 586, 526, 1678, 524, 1720, 500, 586, 524, 584, 528, 584, 526, 586, 526, 584, 528, 582, 526, 576, 526, 586, 524, 584, 528, 1696, 522, 1696, 524, 584, 526, 1694, 524, 584, 526, 578, 526, 586, 526, 584, 526, 586, 526, 1694, 526, 1692, 526, 1696, 522, 584, 526, 576, 526, 584, 526, 584, 526, 586, 524, 586, 526, 1694, 524, 1696, 522, 586, 526, 576, 526, 1696, 522, 586, 526, 586, 524, 584, 528, 540, 570, 586, 524, 586, 526, 576, 526, 586, 526, 584, 526, 1696, 524, 584, 526, 584, 526, 584, 526, 584, 526, 576, 526, 586, 526, 584, 528, 584, 526, 586, 524, 584, 528, 584, 526, 586, 526, 578, 524, 586, 526, 586, 526, 1696, 522, 584, 526, 586, 526, 586, 526, 586, 526, 1686, 524}; // HAIER_AC
uint8_t state[9] = {0xA5, 0x80, 0x34, 0x1C, 0x0C, 0x80, 0x20, 0x00, 0x21};

First, I tried simply sending the raw data out:
irsend.sendRaw(rawData, 149, 38);

That did not work. Now I have changed the program to something like this:
IRHaierAC haier_ir(4);
uint8_t off_state[9] = {0xA5, 0x80, 0x34, 0x0B, 0x0C, 0x80, 0x20, 0x00, 0x10};
haier_ir.setRaw(off_state);
haier_ir.send();

Again, there is no response from the head unit. We tried moving the IR led closer in case it was a range issue, but not.

There is one more interesting observation. As I said I first put the code together maybe 1 month ago. When I first read the signal from the YR_H10 remote, I got a different code:
uint16_t rawData[149] = {2952, 3124, 2952, 4496, 526, 1694, 524, 584, 526, 1694, 526, 584, 526, 586, 524, 1694, 524, 586, 526, 1678, 524, 1694, 524, 584, 526, 584, 528, 1694, 524, 586, 526, 584, 526, 586, 526, 578, 526, 584, 526, 584, 526, 1696, 524, 1694, 524, 586, 524, 586, 526, 1694, 524, 1676, 526, 586, 524, 586, 526, 586, 524, 1696, 524, 1696, 524, 586, 524, 584, 526, 576, 526, 586, 526, 584, 528, 584, 526, 586, 526, 1696, 524, 1694, 522, 584, 528, 576, 526, 1696, 522, 1694, 524, 586, 526, 586, 524, 584, 526, 584, 528, 584, 526, 576, 526, 588, 524, 1696, 522, 1696, 524, 586, 524, 584, 526, 586, 526, 586, 526, 576, 528, 584, 528, 584, 526, 588, 522, 588, 524, 584, 526, 586, 524, 586, 526, 578, 526, 1694, 524, 588, 524, 1694, 524, 586, 526, 1694, 524, 1692, 526, 586, 526, 584, 526}; // UNKNOWN B5DD9282
As you can see this was before the recent update, when Haier support was not added. The signal has the same length, but the codes are different from the above which was taken with version 2.3.3.

Unfortunately I am away from this AC (my friend lives in a different city), so debugging will be very slow. I will go and visit them again for Easter, so I would like to go prepared with a few options to test if it is possible.

Thanks a lot guys, this is a great project.

Regards,
Csongor

[crankyoldgit]

Like I said previously, the irsend.sendRaw(rawData, 149, 38); should work, assuming you've got a good capture. (Maybe try a few captures to see if they are different by much). This is the "safest" method. i.e. Least to go wrong .. fingers crossed etc. ;-)

Lets try focusing on getting that (sendRaw) working for you, as that's got the timings for your device. That's should exclude any bugs in the new haier code etc.

Things to check, make sure you've got a "gap" after the sendRaw() command. i.e. a delay of say half a second. e.g. delay(500);. Commands can get confused if they run back to back without a gap.

Try changing the frequency value instead of 38, try 36, 40, & 56. These are other common values for IR modulation frequencies.

If you're seeing the IR pulse(s) via a camera, then the circuit is probably working (I'm assuming the LED is off when it's not sending etc)

Just for simplicity sake, try putting the raw data and settings into the "IRsendDemo.ino" example, remove the non-raw protocols, and try that, and then upload/paste that version here. i.e. Make the simplest version we can to exclude any other issues.

As you're driving the Philips TV with this board & LED, we can fairly safely assume the hardware side is correct.

Now, On the sendHaierAC() side of things, I see values of HAIER_AC_ZERO_SPACE are a bit different to the capture you provided.
e.g. Previous reports which we built the protocol support around had a zero space averaging around 650 microseconds, your capture seems to indicate your remote is producing a zero space around 584 microseconds, so potentially change that value, and try the sendHaierAC() method again.

[nygma2004]

Awesome. Thanks for the insight. I will come back after Easter hopefully with some results.

[crankyoldgit]

Good luck, I'll ping you some time after Easter if I don't hear from you sooner. Happy hunting.

[nygma2004]

I have the remote right now, so I thought I capture a few more samples. I captured two power off samples. I can see that there is a slight difference, but I am assuming this is due to the current time being different in the two instances. Is my assumption correct? Is it possible that when I use the sendRaw it is being rejected by the unit because it has the same timestamp as an earlier code?

First power off sample:

Timestamp : 000019.440
Encoding  : HAIER_AC
Code      : A570260E0CC0600075 (72 bits)
Mesg Desc.: Command: 0 (Off), Mode: 0 (AUTO), Temp: 23C, Fan: 0 (AUTO), Swing: 0 (Off), Sleep: Off, Health: Off, Current Time: 6:14, On Timer: Off, Off Timer: Off
Library   : v2.3.3

Raw Timing[149]:
   +  2954, -  3122,    +  2954, -  4496,    +   528, -  1694,    +   524, -   610, 
   +   502, -  1694,    +   524, -   610,    +   500, -   610,    +   500, -  1692, 
   +   528, -   610,    +   500, -  1676,    +   528, -   610,    +   500, -  1694, 
   +   526, -  1694,    +   526, -  1692,    +   526, -   610,    +   502, -   610, 
   +   500, -   610,    +   500, -   604,    +   500, -   610,    +   500, -   610, 
   +   500, -  1694,    +   526, -   610,    +   502, -   610,    +   500, -  1714, 
   +   554, -  1644,    +   524, -   602,    +   500, -   612,    +   500, -   610, 
   +   500, -   610,    +   502, -   612,    +   500, -  1714,    +   504, -  1694, 
   +   526, -  1694,    +   526, -   604,    +   500, -   610,    +   500, -   610, 
   +   500, -   610,    +   500, -   610,    +   500, -  1694,    +   524, -  1692, 
   +   528, -   608,    +   502, -   602,    +   500, -  1692,    +   526, -  1692, 
   +   528, -   610,    +   500, -   610,    +   502, -   610,    +   500, -   610, 
   +   502, -   610,    +   500, -   602,    +   500, -   610,    +   502, -  1692, 
   +   526, -  1694,    +   524, -   610,    +   500, -   610,    +   500, -   586, 
   +   524, -   610,    +   500, -   602,    +   500, -   610,    +   500, -   610, 
   +   500, -   610,    +   500, -   610,    +   500, -   610,    +   500, -   610, 
   +   500, -   610,    +   502, -   602,    +   500, -   610,    +   500, -  1694, 
   +   526, -  1714,    +   504, -  1694,    +   526, -   610,    +   502, -  1694, 
   +   524, -   610,    +   502, -  1686,    +   526

uint16_t rawData[149] = {2954, 3122,  2954, 4496,  528, 1694,  524, 610,  502, 1694,  524, 610,  500, 610,  500, 1692,  528, 610,  500, 1676,  528, 610,  500, 1694,  526, 1694,  526, 1692,  526, 610,  502, 610,  500, 610,  500, 604,  500, 610,  500, 610,  500, 1694,  526, 610,  502, 610,  500, 1714,  554, 1644,  524, 602,  500, 612,  500, 610,  500, 610,  502, 612,  500, 1714,  504, 1694,  526, 1694,  526, 604,  500, 610,  500, 610,  500, 610,  500, 610,  500, 1694,  524, 1692,  528, 608,  502, 602,  500, 1692,  526, 1692,  528, 610,  500, 610,  502, 610,  500, 610,  502, 610,  500, 602,  500, 610,  502, 1692,  526, 1694,  524, 610,  500, 610,  500, 586,  524, 610,  500, 602,  500, 610,  500, 610,  500, 610,  500, 610,  500, 610,  500, 610,  500, 610,  502, 602,  500, 610,  500, 1694,  526, 1714,  504, 1694,  526, 610,  502, 1694,  524, 610,  502, 1686,  526};  // HAIER_AC
uint8_t state[9] = {0xA5, 0x70, 0x26, 0x0E, 0x0C, 0xC0, 0x60, 0x00, 0x75};

Second power off sample:

Timestamp : 000062.406
Encoding  : HAIER_AC
Code      : A570260F0CC0600076 (72 bits)
Mesg Desc.: Command: 0 (Off), Mode: 0 (AUTO), Temp: 23C, Fan: 0 (AUTO), Swing: 0 (Off), Sleep: Off, Health: Off, Current Time: 6:15, On Timer: Off, Off Timer: Off
Library   : v2.3.3

Raw Timing[149]:
   +  2954, -  3122,    +  2954, -  4496,    +   528, -  1716,    +   504, -   610, 
   +   500, -  1694,    +   524, -   610,    +   500, -   610,    +   500, -  1692, 
   +   526, -   612,    +   500, -  1676,    +   526, -   612,    +   498, -  1694, 
   +   526, -  1714,    +   504, -  1714,    +   504, -   610,    +   502, -   610, 
   +   500, -   610,    +   502, -   602,    +   500, -   610,    +   500, -   610, 
   +   500, -  1694,    +   524, -   610,    +   502, -   610,    +   500, -  1692, 
   +   526, -  1714,    +   504, -   602,    +   500, -   610,    +   502, -   610, 
   +   500, -   612,    +   500, -   610,    +   500, -  1694,    +   524, -  1692, 
   +   526, -  1694,    +   526, -  1698,    +   506, -   608,    +   502, -   608, 
   +   502, -   610,    +   500, -   612,    +   500, -  1694,    +   526, -  1714, 
   +   504, -   610,    +   500, -   602,    +   500, -  1692,    +   526, -  1692, 
   +   526, -   610,    +   502, -   610,    +   500, -   612,    +   498, -   612, 
   +   500, -   610,    +   502, -   602,    +   502, -   610,    +   500, -  1694, 
   +   494, -  1722,    +   526, -   610,    +   500, -   610,    +   502, -   610, 
   +   502, -   610,    +   502, -   604,    +   500, -   610,    +   500, -   610, 
   +   502, -   608,    +   502, -   610,    +   502, -   610,    +   500, -   610, 
   +   500, -   610,    +   500, -   602,    +   502, -   610,    +   500, -  1692, 
   +   526, -  1692,    +   526, -  1692,    +   528, -   610,    +   500, -  1694, 
   +   526, -  1692,    +   526, -   612,    +   500

uint16_t rawData[149] = {2954, 3122,  2954, 4496,  528, 1716,  504, 610,  500, 1694,  524, 610,  500, 610,  500, 1692,  526, 612,  500, 1676,  526, 612,  498, 1694,  526, 1714,  504, 1714,  504, 610,  502, 610,  500, 610,  502, 602,  500, 610,  500, 610,  500, 1694,  524, 610,  502, 610,  500, 1692,  526, 1714,  504, 602,  500, 610,  502, 610,  500, 612,  500, 610,  500, 1694,  524, 1692,  526, 1694,  526, 1698,  506, 608,  502, 608,  502, 610,  500, 612,  500, 1694,  526, 1714,  504, 610,  500, 602,  500, 1692,  526, 1692,  526, 610,  502, 610,  500, 612,  498, 612,  500, 610,  502, 602,  502, 610,  500, 1694,  494, 1722,  526, 610,  500, 610,  502, 610,  502, 610,  502, 604,  500, 610,  500, 610,  502, 608,  502, 610,  502, 610,  500, 610,  500, 610,  500, 602,  502, 610,  500, 1692,  526, 1692,  526, 1692,  528, 610,  500, 1694,  526, 1692,  526, 612,  500};  // HAIER_AC
uint8_t state[9] = {0xA5, 0x70, 0x26, 0x0F, 0x0C, 0xC0, 0x60, 0x00, 0x76};

[nygma2004]

Actually, one more question. I wanted to capture a few modes: e.g. heating at 25C, cooling at 24C and cooling at 22C. I was changing the modes on the remote and moving the temp up and down and notes down the last capture. Looking at the message description I can see that command can be 1 for on, 6 for temp up, 2 for mode, etc.
Is it possible that unit was not turning on because I captured a command 6 temp up which is not being recognized if the unit was off? Maybe first it is always expecting a command 1?
What I meant to say is: should I always capture which is sent when I turn the unit on? E.g. set the mode, temperature, etc. turn it off, and capture the code which is sent when I turn it back on?

[crankyoldgit]

I am far from an expert on these Haier devices, I have never used one. We should probably ask @kuzin2006 about it's operational usage with respect to the protocol messages, as they decoded the remote's messages.

When I wrote the code for the protocol (based solely on info from @kuzin2006) it seemed odd to me, that the entire "desired" state wasn't sent in each message. So, yes, I think it's quite possible you've previously captured a message that didn't actually turn the device on, thus it's silently ignored it. e.g. the "command 6 temp up".

I would strongly recommend capturing/starting with something very basic first, to see if you can get sendRaw() working. e.g. Capture a message which turns the device on, from an already off state is probably a great starting point, if you want to test if the device is seeing the messages etc.
Note: Send that "on" message only when the device is "off" obviously during initial testing.

My _guess_ is, that if you want a reliable message for home automation purposes, you probably want to make every message a "power on and be in this mode/temp/etc" state message, as much as possible. That is, try not to assume what state/mode/temp/etc the aircon is in before the message.

I wish I knew more about the device to be able to help you, but you've got access to all the information I have, plus you've got access to & actually used the device. I don't.

Regarding the "timestamp", I don't think that matters. My _guess_ is the aircon unit accepts what ever time is in the new message as the time it should be using for any timer/sleep functions etc. i.e. Each message probably sets the time for the unit. But, remember, I've never used the device, so take it with a grain of salt. ;-)

[nygma2004]

Thanks, these are good points. I built my sketch around Blynk. The IR sending routing is linked to "virtual pin" in the Blynk sketch which is a button on the screen. I just realized that I assumed that this virtual pin is triggering on status changes, put it is also possible that it is a reoccurring call as long as the button is pressed on the UI (and some delay). So it is also possible that I have been sending out multiple messages without sufficient delay which has caused the unit to to respond to any of them. I will build in some validation on that. :)

[crankyoldgit]

I strongly recommend using the send demo code first, to check we have a "working" message first, then you can eliminate that as a possible problem. By the sound of if, you've got multiple possible problems. Best to simplify if you can when debugging. ;-)

[nygma2004]

Total success. I have used your instruction and managed to solve the issue. I have taken the IRsendDemo and started testing with the power off signal in different frequencies. Nothing seem to have made a difference. Next I started moving very close to the AC unit, and it started working. So it appears that this unit's IR receiver was much, much more sensitive than anything I have seen. The IR led has to be within 2 meters of the unit, directed straight to the receiver window. Now I have updated my Blynk sketch and it works now.
It might have worked even with the earlier version if I had moved very close to the AC unit. My IR led was driven from 3.3V, I have re soldered it directly to the 5V rail without any current limiting resistor (via a 2N2222 transistor). It looks like that the transmission is more stable now, and hopefully still blow up the LED on the long run.

Moral of the story is that never underestimate the IR range and move as close to the unit as possible. If somebody reads this thread in the future, the code works for Haier HR-H10 transmitters as well. I only used the sendRaw method, has not experimented with the Haier specific class.

Do you guy have any tips on enhancing the IR range?

Thanks for all the guidance and structured thinking.

[crankyoldgit]

Glad it's working for you.

Looks like you've done all the obvious things to improve range I can think of, without getting a _better_ IR LED.
I've been over driving mine exactly as you describe (5V across a very cheap generic IR LED, switched by an NPN transistor) for well over a year with daily use. No burnout yet. I get 6+ meters of range out of it at least.

If you want more range, then probably a better IR LED (more efficient, more focused/less wide-angle) might do the job. Or, drive more IR LEDs in parallel. Don't know if that will help with range or not.
That all really boils down to a hardware/circuit design issue, which this library really can't help you with.

[NiKiZe]

Just to connect this issue with original comment https://github.com/crankyoldgit/IRremoteESP8266/issues/404#issuecomment-373918165