Samsung AC - send "clean" on power off

[bogd]

Describe the bug

"Clean" flag should be honored and sent during power off - right now, the code only sends a "standard" power off message, and ignores anything else when powering off the unit.

For my type of unit, "clean" simply means that it keeps the fan running for about 15 minutes after power off, to dry the inside of the system. As far as I can tell, this flag is sent by the original remote as part of the "off" sequence (this might be wrong - I am attaching captures from the original remote below, if it would help troubleshooting).

To Reproduce

Originally discovered this while troubleshooting a different issue with Tasmota ( see here ).

Example code used

Include all relevant code snippets or links to the actual code files. Tip: How to quote your code so it is still readable in the report.

Expected behaviour

The "clean" flag should be sent as part of the power off sequence - however, as far as I can tell, it is not.

Output of raw data from [IRrecvDumpV2.ino]

Sequence from the original remote :

[ Powered on unit, 26 degrees C, cool mode ]

Protocol : UNKNOWN
Code : 0x8165DDF8 (178 Bits)
uint16_t rawData[355] = {70, 49496, 74, 3862, 70, 29350, 614, 16654, 3000, 8900, 530, 462, 530, 1454, 530, 464, 526, 464, 528, 464, 526, 466, 500, 512, 504, 488, 458, 532, 488, 1494, 496, 498, 524, 466, 526, 1454, 530, 462, 504, 486, 532, 1450, 532, 1454, 530, 1452, 504, 1480, 502, 1504, 504, 488, 458, 532, 460, 530, 490, 502, 494, 496, 498, 492, 502, 490, 530, 460, 504, 488, 504, 486, 532, 460, 528, 464, 528, 462, 528, 464, 528, 466, 524, 466, 526, 464, 526, 488, 502, 490, 434, 556, 486, 506, 462, 528, 492, 498, 496, 494, 528, 464, 528, 462, 528, 464, 530, 460, 528, 462, 530, 462, 528, 464, 528, 466, 528, 1454, 528, 1454, 528, 1478, 436, 1546, 532, 2928, 3000, 8924, 498, 1486, 534, 458, 532, 460, 530, 460, 530, 460, 532, 460, 530, 460, 530, 462, 530, 462, 528, 1452, 530, 464, 528, 486, 502, 1478, 460, 530, 488, 1494, 496, 1486, 530, 1452, 532, 1452, 530, 1452, 532, 1450, 530, 464, 528, 464, 524, 466, 526, 466, 526, 486, 506, 484, 502, 488, 460, 532, 486, 504, 490, 502, 496, 496, 524, 466, 530, 460, 530, 462, 530, 460, 532, 458, 530, 462, 532, 460, 530, 464, 528, 462, 528, 464, 526, 466, 528, 486, 504, 488, 460, 530, 460, 532, 462, 530, 490, 500, 498, 494, 528, 462, 530, 460, 530, 460, 528, 464, 502, 488, 530, 460, 502, 490, 530, 2952, 2998, 8904, 500, 1482, 530, 466, 526, 486, 502, 490, 458, 532, 484, 508, 462, 528, 520, 470, 524, 466, 530, 1452, 530, 462, 502, 488, 530, 1452, 530, 462, 526, 1458, 528, 1454, 526, 468, 526, 1478, 502, 1482, 486, 1496, 492, 1492, 526, 1458, 532, 1450, 532, 1452, 530, 1454, 530, 464, 524, 466, 526, 464, 524, 1458, 526, 1480, 462, 1520, 462, 530, 462, 528, 492, 500, 522, 468, 500, 490, 526, 464, 528, 1454, 526, 466, 528, 1454, 528, 1456, 500, 496, 496, 492, 522, 470, 520, 1484, 458, 532, 460, 532, 462, 530, 492, 500, 494, 496, 528, 464, 528, 462, 500, 1482, 526, 1456, 526, 1458, 526, 1458, 484}; // UNKNOWN 8165DDF8

[ Pressed the "clean" button to activate the feature ]

Timestamp : 000160.168
Library : v2.7.18

Protocol : UNKNOWN
Code : 0x9EBC58F0 (118 Bits)
uint16_t rawData[235] = {68, 28018, 612, 17422, 3026, 8898, 496, 494, 528, 1454, 532, 460, 530, 462, 528, 462, 532, 462, 528, 460, 530, 462, 526, 466, 526, 1454, 528, 468, 524, 488, 504, 1476, 460, 532, 488, 500, 494, 1488, 528, 1454, 506, 1476, 530, 1454, 532, 1452, 530, 462, 528, 464, 526, 464, 528, 464, 526, 466, 526, 486, 502, 490, 458, 532, 486, 504, 488, 502, 492, 498, 522, 470, 530, 396, 534, 452, 598, 460, 532, 356, 632, 462, 530, 460, 530, 462, 530, 462, 526, 466, 528, 464, 526, 466, 500, 514, 504, 488, 458, 532, 486, 504, 488, 504, 490, 500, 522, 468, 530, 460, 532, 462, 528, 1450, 534, 1448, 532, 1450, 528, 1456, 484, 2996, 2932, 8970, 500, 1506, 504, 488, 458, 532, 486, 506, 490, 502, 496, 494, 526, 466, 532, 460, 532, 460, 532, 1450, 532, 460, 530, 462, 530, 1454, 528, 1454, 528, 464, 528, 1476, 504, 490, 458, 1524, 486, 1496, 496, 1486, 530, 1452, 532, 1456, 526, 1452, 530, 1452, 532, 1452, 530, 464, 500, 490, 526, 466, 526, 1478, 460, 1522, 462, 1520, 494, 1488, 502, 490, 530, 1452, 532, 460, 530, 460, 530, 462, 530, 1454, 528, 464, 530, 1454, 528, 1478, 506, 488, 502, 488, 460, 532, 462, 1520, 494, 498, 524, 468, 530, 462, 502, 488, 530, 462, 530, 460, 528, 462, 676, 1306, 530, 1454, 528, 1456, 528, 1478, 524}; // UNKNOWN 9EBC58F0

[ Powered off unit with "clean" mode on ]

Timestamp : 000161.382
Library : v2.7.18

Protocol : UNKNOWN
Code : 0x4F9DA954 (183 Bits)
uint16_t rawData[365] = {68, 334, 610, 17784, 2958, 8946, 528, 488, 504, 1476, 486, 506, 490, 502, 496, 496, 524, 468, 530, 460, 530, 462, 528, 460, 532, 1450, 530, 462, 530, 462, 530, 1452, 530, 1452, 528, 466, 524, 1478, 438, 1546, 488, 1496, 494, 1488, 506, 1478, 504, 488, 530, 460, 528, 462, 530, 460, 532, 462, 528, 464, 526, 466, 528, 464, 524, 466, 500, 492, 524, 488, 502, 490, 458, 532, 488, 504, 488, 502, 524, 468, 500, 490, 530, 462, 528, 462, 532, 460, 528, 460, 530, 462, 528, 462, 530, 462, 528, 464, 526, 464, 526, 464, 528, 466, 526, 488, 460, 530, 460, 530, 462, 530, 488, 502, 524, 468, 526, 1456, 532, 1450, 528, 2954, 3000, 4432, 66, 4402, 530, 1454, 528, 466, 524, 466, 526, 464, 526, 466, 498, 494, 524, 488, 502, 488, 460, 530, 460, 1520, 496, 496, 498, 494, 530, 1452, 530, 462, 526, 1456, 528, 1456, 530, 1454, 500, 1482, 524, 1458, 524, 1480, 460, 532, 460, 530, 486, 506, 492, 500, 494, 498, 526, 466, 526, 466, 526, 464, 526, 464, 526, 466, 528, 464, 528, 464, 526, 466, 522, 470, 524, 466, 524, 468, 524, 490, 472, 518, 458, 532, 462, 530, 486, 504, 490, 502, 492, 498, 498, 492, 526, 464, 526, 464, 526, 466, 526, 464, 500, 490, 526, 466, 522, 470, 524, 466, 524, 468, 522, 468, 522, 492, 498, 492, 498, 2958, 2992, 8934, 462, 1520, 496, 498, 496, 494, 524, 466, 500, 492, 524, 466, 524, 466, 526, 466, 500, 492, 500, 1482, 524, 472, 494, 498, 520, 1482, 500, 1482, 460, 1522, 464, 1518, 496, 496, 496, 1484, 502, 1482, 524, 1458, 526, 1458, 500, 1484, 498, 1484, 498, 1486, 496, 1510, 460, 532, 460, 530, 490, 502, 492, 1490, 498, 1484, 502, 1482, 500, 492, 524, 466, 498, 492, 498, 496, 496, 496, 494, 496, 496, 1486, 498, 518, 470, 1510, 460, 1522, 464, 528, 490, 500, 494, 496, 496, 1484, 502, 492, 498, 492, 524, 466, 498, 494, 496, 496, 496, 496, 496, 496, 494, 498, 494, 496, 494, 1510, 502, 1480, 500, 14606, 68, 20020, 66, 19912, 62, 7344, 108, 14804, 68, 18518, 110}; // UNKNOWN 4F9DA954

Note: Output from Tasmota is not acceptable. We can't easily use their raw format.

What brand/model IR demodulator are you using?

N/A . Captures above are from a Lolin IR shield, but for sending the signals I am using tasmota on a variety of devices (mainly YTF/Eachen IR ones).

Circuit diagram and hardware used (if applicable)

N/A

Link to an image of the circuit diagram used. Part number of the IR receiver module etc. ESP8266 or ESP32 board type.

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

No

Other useful information

As mentioned above, I believe (but please do not take my word on it, my understanding of the full IR protocol for the unit is quite limited!) that the "clean" flag is also sent as part of the "off" sequence. In which case, the library code should do the same, and honor that flag when sending a power off command.

[NiKiZe]

What is the full model number of AC and remote?

Notice that there is no protocol detected, this indicates that your device is not actually supported (could be temporary random timing issues)
Also which protocol have you been using?

[bogd]

The device is a samsung AR09HSFSBWKN, and I am using the SAMSUNG_AC protocol. As for the remote, I had no idea they even had model numbers... the only label on it says "DB93-14195A, OHSUNG ELECTRONICS CO, LTD".

The device is definitely supported - commands send via tasmota (from YTF/Eachen devices) are recognized correctly, and commands from the original remote are also generally correctly decoded by Tasmota (with some exceptions, see the issue I linked above).

Most likely, the lack of decoding on IRRecvDump is due to the lower quality of the IR receiver on the Lolin shield.

[bogd]

I finally managed to get some decodes (unfortunately, this only happens about 1 in 10 tries....):

[ Power on, 25 degrees ]
Protocol : SAMSUNG_AC
Code : 0x02920F000000F001D20F0000000001C2FE71900DF0 (168 Bits)
Mesg Desc.: Power: On, Mode: 0 (Auto), Temp: 25C, Fan: 6 (Auto), Swing: Off, Beep: Off, Clean: Off, Quiet: Off, Powerful: Off, Breeze: Off, Light: On, Ion: Off
uint16_t rawData[349] = {612, 18464, 2964, 8934, 496, 498, 492, 1490, 492, 502, 490, 502, 488, 524, 468, 440, 542, 532, 458, 530, 460, 532, 462, 1518, 494, 498, 492, 498, 494, 1488, 520, 470, 494, 498, 494, 1490, 494, 1488, 492, 1490, 492, 1514, 468, 1514, 460, 532, 484, 508, 484, 506, 490, 500, 492, 498, 494, 498, 492, 498, 494, 498, 492, 498, 494, 496, 494, 498, 494, 498, 490, 502, 490, 502, 464, 526, 490, 524, 468, 522, 468, 522, 460, 530, 460, 532, 462, 528, 488, 502, 492, 500, 492, 500, 494, 496, 494, 496, 494, 498, 494, 498, 492, 498, 494, 498, 492, 500, 492, 500, 490, 1514, 468, 1514, 468, 1514, 462, 1522, 496, 2964, 2988, 8934, 494, 1488, 494, 496, 494, 496, 496, 496, 494, 496, 494, 498, 494, 498, 492, 500, 490, 500, 490, 1496, 486, 522, 468, 524, 458, 1522, 462, 530, 462, 1518, 494, 1490, 494, 1486, 496, 1486, 496, 1486, 494, 1490, 520, 474, 490, 500, 490, 502, 488, 522, 468, 524, 460, 530, 484, 506, 462, 530, 488, 502, 488, 502, 492, 498, 494, 498, 494, 498, 494, 498, 494, 496, 494, 496, 494, 500, 492, 500, 490, 500, 492, 502, 488, 502, 488, 526, 466, 524, 462, 528, 484, 508, 486, 504, 486, 506, 492, 500, 494, 496, 494, 498, 494, 496, 494, 498, 494, 496, 494, 498, 492, 500, 492, 500, 462, 3016, 2966, 8940, 492, 1512, 468, 524, 462, 528, 460, 470, 520, 530, 462, 528, 490, 502, 494, 498, 492, 498, 496, 1486, 494, 498, 496, 496, 494, 496, 494, 500, 492, 1490, 492, 1492, 490, 524, 466, 1514, 460, 1522, 462, 1520, 492, 1490, 496, 1488, 496, 1486, 496, 1486, 496, 1488, 494, 500, 492, 500, 490, 500, 490, 1514, 468, 1516, 460, 1522, 462, 530, 488, 502, 492, 500, 494, 498, 494, 498, 492, 1488, 496, 496, 492, 498, 494, 1490, 494, 1490, 490, 502, 490, 1514, 468, 1516, 460, 532, 460, 530, 460, 530, 488, 502, 490, 502, 494, 496, 494, 496, 496, 496, 494, 1488, 496, 1488, 492, 1492, 490, 1492, 510}; // SAMSUNG_AC
uint8_t state[21] = {0x02, 0x92, 0x0F, 0x00, 0x00, 0x00, 0xF0, 0x01, 0xD2, 0x0F, 0x00, 0x00, 0x00, 0x00, 0x01, 0xC2, 0xFE, 0x71, 0x90, 0x0D, 0xF0};

[ Clean on - this seems to be using a short version of the IR protocol ]

Timestamp : 000259.820
Library : v2.7.18

Protocol : SAMSUNG_AC
Code : 0x02920F000000F001A2FEF1920DF0 (112 Bits)
Mesg Desc.: Power: On, Mode: 0 (Auto), Temp: 25C, Fan: 6 (Auto), Swing: Off, Beep: Off, Clean: On, Quiet: Off, Powerful: Off, Breeze: Off, Light: On, Ion: Off
uint16_t rawData[233] = {586, 17450, 3022, 8900, 526, 466, 528, 1452, 530, 462, 528, 462, 504, 486, 530, 462, 528, 462, 526, 466, 502, 490, 500, 1482, 528, 466, 524, 490, 502, 1478, 486, 506, 462, 530, 494, 1488, 526, 1456, 532, 1450, 530, 1454, 530, 1452, 532, 462, 526, 464, 528, 462, 528, 464, 526, 466, 524, 488, 502, 488, 458, 534, 460, 530, 490, 502, 490, 500, 498, 492, 530, 462, 502, 488, 530, 462, 528, 462, 528, 462, 528, 464, 528, 464, 524, 466, 528, 466, 498, 492, 526, 466, 524, 488, 500, 490, 460, 530, 462, 530, 488, 500, 494, 498, 522, 468, 526, 464, 528, 462, 530, 1452, 530, 1454, 502, 1480, 528, 1454, 486, 2996, 2956, 8946, 526, 1478, 500, 492, 460, 530, 462, 530, 490, 502, 494, 498, 498, 494, 526, 464, 524, 466, 524, 1456, 528, 464, 526, 464, 526, 392, 608, 1450, 524, 470, 522, 1482, 500, 492, 460, 1522, 460, 1522, 492, 1490, 526, 1458, 528, 1454, 530, 1454, 528, 1456, 528, 1456, 526, 468, 524, 468, 520, 470, 522, 1482, 500, 1482, 486, 1496, 490, 1492, 500, 492, 524, 1456, 526, 466, 526, 464, 526, 1456, 528, 466, 526, 466, 522, 1456, 524, 1460, 496, 518, 472, 1508, 460, 1522, 490, 502, 494, 498, 498, 492, 498, 492, 526, 464, 498, 494, 522, 468, 524, 466, 498, 1484, 522, 1462, 498, 1484, 522, 1484, 496}; // SAMSUNG_AC
uint8_t state[14] = {0x02, 0x92, 0x0F, 0x00, 0x00, 0x00, 0xF0, 0x01, 0xA2, 0xFE, 0xF1, 0x92, 0x0D, 0xF0};

[ Power off ]
Timestamp : 000478.446
Library : v2.7.18

Protocol : SAMSUNG_AC
Code : 0x02B20F000000C001D20F0000000001F2FE719011C0 (168 Bits)
Mesg Desc.: Power: Off, Mode: 1 (Cool), Temp: 25C, Fan: 0 (Auto), Swing: Off, Beep: Off, Clean: Off, Quiet: Off, Powerful: Off, Breeze: Off, Light: On, Ion: Off
uint16_t rawData[349] = {580, 17792, 2994, 8932, 464, 526, 492, 1490, 498, 494, 496, 494, 496, 496, 496, 494, 496, 496, 496, 496, 496, 496, 494, 1488, 492, 500, 492, 498, 492, 1512, 470, 1514, 488, 504, 462, 1520, 468, 1516, 498, 1484, 498, 1484, 498, 1486, 498, 496, 496, 496, 494, 498, 492, 498, 492, 500, 492, 522, 470, 520, 470, 520, 462, 530, 488, 504, 488, 502, 490, 500, 496, 496, 496, 496, 496, 494, 496, 496, 494, 496, 496, 496, 494, 496, 496, 496, 494, 498, 494, 498, 492, 500, 490, 522, 468, 522, 470, 522, 458, 532, 462, 530, 488, 504, 490, 500, 494, 496, 498, 494, 494, 496, 496, 496, 496, 1486, 496, 1488, 496, 2986, 2966, 8936, 494, 1488, 494, 522, 468, 522, 468, 522, 458, 532, 462, 528, 464, 526, 492, 500, 494, 496, 496, 1486, 496, 496, 496, 494, 494, 1486, 498, 496, 494, 1488, 494, 1490, 492, 1514, 470, 1514, 460, 1520, 490, 1494, 494, 500, 494, 496, 494, 496, 494, 496, 496, 494, 496, 496, 496, 494, 496, 496, 494, 500, 492, 500, 492, 498, 492, 524, 468, 522, 468, 522, 466, 524, 460, 530, 464, 528, 490, 502, 490, 500, 496, 496, 494, 496, 496, 496, 494, 496, 496, 494, 496, 496, 494, 496, 494, 498, 494, 498, 490, 502, 492, 522, 468, 522, 470, 522, 468, 524, 462, 530, 490, 500, 466, 526, 496, 2962, 2988, 8936, 496, 1382, 600, 494, 494, 496, 494, 496, 496, 496, 494, 498, 494, 498, 494, 498, 490, 500, 492, 1512, 468, 524, 466, 526, 462, 1518, 466, 1518, 494, 1488, 496, 1486, 498, 494, 496, 1486, 498, 1486, 496, 1488, 494, 1490, 492, 1514, 468, 1514, 462, 1520, 490, 1492, 494, 498, 496, 496, 496, 494, 496, 1486, 496, 1486, 496, 1488, 496, 498, 492, 500, 494, 498, 492, 524, 468, 520, 470, 1512, 464, 528, 464, 528, 488, 1492, 494, 1488, 496, 496, 496, 496, 496, 496, 494, 1486, 496, 496, 494, 498, 492, 500, 492, 500, 492, 500, 490, 522, 470, 520, 468, 522, 462, 528, 490, 1492, 492, 1490, 498}; // SAMSUNG_AC
uint8_t state[21] = {0x02, 0xB2, 0x0F, 0x00, 0x00, 0x00, 0xC0, 0x01, 0xD2, 0x0F, 0x00, 0x00, 0x00, 0x00, 0x01, 0xF2, 0xFE, 0x71, 0x90, 0x11, 0xC0};

Hmmm.... I might actually be wrong in my understanding of the IR protocol. Judging from the decode, the "clean" flag is not sent in the"off" message. If that is the case, I might just get it to work by toggling the flag before powering off. I have to run some additional tests :)

[NiKiZe]

Thanks for the additional information. (don't have time to deep dive into this right now, just trying to make sure that all information is available once someone does have that time)
yep clearly timing issues ;), a "seems to be working" is not the same thing as actually supported (as in a device being tested)

I can understand your frustration.
It is great that we have base to work with.
As you said, with that additional data it seems that there is no flag set in the off message of your original remote?
If it turns out somethings needs a change here, we must also make sure to not risk breaking other working devices. (I have not double checked this either)

One other thing to have in mind, The goal of the lib is to "make the devices usable, not to emulate every detail of a remote"
We try to avoid unnecessary emulation in the lib itself. Again as you said, by sending Cleaning which you seem to do on the real remote to activate this feature?

[bogd]

Once again, thank you for taking the time to work on this. To answer your question/remarks:

• based on my previous work trying to decode the IR protocol, and the fact that most commands are correctly recognized by the unit, I still believe that SAMSUNG_AC is the correct protocol for my unit (even though the exact model number is not listed as "supported"). And I am confident enough that I would even suggest adding it to the list of supported models (together with the 12K BTU model, which uses an identical remote and protocol)
• there is no frustration - I am just trying to get to the bottom of this issue, which I originally (and wrongly) believed was due to the way the library implements the power off function. My apologies if my previous messages suggested otherwise!
• I was not requesting any additional emulation, just something that I believed (again, wrongly!) was necessary for a specific function to work correctly.

Anyway - after additional testing, it appears that this ("clean") is a very strange flag on my unit. It appears to be a main unit-side toggle, and all the remote does when setting the bit on is toggle the setting on the main unit.

So a power on / toggle flag / power off sequence should work correctly for my use case.

I am closing this issue now, because the problem seems to be on my end. Thank you for your help, and my apologies for taking up your time with this!

[crankyoldgit]

"Clean" flag should be honored and sent during power off - right now, the code only sends a "standard" power off message, and ignores anything else when powering off the unit.

For my type of unit, "clean" simply means that it keeps the fan running for about 15 minutes after power off, to dry the inside of the system. As far as I can tell, this flag is sent by the original remote as part of the "off" sequence (this might be wrong - I am attaching captures from the original remote below, if it would help troubleshooting).

FYI, The support of Samsung A/Cs is a tad "special". Yes, sending an "Off" message via this library involves sending a canned "Off" message. We have been unable to replicate the message integrity check for the longer special Samsung messages. e.g. "Off". Thus, we can't construct customised long/special messages. If you care to work out how the check digits are calculated, please do so and let us know. For the shorter messages, it's the total/count of all the 1 bits in the binary of the code. I'm willing to look at any data/analysis you collect/perform for it because it has alluded me for years. It's driving me (more) crazy.

If you want to send a custom "off" message, for now, you will need to capture it and send it via sendSamsungAC(your_state_code_here) or via sendRaw(). Sorry.

I finally managed to get some decodes (unfortunately, this only happens about 1 in 10 tries....):

I had a look at those failed matches, it is mostly IR noise in the capture buffer prior to the real message arriving. ie. Could be a poor sensor module, circuit, or environment for IR receiver.

You could work-around that in software by setting the max_skip parameter to IRrecv::decode() to something like 2, or 4.

See: https://crankyoldgit.github.io/IRremoteESP8266/doxygen/html/classIRrecv.html#aeaa5c07a8b46f8fbb982f996cc1f9f4b for more details, and the costs involved in doing so.

based on my previous work trying to decode the IR protocol, and the fact that most commands are correctly recognized by the unit, I still believe that SAMSUNG_AC is the correct protocol for my unit (even though the exact model number is not listed as "supported"). And I am confident enough that I would even suggest adding it to the list of supported models (together with the 12K BTU model, which uses an identical remote and protocol)

Thanks. I'll add in that info to the supported models for Samsung.

[bogd]

@crankyoldgit - yeah, that protocol is... "special"... And I know exactly what you mean about the checksums. Years ago, I spent several months trying to figure out the protocol. And while I could figure out the bits for temperature, fan, etc, the (multiple!) checksum blocks always eluded me.

Looking at my notes from back then, I see something like "4-bit checksum, number of all 0 bits in this set (the longer messages seem to consist of 3 "sets", separated by special "break" messages - 550/3100/3100/8900), modulo 15. If modulo equals 0, set to 15". Each set seems to have its own 4-bit checksum. But then again, this was a long time ago, and I am pretty sure it is not 100% correct.

I will try to look over my captures once again, and see if I can derive a little bit more meaning from them :)

I would also like to say a big thank you! for this library. As mentioned above, I know from personal experience how much work is involved with trying to capture and decode the various IR protocols - so thank you for taking the time to do that, and making it available to the rest of us!

[bogd]

I have posted my old notes from attempting to decode the protocol here . I can also provide various captures from the original remote, if needed - maybe together we can finally crack that annoying protocol! :)

[crankyoldgit]

I will try to look over my captures once again, and see if I can derive a little bit more meaning from them :)

That would be fabulous! I had a quick look at what you had documented, but I'm confused on the "sets". I'ff you can describe what each "set" is by the byte ranges of this library's state[] array, that would be good. Saves me having to go back to the raw stream to see what you mean.

The idea of multiple "checksums" for the sets (and their ignored bytes) may be a big help cracking the extended message construction.