Support for Maxwell AC (Probably advanced Mirage support)

[akram]

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]

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.

Can you please elaborate on this with examples/documentation/data etc?

After receiving and replaying payload data, the IRSend command does not trigger any action on the AC side.

Where is the IRSend command you're using? I can't seem to see it in your report. (Not that I know how that bit of Tasmota works, but I can make a good guess)

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

I can confirm that the library does decode the above as a MIRAGE protocol with a code of 0x566F0000201A00000C320B2435125A

Note: The library only has basic support for this (MIRAGE) protocol. That means it can send & receive state codes. Sort of like the number above. It does NOT have detailed support for this protocol yet. i.e. You can't set temperature & modes etc.
If you want that support, you need to do the protocol analysis. e.g. Follow the instructions here: https://github.com/crankyoldgit/IRremoteESP8266/wiki/Adding-support-for-a-new-AC-protocol

You can also read through #1289 & #1291

[akram]

Can you please elaborate on this with examples/documentation/data etc?

Here the example:
My AC is turned ON, temperatutre is 16°C (its minimum value)
I press the temperature Up button (temperature is now 17°C)
I press the temperature Up button (temperature is now 18°C)
I press the temperature Down button (temperature is now 17°C)
I press the temperature Down button (temperature is now 16°C)
I press the temperature Down button (temperature is now 16°C)
I press the temperature Down button (temperature is now 16°C)

Here are the captured data:

16:55:17.725 MQT: tasmota_38B3E6/tele/RESULT = {"IrReceived":{"Protocol":"MIRAGE","Bits":120,"Data":"0x566D0000201A00008C320B163A1064","Repeat":0,"RawData":"+8460-4135+590-555C-1590Ce+620-525C-1595C-550CeCdCeCi+615-1570CeCiCeJ-1565CiCiCiCdCdCdCiCiCdCdCiCdCdCdCdCiCiCiCdCdCiCdCeCdCdCdCeCd+640-1545Ce+585dCdCiCiCiCdCiCiCdJ-530+595iCiCiCdCiCiCiCiCdCiCdCeChCdCdCdCeCdCeCdOdCeChCiCdCeCeJpCeCdCiCdCdCdCeCeJpCeOdCiC-575+565iJlCiCeJkChFgCdOdCdCdCiCeCdCdCdCiCiChJgCdJlCeJpJ","RawDataInfo":[243,243,0]}}
16:55:22.466 MQT: tasmota_38B3E6/tele/RESULT = {"IrReceived":{"Protocol":"MIRAGE","Bits":120,"Data":"0x566E0000201A00008C320B1C3A106B","Repeat":0,"RawData":"+8475-4110+585-560C-1590C-1595C-555+590eHgCeHgHgCf+615-1570CfCg+610jC-1600D-580H-550HgInDgCgCdCdDmCdCdCgCdK-530CgCgCgHgCgCgCgCdCfHgCgHgCfCgHfIjHgCgCgCgHgCgHnDmDcKoCgHmDm+565gCgCgHgHgHnHnHgCfCfIoCgCdI-1565HgHeHgCgCfIqHdCgCfCfHgCfCdCgCgCgHgKoCfCfCfKoKoCmPnMlCgCfCfHeKoCgHgCdHgCgCeHgCdCdCfCfHmHqHdCeHfCgH","RawDataInfo":[243,243,0]}}
16:55:25.964 MQT: tasmota_38B3E6/tele/RESULT = {"IrReceived":{"Protocol":"MIRAGE","Bits":120,"Data":"0x566D0000201A00008C320B203A105F","Repeat":0,"RawData":"+8455-4115+635-535+585-1595Ef+590-555E-1600Eh+560-1620EjEfEhEiG-1590EhEfEiGhEhEhEjG-550GmG-580JhGnJhEjEhGhGhEhGmEhGhEhGhEmGhEfEhGhEh+615-1565EhEfEfGhJnEjEhO-530EjEhGh+610qJnRqEjGhNe+565nJhOmJhRqEhEjGlGlGhEhEhGlGhGfEhEjEfEfJnGhJkEiEjEfGhGhEhEh+605dEhGhJnGhEfEhGhEhJkGhGlR-1570GfGhEjGhEhEhGmEfGhGhOqGfEfEiElEfGjEfEhE","RawDataInfo":[243,243,0]}}
16:55:28.718 MQT: tasmota_38B3E6/tele/RESULT = {"IrReceived":{"Protocol":"MIRAGE","Bits":120,"Data":"0x566C0000201A00008C320B233A1061","Repeat":0,"RawData":"+8455-4140+590-555C-1590+585-1595CdFgF-580C-1570ChH-560JdFgFgCdFgCgC-550CdCdFjFdFdFd+610jJdCdFdFjFdCkCdFdFj+600-545+615-530CdCkFjFgFdFjCkFgJfCeCgFdFdFdOpCdCdFdLpCdCdCdCdFdOpFjFdHjFjFdOkJdCgCgOpFdFdF-1600CjFgFdFjFgM-1580FdLpFqFqJhCeFjChJdCdCgFgChJdCdCgFdFdChFiFdFqF-1620JqHjFdFdCdCdFdFgHjLdJdCgLpCdLpFjFqFgFjF","RawDataInfo":[243,243,0]}}
16:55:31.717 MQT: tasmota_38B3E6/tele/RESULT = {"IrReceived":{"Protocol":"MIRAGE","Bits":120,"Data":"0x566C0000201A00008C320B263A1064","Repeat":0,"RawData":"+8455-4140+590-555C-1590+615-1570+585-560CeC-580I-1595CdHiHdHkHkCdHkH-1620IjIdHdHdHiCdHdCdCdHdHiHdHdCdCdHi+610-530HdIjHdMnCdHkC-550HiCdHkMnHkCeCdHdHdCdHiCdCdCoHiHdHiCdCdHdHdHdCdMnCdHdCoHkCkCdHdCdMgHi+640-1545CdHiJkF-1565CdHdHeHkHdHkHdCdMnCdHdCkHkFnCjIeHdHdHdCeHdHkHkCeHdHiCdM-535HdHdHeCdCdCdHdHdHkHdCoCkHkCdH","RawDataInfo":[243,243,0]}}
16:55:38.467 MQT: tasmota_38B3E6/tele/RESULT = {"IrReceived":{"Protocol":"MIRAGE","Bits":120,"Data":"0x566C0000201A00008C320B2E3A106C","Repeat":0,"RawData":"+8450-4135+590-555+585-1595E-1590CdEgC-550CfEdE-580+560dEg+615-1565Ei+565gCfEdEj+610-530EiJdEjEdJiEdJiEjChEdCdEdEdIjChEjEdEhEdN-1570CdChNoCgCdIfCgEjChChEdCdCdEdCdEdEdEjEdEdEjEdEdCdEdEdJeEdNlCgEjEdEdCgCdEfEjChCfEfCdIjIfEfKoEfEdCdEdEdK-525Ef+605pEgEdCgEdEdEdEgCdIfCgEfIjChEdEdEdEdNpEdCdEdEdEdCgCfCdCgEgNoC","RawDataInfo":[243,243,0]}}

as you can see, for the same state (16°C), pressing 3 times the down button, the remote controller will send 3 differents payloads: 0x566C0000201A00008C320B233A1061, 0x566C0000201A00008C320B263A1064, 0x566C0000201A00008C320B2E3A106C

[crankyoldgit]

Looking at the data, it's fairly clear the temperature is stored in the second byte. i.e. state[1] if was captured by IRrecvDumpV2 etc. e.g. 0x6D = 17deg, 0x6E = 18deg. 0x6C = 16deg.

As for why the other digits are changing, as per the wiki that's why we recommend setting the clock to 00:00 etc. They seem to increase/match in a way the timestamps you recorded them. That is, I'm pretty sure its a clock value, with the time values including seconds.
This is why we recommend recording a lot of values in a spreadsheet to try to see what changes and what values link to what functions or things.

You are the one that has to do the break-down/analysis/reverse-engineering. We can provide assistance & help etc, but most of the leg work requires your effort.

I strongly suggest you follow that wiki link etc and let us know when you got all the bits that change explained.

[akram]

Thank you for your help and support.
Here is a first attempt to capture the data and different states in the following spreadsheet: https://docs.google.com/spreadsheets/d/1Ucu9mOOIIJoWQjUJq_VCvwgV3EwKaRk8K2AuZgccYEk/edit?usp=sharing

I will refine that to break-down the different bytes and states. By reading the Wiki page that you sent, I also understood that the varying bits/bytes are certainly checksum/CRC bits. I put some data into CRC RevEng too with no success for it to guess what is the CRC algorithm being used.

Thanks for your help again, and in the meantime, if you have more advices on how to decode this, as obviously your eye and experience on this in sharper than mine, please feel free to comment.

[crankyoldgit]

Good news, I was about to give up on your checksum value too after I tried a few things, then I got lucky.
The alg. is "Sum every nibble (except the last byte/8bits) and that gives you the last byte/8 bits."

e.g.
0x56730000201600000C000C0301003A is:
0x5 + 0x6 + 0x7 + 0x3 + 0x0 + 0x0 + 0x0 + 0x0 + 0x2 + 0x0 + 0x1 + 0x6 + 0x0 + 0x0 + 0x0 + 0x0 + 0x0 + 0xC + 0x0 + 0x0 + 0x0 + 0xC + 0x0 + 0x3 + 0x0 + 0x1 + 0x0 + 0x0 == 0x3A

I've tried it on a few values, and it works.

Also, state[11] (i.e. 4th last byte) looks like it might be a seconds value. For a large number of the values, it seems to track with the timestamp roughly. Also, I never see it go higher than 0x3B (59 dec) which is what we would expect.

The temp seems to be stored in state[1] (i.e. the 2nd byte) e.g. 0x77 is 27degC That is state[1] - 0x5C gives the temp in Celsius. e.g. 0x6E - 0x5C is 18degC

[crankyoldgit]

@akram How are you going with the analysis? Have you got enough of it worked out to do/explain what you want yet?

[akram]

@crankyoldgit I added "Decode" tab in the stylesheet to add bits or snipple signification findings. Until now I was not able to make the AC respond to this. I will continue this evening.

[crankyoldgit]

Cool. The key factors we need to add/support first are Power on/off control & Operation mode. After that, concentrate on Fan Speed. As we already have Temp figured out, you just need those before we can start on adding the beginnings of Detailed support to the library.

[crankyoldgit]

Looking at the data you've collected, a candidate for the operation mode is the 8th nibble (i.e high nibble of state[4]) i.e. https://docs.google.com/spreadsheets/d/1Ucu9mOOIIJoWQjUJq_VCvwgV3EwKaRk8K2AuZgccYEk/edit#gid=380909393&range=D35:D38

[crankyoldgit]

@akram How goes the analysis?

[akram]

@crankyoldgit I think I am almost done with it.
There is only the DISPLAY (on/off) and SLEEP(on/off) modes for which I cannot really understand the behaviour. Display on/off seem to be linked with sleep on off; but they are in too separated/distant nibbles.

Also, I still have many nibbles which seems to have fixed value to 0 or C.

What could be the next step to test my assumptions? trying to send IrSend based on these findings ?

[crankyoldgit]

Cool. Good work. I'll look at coding up something based on your Decode sheet soon. I'll let you know when it's ready for some testing. I'm sure I'll have questions as I go.

[akram]

awesome @crankyoldgit , I will be waiting for the update and your questions then.

[crankyoldgit]

What are the Model numbers for your Maxwell A/C and it's remote, please?

[akram]

Remote controller has the following model number on the back: KKG9A-C1
And the AC unit has a label with this number: MX-CH18CF

[crankyoldgit]

Thanks for the rapid response.

[akram]

you're welcome. Things get faster with a proper github notification helper.

In MX-CH18CF , the number 18 seems to be the cooling power of 18k BTU, other less powerfull model have 12 and 9. And CF may refer to Chaud - Froid (Hot and Cool in French) as the device can be used to heat the room also.

I have contacted Maxwell a few months ago, and they seem to have discontinued ACs during covid but they may restart in the future.

[crankyoldgit]

Re: https://docs.google.com/spreadsheets/d/1Ucu9mOOIIJoWQjUJq_VCvwgV3EwKaRk8K2AuZgccYEk/edit#gid=380909393&range=J35:J38

Is there an "Auto" mode? Seems unusual to not have one.

[crankyoldgit]

Also, a big piece of critical info that is missing from your spreadsheet. How is power on/off controlled?!?!

Also I don't see anything for quiet either.

[akram]

Hey @crankyoldgit ,
So, there is no Auto mode on this one apparently, unless what I interpret as Recycle icon is the auto mode?

Then, regarding Power on/off . I added some captures, and it seems that Power ON does not have a special value, it is only about sending a valid state based on what I have captured.

However, Power Off seems to be adding 0xBE to byte number 5. Thus the whole state is also sent on poweroff.

[crankyoldgit]

Thanks for the updated info. I might make "Recycle" map to "Auto. I'll think about it.
Thanks for the power stuff, I'll look at it soon.
Please download and test branch: https://github.com/crankyoldgit/IRremoteESP8266/tree/MirageDetailed
It should support some of the things you've worked out (No swing or power yet)

Let me know how it goes.

[crankyoldgit]

I think you need to analyse byte[5] more. It doesn't make sense. You may need to look at the bit patterns.

[akram]

I will add more captures to find out the exact behaviour of byte[5].

Regarding QUIET mode, it seems related to nibble[7] (display, sleep) . But also to Fan mode in nibble[9] (fan).
Thanks for your great work. I need to find out a way now to build the branch you mentionned and then to build a tasmota-ir version using this version.

[akram]

By adding more captures, I still have this pattern between on an off state:

TURN OFF TEMP=16, FAN=HIGH, SWING=SWIPE

0x566C000021D800000C000C2C230161	16	ON	OFF	SWIPE	COOL	OFF	HIGH	OFF
0x566C000033D800000C000C0424015B	16				DRY
0x5674000053C400000C000C26240155	N/A				FAN
0x5674000010D800000C000C3B240159	24				HOT
0x566C000040D800000C000C3425015D	16				RECYCLE

TURN ON TEMP=16, FAN=HIGH, SWING=SWIPE

0x566C0000211A00000C000C36270156	16	ON	OFF	SWIPE	COOL	OFF	HIGH	OFF
0x566C0000331A00000C000C0C28015D	16				DRY
0x56740000530600000C000C2128014A	N/A				FAN
0x56740000101A00000C000C2F280156	24				HOT
0x566C0000401A00000C000C00290150	16				RECYCLE

For the first lines of each table, there is always a difference of 0xBE between D8 and 1A for instance. And same applies for the others.

[dschulte]

Mode heat, 24C, fan speed low

Timestamp : 000012.949
Library   : v2.7.20

Protocol  : MIRAGE
Code      : 0x56740000120040000000000000001D (120 Bits)
Mesg Desc.: Power: On, Mode: 1 (Heat), Temp: 24C, Fan: 2 (Medium), Swing(V): 0 (UNKNOWN), Turbo: Off, Light: Off, Sleep: Off, Clock: 00:00
uint16_t rawData[243] = {8354, 4214,  526, 564,  526, 1634,  528, 1632,  528, 560,  528, 1636,  526, 562,  526, 1636,  526, 560,  528, 560,  526, 562,  528, 1634,  526, 560,  528, 1632,  530, 1634,  526, 1634,  528, 562,  526, 562,  524, 562,  526, 560,  532, 558,  530, 558,  528, 560,  528, 562,  526, 562,  526, 560,  528, 560,  528, 560,  528, 560,  528, 560,  526, 560,  528, 562,  530, 558,  524, 562,  528, 1634,  524, 562,  528, 560,  528, 1634,  528, 560,  528, 562,  528, 560,  526, 562,  526, 562,  526, 560,  526, 560,  528, 560,  526, 562,  526, 562,  524, 562,  526, 562,  526, 560,  526, 562,  528, 560,  526, 560,  526, 564,  524, 1636,  524, 564,  526, 562,  528, 562,  524, 560,  528, 560,  526, 562,  528, 560,  526, 560,  528, 562,  526, 562,  528, 562,  524, 562,  528, 560,  526, 560,  526, 564,  524, 562,  528, 562,  526, 560,  526, 566,  524, 560,  528, 560,  526, 560,  530, 560,  526, 566,  522, 562,  524, 562,  528, 560,  526, 562,  528, 562,  526, 562,  526, 562,  524, 562,  524, 564,  524, 562,  526, 560,  526, 562,  526, 562,  526, 564,  524, 560,  528, 560,  526, 562,  526, 564,  524, 562,  526, 560,  526, 566,  522, 562,  526, 560,  528, 558,  528, 560,  530, 558,  528, 560,  528, 560,  528, 560,  526, 562,  526, 562,  526, 562,  526, 560,  528, 1634,  528, 560,  528, 1634,  526, 1634,  530, 1632,  528, 560,  528, 560,  528, 560,  526};  // MIRAGE
uint8_t state[15]    = {0x56   0, 0x74   1, 0x00   2, 0x00   3, 0x12   4, 0x00   5, 0x40   6, 0x00   7, 0x00   8, 0x00   9, 0x00  10, 0x00  11, 0x00  12, 0x00  13, 0x1D  14};
uint8_t stateBin[15] = {01010110, 01110100, 00000000, 00000000, 00010010, 00000000, 01000000, 00000000, 00000000, 00000000, 00000000, 00000000, 00000000, 00000000, 00011101};

All unknown bits stay at 0. If there are bits in the other model that are always 1, this might be an okayish differentiation. I don't have much knowledge about IR protocols yet. So I don't know if this is a feasible soulution.

UVC is a UV-C light in the unit which should kill bacteria and such things.

[crankyoldgit]

Thanks for that. Unfortunately, we can't use timings it seems to differentiate the protocols. So, it's down to guesses with bits in the state[]. I'll try to work something out.

Re: UVC. We have two common features in the IRac class representation for generic A/Cs. clean & filter.
You've already defined clean in your analysis. Should we use the UVC setting for filter or for clean? Technically this doesn't matter, and I suspect filter is the better choice here, but you're the one with the manual and the device, so I'm letting you make that call. ;-)
Typically clean is the least used option by a typical user. filter is more commonly used day-to-day. e.g. Ion filter/dust filter/mould filter/etc.

[dschulte]

Then probably filter for UVC is suitable as there is also a clean button which obviously should be mapped to clean. UVC is kind of a filter as it filters out bacteria by destroying them.

[crankyoldgit]

Hi, I recently bought a Tronitechnik AC (link)

Is there a model number/code for the device?

[crankyoldgit]

byte 9
00111011: unclear, changes while off timer runs

byte 10
xxx10111: off timer 00001->1h, 10111->24h

byte 11
00111011: unclear, changes while on timer runs

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

[crankyoldgit]

// i feel on 43C (max)
uint8_t state[15] = {0x56 , 0x74 , 0x00 , 0x00 , 0x12 , 0x00 , 0x40 , 0x3F , 0x00 , 0x00 , 0x00 , 0x00 , 0x00 , 0x00 , 0x2F };
uint8_t stateBin[15] = {01010110, 01110100, 00000000, 00000000, 00010010, 00000000, 01000000, 00111111, 00000000, 00000000, 00000000, 00000000, 00000000, 00000000, 00101111};

uint8_t state[15] = {0x56 , 0x74 , 0x00 , 0x00 , 0x12 , 0x00 , 0x40 , 0xBF , 0x00 , 0x00 , 0x00 , 0x00 , 0x00 , 0x00 , 0x37 };
uint8_t stateBin[15] = {01010110, 01110100, 00000000, 00000000, 00010010, 00000000, 01000000, 10111111, 00000000, 00000000, 00000000, 00000000, 00000000, 00000000, 00110111};

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?

[crankyoldgit]

@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]

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]

• 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]

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

[crankyoldgit]

@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]

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]

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

[crankyoldgit]

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

[akram]

@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]

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]

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]

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