Support for Maxwell AC (Probably advanced Mirage support)

akram commented 3 years ago

Version/revision of the library used

IRremoteESP8266 2.7.18 which comes with Tasmota 9.5.0

Describe the bug

I have a Maxwell AC (not a very well known brand) that seems to be using Mirage protocol, however controlling it does not work. After receiving and replaying payload data, the IRSend command does not trigger any action on the AC side.

To Reproduce

Install tasmota 9.5 (uses IRremoteESP8266 uses v2.7.18 ) capture data from the remote controller and replay it. No reaction on the AC side e.g.

15:48:47.093 MQT: tasmota_38B3E6/tele/RESULT = {"IrReceived":{"Protocol":"MIRAGE","Bits":120,"Data":"0x566C000020D800000C320B00320F64","Repeat":0}}
15:48:48.596 MQT: tasmota_38B3E6/tele/RESULT = {"IrReceived":{"Protocol":"MIRAGE","Bits":120,"Data":"0x566C0000201A00000C320B02320F5C","Repeat":0}}
15:48:56.001 MQT: tasmota_38B3E6/tele/RESULT = {"IrReceived":{"Protocol":"MIRAGE","Bits":120,"Data":"0x566C000020D800000C320B09320F6D","Repeat":0}}
15:48:57.746 MQT: tasmota_38B3E6/tele/RESULT = {"IrReceived":{"Protocol":"MIRAGE","Bits":120,"Data":"0x566C0000201A00000C320B0B320F65","Repeat":0}}
15:49:01.191 MQT: tasmota_38B3E6/tele/RESULT = {"IrReceived":{"Protocol":"MIRAGE","Bits":120,"Data":"0x566C000020D800000C320B0E320F72","Repeat":0}}
15:49:19.560 MQT: tasmota_38B3E6/tele/RESULT = {"IrReceived":{"Protocol":"MIRAGE","Bits":120,"Data":"0x566C0000201A00000C320B20320F5C","Repeat":0}}

Example code used

Using tasmota, enable raw mode with:

SetOption58 1
18:53:50.697 MQT: tasmota_38B3E6/tele/RESULT = {"IrReceived":{"Protocol":"MIRAGE","Bits":120,"Data":"0x56700000201A00000C320B1D371256","Repeat":0,"RawData":"+8455-4135+590-570D-1590CeC-550CeCfCeCfCfCfCfCfCeC-1610DeCfCfCfCfCfCfCfC-575DfCfCfCdDfCdDhDfCfCfCfCfCfC-555CeCdDfCdDeCfCgDgDfCfCdDfCfCfCfCfCfCfCfCfCfCfCdDfCfCfCfCfCdDeCeCfCfCfCfCfCeCfCfCeCeCdDfCeCgDfCeCfChDfCdDeCfCeCeCeCfCfCfCgDeCeCfCeCeCfCdDhDeCfCfCgDfCfCfCdDeCeCdDgDf+595gDfC","RawDataInfo":[243,243,0]}}

and replay the received raw data after converting it

18:59:17.896 CMD: IRSend raw 8450,4130,590,575,570,1590,590,1610,570,550,590,1590,590,550,590,1590,590,550,590,1610,570,1590,590,1610,570,1590,590,550,590,1610,570,1590,590,550,590,570,570,550,590,550,590,570,570,550,590,550,590,570,570,570,570,570,570,550,590,550,590,550,590,550,590,570,570,550,590,550,590,570,570,550,590,550,590,570,570,550,590,1590,590,555,590,570,570,570,570,1610,570,550,590,1610,570,1590,590,550,590,570,570,550,590,550,590,570,570,570,570,550,590,550,590,550,590,570,570,570,570,570,570,570,570,575,570,575,570,570,570,555,590,570,570,570,570,550,590,570,570,1615,570,1610,570,550,590,570,570,570,570,570,570,550,590,1610,570,550,590,575,570,1590,590,1610,570,550,590,570,570,1590,590,1610,570,550,590,1590,590,575,565,555,590,550,590,550,590,575,570,570,570,1590,590,570,570,570,570,1590,590,550,590,570,575,1590,590,570,570,1590,590,550,590,1610,570,1610,570,570,570,550,590,570,570,1610,570,555,590,575,565,1590,590,550,590,550,590,550,590,550,590,1610,570,550,590,1610,570,1610,570,575,570,1610,570,570,570
18:59:18.001 MQT: tasmota_38B3E6/stat/RESULT = {"IRSend":"Done"}

Expected behaviour

The AC reacts to the command:

Output of raw data from [IRrecvDumpV2.ino]

I don't have the required hardware to run this thest.

Note: Output from Tasmota is not acceptable. We can't easily use their raw format. arf....I just read this after submitting the bug.

What brand/model IR demodulator are you using?

YFJ IR Bridge (Tuya)

Circuit diagram and hardware used (if applicable)

None

I have followed the steps in the [Troubleshooting Guide]

Yes

Has this library/code previously worked as expected for you?

No

Other useful information

Before upgrading to 2.7.18 , I was using a Tasmota version embedding IRremote that does not support Mirage. At that time, Tasmota was IRReceiving an UNKNOWN protocol with a payload of 122bits. After upgrading, it is now seen as MIRAGE with 120bits payload. During my AC remote captures, I was also seeing sometings for IRreceived with KELON protocol. So, I wonder if the AC is really using MIRAGE and if its protocol is interpreted as is, but that could be a different protocol.

Also, one important thing: same commands and even same state does not have the same data. Some part of the payload is identical accross calls, but, some others always vary whatever the sent state.

crankyoldgit commented 2 years ago

@dschulte I've coded up some stuff to try to support your different model.

Can you please download branch: https://github.com/crankyoldgit/IRremoteESP8266/tree/KKG29AC1 / PR #1660 , test it out, and give me some feedback please?

dschulte commented 2 years ago

Is there a model number/code for the device?

Model number of indoor and outdoor unit is just "Reykir 9000".

FYI, 0b00111011 is 59 (dec). It's most likely the minutes value for the timer(s)

Ahh, that makes sense. I'll investigate.

What is with the two state[]s? And why are they different? It looks like the IFeel bit is set on the latter one, but why not on the first one, when I assume the IFeel but is being pressed?

I should have explained that a bit more. The remote sends both messages on one button press. I'll check if both messages are necessary or if the last message is sufficient.

The branch looks good at first glance. I'll check it thoroughly this evening.

dschulte commented 2 years ago

Power must be switched (11=off, 00=on)
Fan speed low and medium must be switched
Detection of model is not working correctly. What's the reason not using the second bit of byte 8 as you proposed? All bits you are using for differentiation could be 0.
You are checking if byte 10 is set (line 144) which conflicts with the off timer of KKG29A-C1. This (obviously) works for my remote (but not sure if really correct):
```
if (!(prot.raw[8] & (1 << 6)))
return mirage_ac_remote_model_t::KKG29AC1;
else
return mirage_ac_remote_model_t::KKG9AC1;
```
Display (light) is a toggle

dschulte commented 2 years ago

Oh, haven't seen your last commit. Will check...

crankyoldgit commented 2 years ago

@dschulte I've updated the branch again based on some of your feedback. Please download & try again. Re: Byte[8] I did some more research. It is not as clear as I initially thought. Thus model detection has been revised/reworked heavily. There is no simple solution that I could easily see.

dschulte commented 2 years ago

Looks good so far, except the quiet button isn't represented in "Mesg Desc.".

Unfortunately the model detection is still not working correctly. The if-statement for KKG29AC1 is too narrow. Only heat and "recycle" mode will be detected correctly. Other modes like cool with no other settings are detected as KKG9AC1. Might it be feasible to set KKG29AC1 as default? The filter for KKG9AC1 looks relatively specific for me. Checking for minutes and seconds is sufficient except for one second on the full hour and the other part of the statement makes it even more precise. So it is a false detection in less than 1 out of 3600 times. I will have a look into the raw data of the other remote when I have some time to see if I spot something to differentiate. It doesn't really matter for me as I will transmit 99,9% of the time but it would be pleasing to get it fully working.

crankyoldgit commented 2 years ago

Thanks for the feedback. Can you supply those state[]s that confused it so I can put them into a unit test?

crankyoldgit commented 2 years ago

FYI, I've updated the branch based on your feedback. Please try it again and let me know.

akram commented 2 years ago

@dschulte , I am really interested in knowing if you will make your model work. I will not have access to my unit before a few months. But, in the meanwhile, I can buy the components to build a test module; that would be easier than testing with tasmota flashed devices.

dschulte commented 2 years ago

Thanks for the feedback. Can you supply those state[]s that confused it so I can put them into a unit test?

Here one message, which is detected wrong with the old commit. The current commit detects the message correctly.

Mode cool, 22°C, fan speed medium, commit ecc60cc

Timestamp : 001482.109
Library   : v2.7.20

Protocol  : MIRAGE
Code      : 0x567200002300000000000000000019 (120 Bits)
Mesg Desc.: Model: 1 (KKG9AC1), Power: On, Mode: 2 (Cool), Temp: 22C, Fan: 3 (Low), Turbo: Off, Sleep: Off, Light: Off, Swing(V): 0 (Off), Clock: 00:00
uint8_t state[15]    = {0x56   0, 0x72   1, 0x00   2, 0x00   3, 0x23   4, 0x00   5, 0x00   6, 0x00   7, 0x00   8, 0x00   9, 0x00  10, 0x00  11, 0x00  12, 0x00  13, 0x19  14};
uint8_t stateBin[15] = {01010110, 01110010, 00000000, 00000000, 00100011, 00000000, 00000000, 00000000, 00000000, 00000000, 00000000, 00000000, 00000000, 00000000, 00011001};

Mode cool, 22°C, fan speed medium (same as above), commit be51b41

Timestamp : 000112.926
Library   : v2.7.20

Protocol  : MIRAGE
Code      : 0x567200002300000000000000000019 (120 Bits)
Mesg Desc.: Model: 2 (KKG29AC1), Power: On, Mode: 2 (Cool), Temp: 22C, Fan: 3 (Medium), Turbo: Off, Sleep: Off, Quiet: Off, Light: -, Swing(V): Off, Swing(H): Off, Filter: Off, Clean: -, On Timer: Off, Off Timer: Off, IFeel: Off
uint8_t state[15]    = {0x56   0, 0x72   1, 0x00   2, 0x00   3, 0x23   4, 0x00   5, 0x00   6, 0x00   7, 0x00   8, 0x00   9, 0x00  10, 0x00  11, 0x00  12, 0x00  13, 0x19  14};
uint8_t stateBin[15] = {01010110, 01110010, 00000000, 00000000, 00100011, 00000000, 00000000, 00000000, 00000000, 00000000, 00000000, 00000000, 00000000, 00000000, 00011001};

@dschulte , I am really interested in knowing if you will make your model work. I will not have access to my unit before a few months. But, in the meanwhile, I can buy the components to build a test module; that would be easier than testing with tasmota flashed devices.

For my use case the implementation is probably fully functional already as I will send only where I can select the correct model. So now it is just to get everything to a 100% working state.

@crankyoldgit I think we got it. Thanks a lot for your help and this awesome work! I will assemble a transmitting circuit in the next days and will give feedback. But I don't expect any problems there...

crankyoldgit commented 2 years ago

Here one message, which is detected wrong with the old commit. The current commit detects the message correctly.

Thanks. I've added it as a test case, so if we change model detection in the future we will know if we broke it.

@crankyoldgit I think we got it. Thanks a lot for your help and this awesome work! I will assemble a transmitting circuit in the next days and will give feedback. But I don't expect any problems there...

Famous last words. ;-) Please let us know when you've tested it, as once you've confirmed it's working, I'll merge it into the rest of the library proper. Hopefully in time for the next version release.

crankyoldgit commented 2 years ago

FYI, the changes mentioned above have now been included in the new v2.8.0 release of the library.

crankyoldgit / IRremoteESP8266