Github Devices Community Docs Blog

Problems with controlling Haier AC using OpenMqttGateway

psss, :expressionless: I need to dig this again.

I’m really sorry for all the trouble :frowning:

Can I help so I’m not just sitting, feeling like a dick while you do all the debugging?

No problem, it helps building a better gateway :wink:

I need to take a look again and I will say you, thanks for proposing !

Hello,

@minims found the issue; it is now corrected in the dev branch:

Crap. I was certain I replied on mobile, but it didn’t post the message :frowning_face:

Ok, tried the dev branch and damn, when I publish
{"hex":"0xA6BCF20040600020000000000519","bits":14,"protocol_name":"HAIER_AC_YRW02"}
AC finally reacts!

Now. I am still unable to receive IR signals.
First thing I did is to set
kRawBuf = 300 in IRrecv.h
even if you said this should not be necessary anymore. First success:


As before, I am not getting raw value because of the size.

So I changed:
#define JSON_MSG_BUFFER 512
by
#define JSON_MSG_BUFFER 1280
and
mqtt_max_packet_size=1024
by
mqtt_max_packet_size=1280
That did the trick.

ps. Commit c9de14e broke version number again :wink:
firefox_73gKiiUx2N
Or maybe that is intentional :thinking:

GREATTT!

Thanks for the tip!

Yes it is, version number is set when building a release.

I still don’t understand why I need those since you’ve said they shouldn’t be required :thinking:

After posting I figured it’s probably build variable :slight_smile: We do the same, increment/change version number during build process.

Now I just need to hard powercycle my AC because when I mess up to much with the IR codes (like sending value not hex which I did) it stops making the beeps :smiley:

Next step is to figure out how to make it work with Home Assistant and SmartIR :+1:

@1technophile problem is back for Sony IR on current dev branch, any idea ?

Edit : problem is in this commit : https://github.com/1technophile/OpenMQTTGateway/commit/3bee160b4841ddf17aad7df11e069cda97a2ed4b

Issue is on ZgatewayIR.ino between line 331 and 336. I don’t know how to fix. if I remove the Sony 20 bits if to keep the one for 12 bits, it works.

I sticked with the default parameters of IRRemoteESP8266
but maybe that’s not a good approach.
Alternatively you can add a “bits” key into you json with 12 as value.

But in all the case it is strange, before releasing I did the test between my 2 IR gateways;
GTW1 sending:
home/OpenMQTTGateway/commands/MQTTtoIR -m '{"hex":"0x490","protocol_name":"SONY","repeat":3}'

GTW2 receiving:
{"value":1168,"protocol":4,"bits":20,"hex":"0x490","protocol_name":"SONY","raw":"2428,588,630,578,628,578,628,574,630,576,628,574,632,574,630,574,628,576,630,574,1230,572,630,576,628,578,1230,574,628,580,626,574,1230,576,630,576,626,576,628,576,630"}

From the look at the code and commit @Minims posted, you need to specify bits explicitly if it’s not 20. Otherwise it will set it to default 20 and will not set it to 12 or am I not reading the code right?

You are reading it right !

Yes, it is the current behavior. So I have try to specify bits:12 and it works.
I think it can be added in the breaking change as you need to update payload to make it work again. :grinning:

My vote would be not to. Instead I would make this change:

    if (valueBITS == 0)
      valueBITS = SONY_12_BITS;
    irsend.sendSony(data, valueBITS, valueRPT);
#    else
    if (valueBITS == 0)
      valueBITS = SONY_20_BITS;

With this 12 bit payload handling will remain unchanged (will not have to be explicitly specified) and addition of 20 bit payload will be something you need to set with "bits" = 20. What you think @1technophile?

edit. small rephrasing to be more clear…

Now that I think about it, I would remove the whole 20 bits block. I don’t think it makes sense since it will never be hit, right?

It could be useful to remove it for the base SONY protocol if other users confirm that SONY protocol is always 12 bits. In this case I will also propose a PR into IRRemoteESP8266 repository.

I’m not saying to remove it from being able to handle 20 bits. I just mean that those logic statements are wrong in a way that the second one will never be hit, because if valueBITS is 0, it will be set to 20 (in the current code) and the second if statement will be always false.

So there are two things wrong there, we changed what is the default for Sony protocol (from 12 to 20 by doing a check for 20 first) and we make an if statement that will never trigger. That was my point, not like removing it from IRRemoteESP8266 repo.

The second ones is hit when you are not on ESP32/ESP8266 platform, there is a
# if defined(ESP8266) || defined(ESP32)
above.
When we are on arduino we use a different library for IR with a default value of 12 bits.

Ah, so yes, makes sense. Didn’t know that.

Supporting several boards makes the code a little bit harder to read :slight_smile: