Information on Samsung AC IR protocol

[thermseekr]

Hello all,

This is not an actual issue. Feel free to erase/relocate as needed.

I wanted to use Home Assistant and Node-RED (where all my automations reside) to control my two Samsung air conditioning units. I spent a lot of time searching for information on the protocol, and this repository - specially issue #505 - was fundamental to point me in the right way. Today I finished the project and I would like to share the information I collected about the protocol in case it can be useful to anyone.

To be honest, I don't bring much more information than what is already available in issue #505 , but it is more detailed and a bit more organized.

The file has two spreadsheets, the first one with the learned commands in raw and burst/bit/byte table formats and the second one with the analysis of the functions I was able to decode so far. I kept the work restricted to temperature, mode, fan and swing functions. I didn't care about special modes as I don't use them. The beep for me is useful to confirm the unit has received the commands, so it's usually kept on and for that reason I haven't touched it as well.

About the checksum, which I think is the most interesting thing that I found: if you consider as checksum the whole two nibbles (the most significant nibble in byte 16 and the least significant nibble in byte 17) instead of only the bits that change, checksum will simply be the sum of all 1s in the last burst (last 7 bytes), checksum bits excluded, negated.

https://drive.google.com/file/d/1C4pzE47rKp4q0X-0olYKefg0tZ9Kju1i/view?usp=sharing

Thank you @crankyoldgit and Hollaco for spending the time to gather all info available in issue #505 .

Regards,
Tales

[crankyoldgit]

About the checksum, which I think is the most interesting thing that I found: if you consider as checksum the whole two nibbles (the most significant nibble in byte 16 and the least significant nibble in byte 17) instead of only the bits that change, checksum will simply be the sum of all 1s in the last burst (last 7 bytes), checksum bits excluded, negated.

Finally get around to this, sorry for the delay. Can I get you to explain/document this in C, C++, Python, or even pseudocode?
For what ever reason, I'm having a hard time understanding this.

[thermseekr]

Hi! I can't do it right now, will try to explain in a more clear way later today. And yes, I can share the JS code I wrote to "compile" and send the command to the AC. It's in a function node in Node-RED. Just keep in mind I'm not a professional programmer 😄

Edit: Sorry I hadn't seen your message before. Been a bit off-line the last few days.

[crankyoldgit]

I'm no JS coder, so even pseudo code will be fine.
If you are going to provide JavaScript, please please comment it a lot.

No worries for the delay, this isn't a job or anything. :-)

[thermseekr]

Hi David,

So, I'll try to make myself more clear about the checksum computation.

First, in order to refresh your memory in case you haven't looked into this protocol lately, Samsung AC units transmit three 7-byte bursts for power on and power off, and two 7-byte bursts for all other commands. The third burst for power on/off, when present, will be transmitted between the two regular bursts. Odd...

Other important thing to note is that bit order in each byte is reversed between the spreadsheet you shared here and the one I shared here. In my spreadsheet, I numbered bits and bytes in the order they are transmitted, and it is LSB first.

When studying the data I collected, it seemed more logical to assume that all functions (mode, speed, temperature, swing) should use a whole nibble instead of only the bits I actually saw changing. When studying the checksum, I saw the same bits you and/or Hollako identified as 45-46-47, but there were some combinations where the first bit in the next byte was also changing. I think you mentioned that in one of your posts, asking him to identify why that other bit was flipping sometimes. I than considered checksum to be the second half of byte 16 and the first half of byte 17. Given it's LSB first, the high nibble is in byte 17 and the low nibble is in byte 16.

After that I did a few tests counting the 1s in each transmission until I realized that counting 1s only in the last burst (7 last bytes), excluding the 8 checksum bits, I got this:

Or in binary:

Bits are inverted!!

I hope I was able to make it more clear. If not, please let me know. If you want I can still share the code I use in Node-RED to assemble and transmit the commands, but I'm not sure if it would add much.

Best regards,
Tales

[crankyoldgit]

Yes please, share the code.

[crankyoldgit]

I was thinking if you could explained it like this (completely made up, not meant to reflect reality):

First checksum is: Count all the 1 bits in bytes[0], bytes[1], bytes[2], bytes[3], bytes[4], bytes[5], & bottom half of bytes[6] put the count in the top half of bytes[6] and put the inverse in the bottom of bytes[7].
Second checksum is: Count all the 1 bits in the top of bytes[7], all of bytes[8], bytes[9], bytes[10], bytes[11], bytes[12]. Put the count in the bottom of bytes[13] and the inverse in the top of bytes[13].
Blah blah for the 3rd section etc.

[thermseekr]

Good morning! Yes I can.

1. Consider always the last 7 bytes of any transmission. Let's number them bytes 15 to 21.
2. Checksum will be located in the second half of byte 16 and first half of byte 17, LSB first.
3. Count the number of 1s in bytes 15 to 21, excluding checksum bits. These will be byte 15, first half of byte 16, second half of byte 17, byte 18, byte 19, byte 20, byte 21.
4. Perform a bitwise NOT on the result. This is your checksum.

Will add code later, can't do it now. Meanwhile, I suggest you take a look in the spreadsheet, under the Analysis tab.

IR Codes Samsung.xlsx

Cheers,
Tales

[crankyoldgit]

Good morning! Yes I can.

Many many thanks. Yes, I looked at the spreadsheet. I thought it was kind of what you had said, but from past experience, I wanted to be real sure this time. You've no idea how much this has vexed me. I had lifted the existing code from somewhere else, and could never understand how or why it worked the way it did. i.e. 28 - the count of bits.

Inverting it, and knowing it's a full byte, not just a nibble was key.

Again, many many thanks.

[thermseekr]

Hello David,

I am super super happy to have been able to help. I usually get the benefit from the work of others, and now I had the opportunity to do something useful. It's very rewarding.

Fun fact, I was ready to go out on vacations with the family when I got a positive test for COVID. I looked into a whole week locked in my bedroom and I thought well, time to figure this protocol out.

Thank you very much.

Tales/thermseeker

[crankyoldgit]

That sucks. Hope you recover well, and have no "long covid" issues.

[thermseekr]

I am fully recovered, thanks. Had only moderate headache and a bit of fever during the first 2-3 days.

Here's the code I use in Node-RED to assemble the transmission. I can explain in later in more detail if needed, and also share the full flows in NR if you think it's useful. I use Broadlink devices as IR blasters in my home.

Samsung AC NodeRed.txt

[crankyoldgit]

Thanks, but based on your pseudo code, I was able to confirm it, and code it up myself. See PR #1554

[bogd]

@thermseekr - that is a great job!! As mentioned in another issue , I also tried to get to the bottom of that CRC a long time ago, but I never could figure out the complete and correct way to compute it.

Thank you for doing this, and thank you for sharing it with the rest of us - this will make life a lot easier for many people (and I am one of them)! :)

[thermseekr]

Hello @bogd

I too had tried it other times without success. I'm very happy it worked out and that it will be useful to others. All I have running in my home automation is derived from work done by other people, I'm happy to be able to collaborate a little bit with this awesome community.

[crankyoldgit]

FYI, the changes mentioned above have been included in the just released v2.7.20 of the library.