Irremoteesp8266: Decoding Samsung AC IR Remote
Please help to decode Samsung AC IR remote to be able to control separately the Mode, Temperature, Fan speed, Swing mode. To be able to be controlled via ESP8266 with MQTT. I can handle the MQTT part but the decoding still he missing part in this application.
Thank you,
Hollako
All 73 comments
It's missing because it requires a) access to the device (which you probably have) and b) a lot of time/effort.
For an example of the process we go about for adding support, see #485
If you want the support, you are going to have to put some effort in to capture and pull apart the message codes to work out which bits control the various functions. I and others have found creating a spreadsheet helps to try to decode by hand what is in the message. Once we have that worked out, then adding the code is then possible.
I'm happy to help with the code aspects, but doing the initial message decoding is best done by someone who has the remote/device to hand.
crankyoldgit
on 27 Aug 2018
Sure no problem, I am ready to help with small hints from your side i will start the decoding process. as a first step i should get the Raw Data then convert them to bits (1 or 0), please advise if am wrong ?!?
Hollako
on 27 Aug 2018
What does the output of IRrecvDumpV2 look like?
If it is only UNKNOWN, then yes, the Raw Data is what you are going to have to use.
To help convert that to binary, try using the auto_analyse_raw_data.py program.
If IRrecvDumpV2 recognises it as a named protocol (e.g. SAMSUNG), then you likely can just use/convert the hex value.
crankyoldgit
on 27 Aug 2018
Hello,
true, It gives me Unknown.
On the other hand I have another AC remote where the output of the IRecvDmpV2 is Coolix. However i couldn't the commands where i can send the Coolix codes separately (Mode, Temp, Fans, etc..) any advise please ?
Hollako
on 28 Aug 2018
The Coolix protocol hasn't been fully reverse engineered yet. There is some work to decode the Coolix protocol in Issue #484 - Feel free to contribute to there to help decode the bit patterns/values.
crankyoldgit
on 29 Aug 2018
Hello,
Actually for the moment am focusing on the Samsung codes, once done will contribute on coolix for sure.
However, am facing some difficulties on the decoding, i used the python file to convert the raw to bits. first i found several outputs after conversion. am not sure the Bin sequence that am using is the correct one. then i tried to compare between the temperatures with same Mode Cool, Fan Auto, Swing Auto. but things still not clear enough despite that i found some bits are changing where they probably are the temperature bits but not enough.
For example i detected the same code twice with same temperature then i copied the Raw sequence extracted from IRrecvDumpV2 sketch then i converted these Raw signal in order to get the same Bin sequence but unfortunately I got 2 different Bin sequence with typically same IR code.
Please any hint to go Further with the correct reversing engineering of an AC IR codes?
Hollako
on 2 Sep 2018
https://github.com/markszabo/IRremoteESP8266/wiki/Troubleshooting-Guide#reporting-an-issue
Especially see points 1, 8, 11, & 12. ;-)
i.e. Can you give us some data/examples? It's hard(er) to understand what is going on without actual data.
crankyoldgit
on 3 Sep 2018
Hello, sure i forgot to attach the file am working on.
Samsung Decoding.xlsx
But as i mentioned in my previous comment that the same code give a different Raw sequence and different binary sequence as well. But the number of bits is all time same 117 bits an the Raw sequence is 233 (please find attached picture).
Hollako
on 3 Sep 2018
Can you include here the text for the lines you are giving as input to the auto analyse program?
e.g. like the last line of your screen shot. uint16_t rawData[etc] = {......};
Especially for the two messages that you say are the same, but decode differently.
FYI, text is far better than a graphical screenshot, as it allows people to use the data you provide to try to duplicate or analyse the experience you are having.
Typically, if the state of the remote is the same when the same button is pressed, we would expect exactly the same message both times. Note that the "clock" on the remote may have changed and thus the message may change too if the time is included.
So, as indicated earlier. More data please. Don't be afraid to go overboard in that respect.
From what I can see so far, these samsung messages certainly are an unusual protocol so far.
What model is the A/C Unit and the Remote?
crankyoldgit
on 3 Sep 2018
Looking at your spreadsheet, I am fairly confident you are missing half of the message data in your "Binary Sequence" column. e.g. There appear to be two 56-bit data sequences per message, totalling ~112 bits of data.
I've tried to reconstruct the data from one of the entries in the spreadsheet and got the following:
Found 233 timing entries.
Potential Mark Candidates:
[3086, 690]
Potential Space Candidates:
[17844, 8864, 2886, 1432, 436]
Guessing encoding type:
Looks like it uses space encoding. Yay!
Guessing key value:
kHdrMark = 3086
kHdrSpace = 2886
kBitMark = 690
kOneSpace = 1432
kZeroSpace = 436
kSpaceGap1 = 17844
kSpaceGap2 = 8864
Decoding protocol based on analysis so far:
kBitMark(UNEXPECTED)GAP(17844)kHdrMark+UNEXPECTED->GAP(8864)kBitMark(UNEXPECTED)01000000010010011111000000000000000000000000000000001111
Bits: 56
Hex: 0x4049F00000000F (MSB first)
0xF00000000F9202 (LSB first)
Dec: 18095693650460687 (MSB first)
67553994411577858 (LSB first)
Bin: 0b01000000010010011111000000000000000000000000000000001111 (MSB first)
0b11110000000000000000000000000000000011111001001000000010 (LSB first)
UNEXPECTED->kHdrSpace+kHdrMark+UNEXPECTED->GAP(8858)kBitMark(UNEXPECTED)10000000010000001111010110001110000000001010100000001111
Bits: 56
Hex: 0x8040F58E00A80F (MSB first)
0xF0150071AF0201 (LSB first)
Dec: 36100220412536847 (MSB first)
67577086062035457 (LSB first)
Bin: 0b10000000010000001111010110001110000000001010100000001111 (MSB first)
0b11110000000101010000000001110001101011110000001000000001 (LSB first)
Total Nr. of suspected bits: 112
Hey again, a good news, i tried the heat mode with temp from 16 to 30 and i could recognize the temperature bits clearly.
A very important tip you mentioned regarding the time of the remote that may vary the code as well.
And referring the raw data are all included in the excel sheet i sent but i was not sure if i am on the right track by decoding the AC IR. Hopefully now am in a step forward. And i need to make sure that the code is 56 bits, is it correct ?
Anyway i moving forward to know the rest of the code (mode, fan, swing).
Hollako
on 3 Sep 2018
True 112 bits but the first sequence is exactly the same between all the codes. So am working on the second sequence only. then we can add the first one as it is.
Hollako
on 3 Sep 2018
@Hollako If you try the branch https://github.com/markszabo/IRremoteESP8266/tree/v2.5-dev-samsung-ac it should hopefully help you with your decoding efforts. It's based on the data I as able to get from your spreadsheet.
crankyoldgit
on 3 Sep 2018
Hello,
I am facing an issue with the new "auto_analyse_raw_data.py" file am not able able to convert the raw to bin sequence anymore. and here is below the error in python:
Traceback (most recent call last):
File "C:\Python27\Lib\site-packages\pythonwin\pywin\framework\scriptutils.py", line 326, in RunScript
exec codeObject in __main__.__dict__
File "C:\Users\Ehanna\Desktop\Samsung Decoding\auto_analyse_raw_data.py", line 7, in
import argparse
File "C:\Python27\lib\argparse.py", line 86, in
import copy as _copy
File "C:\Python27\lib\copy.py", line 52, in
import weakref
File "C:\Python27\lib\weakref.py", line 14, in
from _weakref import (
ImportError: cannot import name _remove_dead_weakref
Help please !!
Hollako
on 4 Sep 2018
Which new "auto_analyse_raw_data.py" file are you using? The one in the v2.5-dev-samsung-ac branch?
And what command line arguments (and files/data) are you giving it?
I just tested the one in v2.5-dev-samsung-ac and it's working fine for me on a linux system.
Looking at the Traceback provided, it seems the problem is in the argparse library, not with the analyse script. i.e. Check your python 2.7 installation etc.
crankyoldgit
on 4 Sep 2018
P.S. In theory, if you use IRrecvDumpV2 in that branch, you shouldn't need they analyse program anymore. It will give you the answer in HEX. etc.
crankyoldgit
on 4 Sep 2018
The python version installed is 2.7.14, wired.
Anyway i followed your steps and replace the IRremoteESP8266 with v2.5-dev-samsung-ac branch and now i am getting the Encoding SAMSUNG_AC and HEX number as you mentioned above.
So the next step now is to convert the HEX numbers into binary? and continue the decoding.
Many thanks for your support, maybe i am asking some silly questions but this is my first time in decoding IR codes. hopefully later on i will be more efficient in this community to enrich this library with more and more of A/C codes.
Hollako
on 4 Sep 2018
Re: Converting. It depends. Some times some people find it easier to work in Hexidecimal, some people prefer binary. There are plenty of hex <=> bin converters/calculators out there.
If you look at #509 you can see some other tips/approaches/gotchas for working out decoding the state into the functions of the A/C unit.
I often recommend working out the bit order (the code you are using assumes MSB at the moment, it could be wrong) by trying to workout the Temperature feature. Often, but not always, the temperature bits/byte/nibble increments by 1 for each extra degree. That sequencing helps determine which order the bits are in. Usually.
crankyoldgit
on 4 Sep 2018
Hello,
I think am done with the converting into binary for all the main function, Power, Temperature, Mode, Fan Speed and Swing. I adopted the IRremoteESP8266 with v2.5-dev-samsung-ac branch to finalize it cause i don't know why the Python is not working anymore with me. But the good thing is that i could continue with the IRrecvDumpV2 of the Samsung AC branch. and yes i am using the MSB.
Please find attached the excel file "Summary" sheet. Where I clarified which bits are related to which function in IR code. Then in the Fan Sheet you will find the 112 bits sequence with some examples.
So now what;s next ?
Samsung AC Decoding.xlsx
Hollako
on 4 Sep 2018
Thanks. Looking at the fan data. It's clear the fan data is in LSB First order. So I've pushed a change to that branch to reverse the bit order.
That will mean all the hex/binary data will change. You'll need to update/re-capture.
I noticed you've marked a 4-bit section of data as Unknown. In order for us to succeed we will need to know why those bits are changing before we can make new messages.
There are several possibilities for them:
1) They are a checksum. But it's very odd as it's in the middle of the message. Typically a checksum is at the end.
2) The time on the remote.
3) Some other function.
If it is the checksum, you need to calculate how it's derived before we can construct a message from components. This is often the most frustrating and challenging part.
What you want to do is to see if you can change a single bit elsewhere in the message, to see if those checksum bits change. Then work backwards to see how you could calculate those changing values.
Here are some examples of checksum algorithms I've seen in other protocols.
- The sum of all the previous/other bytes but modded (i.e. %) to fit into a the size of the checksum.
- The sum of all the lower half of all the bytes and modded to fit into a the size of the checksum.
- The XOR of the previous bytes ...
- The 2's compliment of the sum of the bytes ...
- Ten (10) + The sum of the bytes ...
Basically, have a look through some of the other protocols to see how they handle checksums.
FYI, Due to the nature of the checksum calc, you can't obviously include the bits of the checksum in the calculation of itself. i.e. You can safely exclude them.
crankyoldgit
on 5 Sep 2018
Hello,
First let me understand why it's changed to LSB, for me when i was working on the python file i was copying the MSB binary sequence. And when i continued with the new branch including the Samsung AC codes the sequence still same and the same bits still at same place. Maybe the enumeration of the bits are wrong cause i started from 112 on left to 1 on right. i am not sure if i should swap the enumeration.
Regarding the unknown bits, is it obligatory to know them? cause there is more bits like Comfort, Beep, Quiet etc... i clarified which bits but i don't know if it's necessary to use them or consider them in IRRemote library.
However, the checksum is a new challenge for me but what if they are Time bits? should we consider them as well ?
Thank you,
Hollako
on 5 Sep 2018
See this comment in the whirlpool discussion: https://github.com/markszabo/IRremoteESP8266/issues/509#issuecomment-417918572
It's basically the same here.
The change to LSB (for each byte) order here won't be the same as the analyse script output. It's just swapping the order with in each byte.
I looked at the data to try to work out your numbering scheme .. it took me a while to work out what you did. But I believe I've got it right.
Basically, when you just change the temp, those bits/hex values should increment just like you'd expect.
i.e. the remote's temp goes up by one, that corresponding hex digit should also go up by one.
I think I didn't explain myself well. You don't have to have every feature of the remote documented. You just have to be able know why/explain/be able to predict which bits are changed when you change only one thing.
So, you don't have to have "quiet" etc working or mapped. But .. if the Temp changes by one, and some other bits change, they either have to be temp bits, or you need to explain why they changed. Example:
If you change the mode, and these other bits (presuming they are the checksum) also change at the same time, AND if you change the temp and those same "checksum" bits change ... then they are either a checksum .. or there must be some other explanation that we need to uncover.
All of this is so we can construct an entirely new message (set the temp to 19, mode to cool, fan to High, etc) and construct a valid code that the aircon unit will accept. i.e. it is the same as what the remote generates.
crankyoldgit
on 5 Sep 2018
To see if it is a time code, try to produce the same "message" (i.e. all the same hex values) with the remote in the same state .. but only with a different time on the remote.
e.g.
Send a "on cool 21C fan auto etc" at 12:01 ... and then at 12:02 ... etc. If it is a time code, then it will change, if it isn't the messages will be the same,
crankyoldgit
on 5 Sep 2018
In short. If any bits change when when we press a button that we want to emulate, we need to understand and explain why they've changed.
crankyoldgit
on 5 Sep 2018
Well noted, will go further to know the unknown bits.
Hollako
on 5 Sep 2018
Hello,
Sorry for this delay, have been busy lately.
Anyway I did clarified the "Unknown" bits and i can confirm that they are a checksum bits, if i send the same code these bits are same as well. But couldn't know how they are calculated specially that these bits are in the middle of the message and not at the end or beginning.
I need a small tip to know how to start please !
Thank you,
Hollako
on 10 Sep 2018
Some google searches for "samsung air conditioner ir codes" highlights a number of Arduino implementations. Have a look at what some of them have for the checksum calc.
It looks like it _might_ be the number of '1's in the binary before the checksum value, or something related to that. That final number may be a inverted or a 2's compliment but it's a start for some hints.
crankyoldgit
on 10 Sep 2018
crankyoldgit
on 10 Sep 2018
Marking this issue resolved due to low-feedback and that the experimental code has now been merged into 2.5, which will be released soon.
crankyoldgit
on 20 Sep 2018
Hello,
I could know the relation between the Checksum (bits 41 to 44) and the bits 1 to 40 but without knowing exactly how it's calculated.
But am sure that the number of bit 1 is giving the same checksum.
For example when the of bit 1 (between bit N°1 to bit N°40) is 18, the checksum is 0111.
another example if the bit 1 number is 20 the checksum is 0011.
I have attached the excel file in the "Mode" sheet many sequence insure this relation but till now i couldn't know the algorithm of this calculation.
Help please !!
Hollako
on 20 Sep 2018
From what I've read elsewhere, the algorithm for counting the bits seems to exclude the "last sent" byte's bits.
See https://github.com/markszabo/IRremoteESP8266/blob/v2.5-dev/src/ir_Samsung.cpp#L250 for all the details/code for what _seems_ to work on the data I've tried.
crankyoldgit
on 20 Sep 2018
v2.5.0 has been released.
crankyoldgit
on 20 Sep 2018
Hello,
First of all Many thanks for your support and effort.
I tried the V2.5.0 version and i found small issues regarding the Samsung IR codes, listed below:
1- The Power Off is not resolved n the IRrecvDumpV2 and giving unknown code.
2- the Fan speed values are 0 for Auto, 2 for Low, 4 for Mid and 5 for High. Why it's not 0,1,2,3 ?
3- the Swing Mode is changing between On and Off (values 0 and 1) but the transmitted code is the same, and i receive the same code in IRrecvDumpV2
The Fan Speed is not as a high priority but Power Off and Swing Mode are not working. I am ready to help if something still missing from my side.
Thank you,
Hollako
on 23 Sep 2018
Can you please provide the entire output of IRrecvDumpV2 for each signal that has an issue? I need that information to determine what might be wrong.
1) See above. I'll need that to fix it.
2) The numbers were based on your spreadsheet data. If you disagree and think I've mis-read the data, please let me know.
3) Thanks. I'll look into it, but the tests I've done seem to indicate it is changing the state and the message. Again, please provide the the Dump output for the signals, and the code you are using to set & change the Swing options.
crankyoldgit
on 23 Sep 2018
Hello,
For the Fan Speed, noted. I didn't know that you follow the binary sequence and convert it to decimal.
As for the swing mode, Please find attached the excel file, in the swing sheet you will find the binary sequence where i clarified the swing bits 34,45,46. When move the bits are 010 and when stop the bits are 111. Even i tried 2 (decimal of 010) and 7 (decimal of 111), same results.
And for the Power also please look at the fan sheet where i clarified the power bits which are bits number 99, 59 and 60. Power Off ROW.
Hollako
on 24 Sep 2018
Can you please just cut and paste the dump output here?
crankyoldgit
on 24 Sep 2018
As for swing, The spreadsheet says to me it's bits 34,35, & 36. Where is the stuff saying it is 34, 45, 46?
Are you attaching the correct spreadsheet? I think a better solution is to convert it into a Google Sheets document and make it read-only/public and put the link here.
Also, setSwing() takes a _boolean_ i.e. true (move) or false (stop moving).
crankyoldgit
on 24 Sep 2018
Hello,
Regarding the swing is my typo mistake 34, 35 and 36 are the correct ones. And i will try the boolean codes. Noting that when i send setSwing(0) the IR String shown Swing Off and when i send setSwing(1) the IR string shows Swing On.
Regarding the rest codes i will attache them once ready.
Thank you.
Hollako
on 24 Sep 2018
Hello David,
Here is below the decoding received in the IRrecvDumpV2:
Swing On:
Timestamp : 000389.162
Encoding : SAMSUNG_AC
Code : 02920F000000F00102AF718011F0 (112 bits)
Mesg Desc.: Power: On, Mode: 1 (COOL), Temp: 24C, Fan: 0 (AUTO), Swing: Off, Beep: Off, Clean: Off, Quiet: Off
Library : v2.5.0
Raw Timing[233]:
+ 692, - 17106, + 3058, - 8932, + 572, - 454, + 546, - 1430,
+ 568, - 452, + 548, - 450, + 550, - 448, + 550, - 478,
+ 522, - 476, + 550, - 450, + 568, - 430, + 574, - 1402,
+ 594, - 428, + 546, - 454, + 546, - 1428, + 574, - 450,
+ 550, - 448, + 548, - 1428, + 570, - 1428, + 568, - 1450,
+ 548, - 1450, + 550, - 1456, + 542, - 478, + 570, - 428,
+ 574, - 426, + 576, - 420, + 574, - 426, + 544, - 454,
+ 548, - 452, + 548, - 450, + 550, - 448, + 550, - 448,
+ 548, - 450, + 548, - 450, + 548, - 452, + 548, - 450,
+ 546, - 452, + 548, - 450, + 550, - 448, + 548, - 478,
+ 520, - 480, + 572, - 428, + 570, - 428, + 578, - 422,
+ 574, - 426, + 544, - 454, + 522, - 478, + 548, - 450,
+ 548, - 452, + 548, - 450, + 546, - 452, + 574, - 426,
+ 550, - 448, + 550, - 450, + 548, - 1448, + 548, - 1450,
+ 548, - 1456, + 594, - 1402, + 570, - 2918, + 3106, - 8908,
+ 594, - 1408, + 566, - 454, + 550, - 450, + 546, - 450,
+ 548, - 452, + 546, - 452, + 548, - 452, + 550, - 448,
+ 550, - 450, + 546, - 1450, + 548, - 450, + 548, - 478,
+ 520, - 478, + 572, - 428, + 570, - 428, + 576, - 422,
+ 574, - 1400, + 564, - 1434, + 570, - 1430, + 566, - 1428,
+ 570, - 454, + 548, - 1428, + 570, - 450, + 548, - 1448,
+ 550, - 1434, + 562, - 480, + 518, - 480, + 566, - 432,
+ 574, - 1400, + 592, - 1404, + 568, - 1430, + 570, - 452,
+ 548, - 450, + 548, - 450, + 548, - 450, + 546, - 452,
+ 550, - 450, + 548, - 450, + 574, - 424, + 548, - 1452,
+ 548, - 1454, + 586, - 434, + 570, - 428, + 576, - 424,
+ 572, - 1404, + 542, - 478, + 550, - 450, + 550, - 450,
+ 574, - 426, + 574, - 424, + 548, - 450, + 548, - 450,
+ 566, - 1412, + 570, - 1448, + 548, - 1436, + 562, - 1456,
+ 570
uint16_t rawData[233] = {692, 17106, 3058, 8932, 572, 454, 546, 1430, 568, 452, 548, 450, 550, 448, 550, 478, 522, 476, 550, 450, 568, 430, 574, 1402, 594, 428, 546, 454, 546, 1428, 574, 450, 550, 448, 548, 1428, 570, 1428, 568, 1450, 548, 1450, 550, 1456, 542, 478, 570, 428, 574, 426, 576, 420, 574, 426, 544, 454, 548, 452, 548, 450, 550, 448, 550, 448, 548, 450, 548, 450, 548, 452, 548, 450, 546, 452, 548, 450, 550, 448, 548, 478, 520, 480, 572, 428, 570, 428, 578, 422, 574, 426, 544, 454, 522, 478, 548, 450, 548, 452, 548, 450, 546, 452, 574, 426, 550, 448, 550, 450, 548, 1448, 548, 1450, 548, 1456, 594, 1402, 570, 2918, 3106, 8908, 594, 1408, 566, 454, 550, 450, 546, 450, 548, 452, 546, 452, 548, 452, 550, 448, 550, 450, 546, 1450, 548, 450, 548, 478, 520, 478, 572, 428, 570, 428, 576, 422, 574, 1400, 564, 1434, 570, 1430, 566, 1428, 570, 454, 548, 1428, 570, 450, 548, 1448, 550, 1434, 562, 480, 518, 480, 566, 432, 574, 1400, 592, 1404, 568, 1430, 570, 452, 548, 450, 548, 450, 548, 450, 546, 452, 550, 450, 548, 450, 574, 424, 548, 1452, 548, 1454, 586, 434, 570, 428, 576, 424, 572, 1404, 542, 478, 550, 450, 550, 450, 574, 426, 574, 424, 548, 450, 548, 450, 566, 1412, 570, 1448, 548, 1436, 562, 1456, 570}; // SAMSUNG_AC
uint8_t state[14] = {0x02, 0x92, 0x0F, 0x00, 0x00, 0x00, 0xF0, 0x01, 0x02, 0xAF, 0x71, 0x80, 0x11, 0xF0};
Swing Off:
Timestamp : 000538.883
Encoding : SAMSUNG_AC
Code : 02920F000000F001E2FE718011F0 (112 bits)
Mesg Desc.: Power: On, Mode: 1 (COOL), Temp: 24C, Fan: 0 (AUTO), Swing: Off, Beep: Off, Clean: Off, Quiet: Off
Library : v2.5.0
Raw Timing[233]:
+ 692, - 17104, + 3100, - 8894, + 612, - 410, + 588, - 1408,
+ 590, - 410, + 588, - 410, + 588, - 412, + 588, - 438,
+ 560, - 438, + 534, - 466, + 572, - 428, + 572, - 1400,
+ 606, - 418, + 584, - 414, + 586, - 1386, + 612, - 412,
+ 588, - 410, + 588, - 1384, + 614, - 1388, + 610, - 1408,
+ 588, - 1410, + 590, - 1412, + 586, - 440, + 570, - 428,
+ 572, - 428, + 578, - 420, + 580, - 418, + 586, - 412,
+ 588, - 410, + 588, - 412, + 588, - 412, + 586, - 412,
+ 588, - 410, + 588, - 410, + 588, - 410, + 588, - 408,
+ 590, - 408, + 590, - 408, + 590, - 440, + 560, - 438,
+ 570, - 428, + 570, - 430, + 572, - 426, + 578, - 422,
+ 582, - 418, + 586, - 412, + 588, - 410, + 588, - 412,
+ 588, - 410, + 588, - 412, + 588, - 410, + 588, - 412,
+ 586, - 412, + 586, - 410, + 588, - 1408, + 590, - 1414,
+ 584, - 1436, + 568, - 1408, + 610, - 2874, + 3122, - 8896,
+ 606, - 1394, + 562, - 458, + 588, - 412, + 586, - 412,
+ 588, - 410, + 588, - 412, + 586, - 412, + 588, - 410,
+ 588, - 410, + 590, - 1410, + 588, - 438, + 560, - 440,
+ 568, - 430, + 568, - 1430, + 574, - 1400, + 606, - 1392,
+ 612, - 410, + 588, - 1386, + 614, - 1410, + 586, - 1386,
+ 612, - 1408, + 590, - 1408, + 590, - 1414, + 584, - 1438,
+ 572, - 1406, + 594, - 424, + 578, - 420, + 584, - 416,
+ 584, - 1412, + 588, - 1390, + 608, - 1388, + 610, - 412,
+ 588, - 410, + 588, - 410, + 590, - 408, + 590, - 408,
+ 590, - 412, + 588, - 438, + 560, - 438, + 572, - 1402,
+ 594, - 1406, + 604, - 418, + 582, - 416, + 588, - 412,
+ 588, - 1388, + 610, - 412, + 588, - 410, + 588, - 412,
+ 588, - 410, + 588, - 412, + 588, - 410, + 590, - 408,
+ 590, - 1394, + 604, - 1414, + 594, - 1402, + 596, - 1402,
+ 612
uint16_t rawData[233] = {692, 17104, 3100, 8894, 612, 410, 588, 1408, 590, 410, 588, 410, 588, 412, 588, 438, 560, 438, 534, 466, 572, 428, 572, 1400, 606, 418, 584, 414, 586, 1386, 612, 412, 588, 410, 588, 1384, 614, 1388, 610, 1408, 588, 1410, 590, 1412, 586, 440, 570, 428, 572, 428, 578, 420, 580, 418, 586, 412, 588, 410, 588, 412, 588, 412, 586, 412, 588, 410, 588, 410, 588, 410, 588, 408, 590, 408, 590, 408, 590, 440, 560, 438, 570, 428, 570, 430, 572, 426, 578, 422, 582, 418, 586, 412, 588, 410, 588, 412, 588, 410, 588, 412, 588, 410, 588, 412, 586, 412, 586, 410, 588, 1408, 590, 1414, 584, 1436, 568, 1408, 610, 2874, 3122, 8896, 606, 1394, 562, 458, 588, 412, 586, 412, 588, 410, 588, 412, 586, 412, 588, 410, 588, 410, 590, 1410, 588, 438, 560, 440, 568, 430, 568, 1430, 574, 1400, 606, 1392, 612, 410, 588, 1386, 614, 1410, 586, 1386, 612, 1408, 590, 1408, 590, 1414, 584, 1438, 572, 1406, 594, 424, 578, 420, 584, 416, 584, 1412, 588, 1390, 608, 1388, 610, 412, 588, 410, 588, 410, 590, 408, 590, 408, 590, 412, 588, 438, 560, 438, 572, 1402, 594, 1406, 604, 418, 582, 416, 588, 412, 588, 1388, 610, 412, 588, 410, 588, 412, 588, 410, 588, 412, 588, 410, 590, 408, 590, 1394, 604, 1414, 594, 1402, 596, 1402, 612}; // SAMSUNG_AC
uint8_t state[14] = {0x02, 0x92, 0x0F, 0x00, 0x00, 0x00, 0xF0, 0x01, 0xE2, 0xFE, 0x71, 0x80, 0x11, 0xF0};
And Regarding the power codes i noticed that the timing is not same as the other codes during Power On and the bits also are not same, didn't noticed this difference before.
Power On:
Timestamp : 000596.878
Encoding : UNKNOWN
Code : D6C798FC (175 bits)
Library : v2.5.0
Raw Timing[349]:
+ 662, - 17870, + 3026, - 8966, + 540, - 484, + 514, - 1482,
+ 518, - 482, + 514, - 482, + 518, - 482, + 516, - 510,
+ 490, - 508, + 490, - 508, + 572, - 428, + 576, - 1398,
+ 542, - 482, + 514, - 484, + 514, - 1460, + 540, - 482,
+ 518, - 482, + 516, - 1456, + 544, - 1480, + 518, - 1480,
+ 518, - 1480, + 518, - 1484, + 514, - 510, + 566, - 432,
+ 576, - 424, + 574, - 426, + 540, - 458, + 516, - 482,
+ 516, - 482, + 516, - 482, + 518, - 480, + 518, - 482,
+ 518, - 482, + 518, - 482, + 516, - 482, + 518, - 482,
+ 516, - 482, + 518, - 480, + 516, - 508, + 492, - 508,
+ 490, - 508, + 572, - 428, + 576, - 422, + 572, - 428,
+ 542, - 456, + 514, - 484, + 518, - 480, + 518, - 480,
+ 518, - 480, + 516, - 482, + 516, - 482, + 520, - 478,
+ 518, - 482, + 518, - 480, + 518, - 1480, + 518, - 1480,
+ 516, - 1484, + 594, - 1428, + 518, - 2964, + 3032, - 8964,
+ 540, - 1458, + 542, - 480, + 518, - 480, + 520, - 480,
+ 518, - 482, + 520, - 480, + 520, - 478, + 518, - 480,
+ 520, - 478, + 520, - 1478, + 522, - 478, + 518, - 506,
+ 494, - 1484, + 594, - 426, + 574, - 1400, + 564, - 1434,
+ 540, - 1454, + 544, - 1478, + 520, - 1454, + 544, - 1458,
+ 540, - 480, + 520, - 480, + 518, - 480, + 520, - 480,
+ 518, - 508, + 490, - 506, + 568, - 432, + 572, - 426,
+ 576, - 424, + 544, - 454, + 518, - 480, + 516, - 482,
+ 520, - 478, + 520, - 478, + 522, - 478, + 518, - 480,
+ 520, - 478, + 520, - 478, + 520, - 478, + 520, - 478,
+ 520, - 478, + 518, - 478, + 522, - 506, + 494, - 504,
+ 566, - 432, + 576, - 424, + 576, - 424, + 570, - 428,
+ 518, - 482, + 518, - 480, + 518, - 482, + 520, - 478,
+ 520, - 478, + 520, - 480, + 520, - 478, + 520, - 478,
+ 520, - 2964, + 3032, - 8986, + 520, - 1478, + 520, - 506,
+ 492, - 506, + 492, - 506, + 568, - 430, + 574, - 424,
+ 546, - 454, + 516, - 482, + 518, - 482, + 518, - 1456,
+ 544, - 478, + 546, - 452, + 520, - 478, + 544, - 1432,
+ 542, - 1478, + 520, - 1478, + 520, - 478, + 520, - 1482,
+ 586, - 1412, + 598, - 1400, + 564, - 1432, + 540, - 1458,
+ 544, - 1454, + 544, - 1454, + 544, - 1456, + 542, - 480,
+ 518, - 480, + 520, - 480, + 520, - 1462, + 536, - 1482,
+ 588, - 1410, + 598, - 424, + 572, - 426, + 542, - 456,
+ 518, - 482, + 520, - 478, + 520, - 478, + 522, - 478,
+ 520, - 478, + 520, - 1456, + 542, - 1458, + 540, - 478,
+ 520, - 478, + 520, - 478, + 520, - 1482, + 540, - 482,
+ 568, - 430, + 576, - 424, + 570, - 428, + 542, - 458,
+ 518, - 480, + 520, - 480, + 520, - 1454, + 568, - 1430,
+ 566, - 1432, + 566, - 1454, + 594
uint16_t rawData[349] = {662, 17870, 3026, 8966, 540, 484, 514, 1482, 518, 482, 514, 482, 518, 482, 516, 510, 490, 508, 490, 508, 572, 428, 576, 1398, 542, 482, 514, 484, 514, 1460, 540, 482, 518, 482, 516, 1456, 544, 1480, 518, 1480, 518, 1480, 518, 1484, 514, 510, 566, 432, 576, 424, 574, 426, 540, 458, 516, 482, 516, 482, 516, 482, 518, 480, 518, 482, 518, 482, 518, 482, 516, 482, 518, 482, 516, 482, 518, 480, 516, 508, 492, 508, 490, 508, 572, 428, 576, 422, 572, 428, 542, 456, 514, 484, 518, 480, 518, 480, 518, 480, 516, 482, 516, 482, 520, 478, 518, 482, 518, 480, 518, 1480, 518, 1480, 516, 1484, 594, 1428, 518, 2964, 3032, 8964, 540, 1458, 542, 480, 518, 480, 520, 480, 518, 482, 520, 480, 520, 478, 518, 480, 520, 478, 520, 1478, 522, 478, 518, 506, 494, 1484, 594, 426, 574, 1400, 564, 1434, 540, 1454, 544, 1478, 520, 1454, 544, 1458, 540, 480, 520, 480, 518, 480, 520, 480, 518, 508, 490, 506, 568, 432, 572, 426, 576, 424, 544, 454, 518, 480, 516, 482, 520, 478, 520, 478, 522, 478, 518, 480, 520, 478, 520, 478, 520, 478, 520, 478, 520, 478, 518, 478, 522, 506, 494, 504, 566, 432, 576, 424, 576, 424, 570, 428, 518, 482, 518, 480, 518, 482, 520, 478, 520, 478, 520, 480, 520, 478, 520, 478, 520, 2964, 3032, 8986, 520, 1478, 520, 506, 492, 506, 492, 506, 568, 430, 574, 424, 546, 454, 516, 482, 518, 482, 518, 1456, 544, 478, 546, 452, 520, 478, 544, 1432, 542, 1478, 520, 1478, 520, 478, 520, 1482, 586, 1412, 598, 1400, 564, 1432, 540, 1458, 544, 1454, 544, 1454, 544, 1456, 542, 480, 518, 480, 520, 480, 520, 1462, 536, 1482, 588, 1410, 598, 424, 572, 426, 542, 456, 518, 482, 520, 478, 520, 478, 522, 478, 520, 478, 520, 1456, 542, 1458, 540, 478, 520, 478, 520, 478, 520, 1482, 540, 482, 568, 430, 576, 424, 570, 428, 542, 458, 518, 480, 520, 480, 520, 1454, 568, 1430, 566, 1432, 566, 1454, 594}; // UNKNOWN D6C798FC
Power Off:
Timestamp : 000696.241
Encoding : UNKNOWN
Code : 7561C5F6 (175 bits)
Library : v2.5.0
Raw Timing[349]:
+ 670, - 17802, + 3096, - 8898, + 602, - 420, + 580, - 1418,
+ 582, - 418, + 582, - 416, + 582, - 416, + 584, - 442,
+ 550, - 448, + 568, - 430, + 570, - 430, + 576, - 1396,
+ 600, - 424, + 546, - 452, + 578, - 1394, + 604, - 1396,
+ 600, - 420, + 580, - 1398, + 602, - 1416, + 586, - 1412,
+ 582, - 1420, + 576, - 1422, + 592, - 428, + 574, - 424,
+ 576, - 422, + 578, - 420, + 548, - 452, + 578, - 420,
+ 578, - 420, + 584, - 416, + 580, - 418, + 580, - 418,
+ 582, - 418, + 580, - 418, + 582, - 414, + 584, - 414,
+ 584, - 416, + 582, - 418, + 584, - 442, + 558, - 442,
+ 568, - 430, + 576, - 424, + 578, - 420, + 576, - 424,
+ 576, - 422, + 580, - 420, + 584, - 414, + 584, - 416,
+ 584, - 414, + 582, - 418, + 580, - 418, + 582, - 416,
+ 582, - 416, + 584, - 414, + 584, - 414, + 586, - 442,
+ 554, - 1420, + 570, - 1452, + 578, - 2884, + 3120, - 8898,
+ 596, - 1400, + 602, - 422, + 582, - 418, + 584, - 414,
+ 582, - 416, + 584, - 414, + 584, - 416, + 582, - 416,
+ 584, - 416, + 584, - 1410, + 586, - 414, + 582, - 444,
+ 556, - 1420, + 590, - 432, + 572, - 1402, + 602, - 1396,
+ 600, - 1398, + 606, - 1414, + 582, - 1394, + 604, - 1394,
+ 604, - 414, + 584, - 414, + 586, - 412, + 586, - 410,
+ 586, - 442, + 556, - 440, + 544, - 456, + 568, - 430,
+ 576, - 424, + 578, - 420, + 578, - 420, + 576, - 424,
+ 584, - 412, + 586, - 412, + 586, - 412, + 584, - 414,
+ 586, - 412, + 584, - 414, + 586, - 412, + 586, - 412,
+ 586, - 414, + 586, - 412, + 584, - 442, + 558, - 442,
+ 558, - 440, + 566, - 432, + 574, - 424, + 578, - 422,
+ 576, - 422, + 578, - 420, + 586, - 414, + 586, - 414,
+ 586, - 412, + 584, - 414, + 586, - 414, + 586, - 414,
+ 586, - 2902, + 3096, - 8900, + 600, - 1416, + 586, - 442,
+ 556, - 442, + 558, - 440, + 564, - 434, + 572, - 428,
+ 578, - 420, + 580, - 420, + 578, - 420, + 584, - 1392,
+ 608, - 414, + 586, - 414, + 582, - 414, + 586, - 412,
+ 586, - 412, + 586, - 414, + 584, - 1394, + 606, - 1416,
+ 580, - 1418, + 568, - 1432, + 594, - 1402, + 602, - 1398,
+ 606, - 1392, + 606, - 1390, + 608, - 1390, + 608, - 414,
+ 584, - 414, + 586, - 414, + 584, - 1412, + 586, - 1398,
+ 600, - 1418, + 590, - 430, + 566, - 432, + 576, - 422,
+ 578, - 420, + 578, - 422, + 582, - 416, + 586, - 414,
+ 586, - 412, + 584, - 1390, + 606, - 1392, + 608, - 414,
+ 586, - 412, + 584, - 412, + 588, - 1410, + 586, - 442,
+ 558, - 440, + 568, - 430, + 566, - 434, + 574, - 426,
+ 578, - 420, + 578, - 420, + 582, - 416, + 586, - 412,
+ 586, - 1390, + 608, - 1390, + 608
uint16_t rawData[349] = {670, 17802, 3096, 8898, 602, 420, 580, 1418, 582, 418, 582, 416, 582, 416, 584, 442, 550, 448, 568, 430, 570, 430, 576, 1396, 600, 424, 546, 452, 578, 1394, 604, 1396, 600, 420, 580, 1398, 602, 1416, 586, 1412, 582, 1420, 576, 1422, 592, 428, 574, 424, 576, 422, 578, 420, 548, 452, 578, 420, 578, 420, 584, 416, 580, 418, 580, 418, 582, 418, 580, 418, 582, 414, 584, 414, 584, 416, 582, 418, 584, 442, 558, 442, 568, 430, 576, 424, 578, 420, 576, 424, 576, 422, 580, 420, 584, 414, 584, 416, 584, 414, 582, 418, 580, 418, 582, 416, 582, 416, 584, 414, 584, 414, 586, 442, 554, 1420, 570, 1452, 578, 2884, 3120, 8898, 596, 1400, 602, 422, 582, 418, 584, 414, 582, 416, 584, 414, 584, 416, 582, 416, 584, 416, 584, 1410, 586, 414, 582, 444, 556, 1420, 590, 432, 572, 1402, 602, 1396, 600, 1398, 606, 1414, 582, 1394, 604, 1394, 604, 414, 584, 414, 586, 412, 586, 410, 586, 442, 556, 440, 544, 456, 568, 430, 576, 424, 578, 420, 578, 420, 576, 424, 584, 412, 586, 412, 586, 412, 584, 414, 586, 412, 584, 414, 586, 412, 586, 412, 586, 414, 586, 412, 584, 442, 558, 442, 558, 440, 566, 432, 574, 424, 578, 422, 576, 422, 578, 420, 586, 414, 586, 414, 586, 412, 584, 414, 586, 414, 586, 414, 586, 2902, 3096, 8900, 600, 1416, 586, 442, 556, 442, 558, 440, 564, 434, 572, 428, 578, 420, 580, 420, 578, 420, 584, 1392, 608, 414, 586, 414, 582, 414, 586, 412, 586, 412, 586, 414, 584, 1394, 606, 1416, 580, 1418, 568, 1432, 594, 1402, 602, 1398, 606, 1392, 606, 1390, 608, 1390, 608, 414, 584, 414, 586, 414, 584, 1412, 586, 1398, 600, 1418, 590, 430, 566, 432, 576, 422, 578, 420, 578, 422, 582, 416, 586, 414, 586, 412, 584, 1390, 606, 1392, 608, 414, 586, 412, 584, 412, 588, 1410, 586, 442, 558, 440, 568, 430, 566, 434, 574, 426, 578, 420, 578, 420, 582, 416, 586, 412, 586, 1390, 608, 1390, 608}; // UNKNOWN 7561C5F6
@Hollako thanks for that data. It's most helpful.
crankyoldgit
on 25 Sep 2018
I've found the bug for why setting and reading the Swing status wasn't working. I changed the wrong byte (8 instead of 9).
However, your data showed there is another bit changing that you haven't explained/documented.
By "your" naming, it would be bit 40. It changes between the two settings/samples.
e.g.:
Swing On: 02920F000000F00102AF718011F0
Swing Off: 02920F000000F001E2FE718011F0
The difference is bytes 8 & 9 (first byte reading from the left is Byte 0.):
On: 02AF
Off: E2FE
Byte 8 contains the checksum, so you can ignore that change.
But byte 9 changes from 0xAF (On) to 0xFE (Off). The first nibble (top 4 bits) of each byte (A/on and F/off respectively) is explained by your spreadsheet/comments about how swing works. However the lowest bit of that byte (Your bit 40) changes. i.e. F to E)
@Hollako You need to explain that.
I'll upload a commit/branch where I'm working on the corrections in a sec.
crankyoldgit
on 25 Sep 2018
FYI, I'm working on the fixes in the samsung-ac-fixes branch.
crankyoldgit
on 25 Sep 2018
Regarding the power on/off. Yes, the new data you've provided indicates there are a total of three 56-bit sections in those messages, rather than the typical two. (think 21 bytes, instead of the normal 14)
From the two data samples you've provided, the middle one is the "new" one, and it seems fixed at least.
Decoding/reading it shouldn't be to hard a problem, but creating/sending/knowing when to send it is the harder part.
That's a significant change, and I'll have to think about how best to support that.
crankyoldgit
on 25 Sep 2018
First pass added for supporting the unusual length Samsung A/C message has been added to that branch. @Hollako Can you please try it out?
crankyoldgit
on 25 Sep 2018
Dear David,
Regarding the Swing, it's done.
But for the power mainly also is done but i have noticed a difference between the code sent from the Original Samsung Remote and the code sent from the ESP8266 IRTX device based on the new IRremote8266 library.
For now am doing my tests on on the IRrecvDumV2 and not a real Samsung AC Split. Please find below the code received from the Original Samsung AC remote and the IR code send by the ESP8266 IRTX.
Original Samsung Remote:
Power On
Timestamp : 001639.550
Encoding : SAMSUNG_AC
Code : 02920F000000F001D20F0000000001E2FE718011F0 (168 bits)
Mesg Desc.: Power: On, Mode: 0 (AUTO), Temp: 16C, Fan: 0 (AUTO), Swing: Off, Beep: Off, Clean: Off, Quiet: Off
Library : v2.5.0
Raw Timing[349]:
+ 658, - 17896, + 3026, - 8942, + 562, - 462, + 538, - 1458,
+ 540, - 462, + 536, - 462, + 536, - 464, + 536, - 488,
+ 512, - 486, + 516, - 484, + 560, - 440, + 536, - 1434,
+ 562, - 462, + 536, - 462, + 538, - 1434, + 564, - 460,
+ 538, - 462, + 538, - 1456, + 540, - 1436, + 562, - 1438,
+ 560, - 1456, + 540, - 1462, + 536, - 488, + 534, - 464,
+ 538, - 462, + 538, - 462, + 536, - 462, + 536, - 462,
+ 538, - 460, + 540, - 460, + 538, - 460, + 540, - 458,
+ 540, - 458, + 538, - 460, + 538, - 462, + 538, - 460,
+ 538, - 460, + 538, - 462, + 538, - 464, + 534, - 488,
+ 512, - 486, + 484, - 516, + 536, - 462, + 538, - 460,
+ 538, - 460, + 536, - 462, + 538, - 460, + 540, - 458,
+ 540, - 460, + 538, - 460, + 538, - 460, + 538, - 460,
+ 540, - 458, + 538, - 460, + 538, - 1454, + 544, - 1482,
+ 514, - 1462, + 552, - 1444, + 564, - 2942, + 3058, - 8940,
+ 562, - 1436, + 564, - 460, + 538, - 460, + 540, - 458,
+ 540, - 458, + 540, - 458, + 540, - 458, + 540, - 458,
+ 540, - 458, + 540, - 1452, + 544, - 462, + 536, - 486,
+ 512, - 1460, + 560, - 466, + 536, - 1436, + 562, - 1434,
+ 566, - 1434, + 564, - 1432, + 564, - 1434, + 566, - 1434,
+ 564, - 458, + 540, - 458, + 540, - 460, + 540, - 460,
+ 538, - 486, + 512, - 486, + 484, - 516, + 534, - 466,
+ 536, - 462, + 538, - 462, + 536, - 462, + 538, - 460,
+ 540, - 458, + 540, - 458, + 540, - 458, + 540, - 458,
+ 540, - 458, + 540, - 460, + 538, - 460, + 540, - 460,
+ 540, - 458, + 540, - 460, + 538, - 486, + 512, - 486,
+ 482, - 516, + 532, - 466, + 536, - 464, + 536, - 462,
+ 538, - 460, + 540, - 460, + 538, - 460, + 540, - 458,
+ 540, - 458, + 540, - 460, + 540, - 458, + 540, - 458,
+ 540, - 2944, + 3052, - 8962, + 542, - 1456, + 544, - 486,
+ 512, - 486, + 516, - 482, + 482, - 516, + 534, - 464,
+ 538, - 462, + 538, - 460, + 540, - 460, + 540, - 1436,
+ 562, - 458, + 540, - 458, + 540, - 460, + 540, - 1434,
+ 564, - 1454, + 542, - 1456, + 544, - 486, + 512, - 1482,
+ 518, - 1456, + 558, - 1438, + 564, - 1436, + 564, - 1434,
+ 564, - 1434, + 564, - 1432, + 588, - 1412, + 562, - 460,
+ 540, - 458, + 540, - 460, + 540, - 1482, + 516, - 1482,
+ 512, - 1464, + 558, - 464, + 536, - 462, + 536, - 462,
+ 540, - 460, + 540, - 458, + 562, - 436, + 542, - 458,
+ 540, - 458, + 540, - 1456, + 542, - 1454, + 544, - 460,
+ 562, - 436, + 540, - 462, + 536, - 1482, + 516, - 484,
+ 482, - 516, + 534, - 464, + 536, - 464, + 536, - 462,
+ 540, - 460, + 540, - 458, + 540, - 1454, + 542, - 1436,
+ 562, - 1436, + 562, - 1456, + 540
uint16_t rawData[349] = {658, 17896, 3026, 8942, 562, 462, 538, 1458, 540, 462, 536, 462, 536, 464, 536, 488, 512, 486, 516, 484, 560, 440, 536, 1434, 562, 462, 536, 462, 538, 1434, 564, 460, 538, 462, 538, 1456, 540, 1436, 562, 1438, 560, 1456, 540, 1462, 536, 488, 534, 464, 538, 462, 538, 462, 536, 462, 536, 462, 538, 460, 540, 460, 538, 460, 540, 458, 540, 458, 538, 460, 538, 462, 538, 460, 538, 460, 538, 462, 538, 464, 534, 488, 512, 486, 484, 516, 536, 462, 538, 460, 538, 460, 536, 462, 538, 460, 540, 458, 540, 460, 538, 460, 538, 460, 538, 460, 540, 458, 538, 460, 538, 1454, 544, 1482, 514, 1462, 552, 1444, 564, 2942, 3058, 8940, 562, 1436, 564, 460, 538, 460, 540, 458, 540, 458, 540, 458, 540, 458, 540, 458, 540, 458, 540, 1452, 544, 462, 536, 486, 512, 1460, 560, 466, 536, 1436, 562, 1434, 566, 1434, 564, 1432, 564, 1434, 566, 1434, 564, 458, 540, 458, 540, 460, 540, 460, 538, 486, 512, 486, 484, 516, 534, 466, 536, 462, 538, 462, 536, 462, 538, 460, 540, 458, 540, 458, 540, 458, 540, 458, 540, 458, 540, 460, 538, 460, 540, 460, 540, 458, 540, 460, 538, 486, 512, 486, 482, 516, 532, 466, 536, 464, 536, 462, 538, 460, 540, 460, 538, 460, 540, 458, 540, 458, 540, 460, 540, 458, 540, 458, 540, 2944, 3052, 8962, 542, 1456, 544, 486, 512, 486, 516, 482, 482, 516, 534, 464, 538, 462, 538, 460, 540, 460, 540, 1436, 562, 458, 540, 458, 540, 460, 540, 1434, 564, 1454, 542, 1456, 544, 486, 512, 1482, 518, 1456, 558, 1438, 564, 1436, 564, 1434, 564, 1434, 564, 1432, 588, 1412, 562, 460, 540, 458, 540, 460, 540, 1482, 516, 1482, 512, 1464, 558, 464, 536, 462, 536, 462, 540, 460, 540, 458, 562, 436, 542, 458, 540, 458, 540, 1456, 542, 1454, 544, 460, 562, 436, 540, 462, 536, 1482, 516, 484, 482, 516, 534, 464, 536, 464, 536, 462, 540, 460, 540, 458, 540, 1454, 542, 1436, 562, 1436, 562, 1456, 540}; // SAMSUNG_AC
uint8_t state[21] = {0x02, 0x92, 0x0F, 0x00, 0x00, 0x00, 0xF0, 0x01, 0xD2, 0x0F, 0x00, 0x00, 0x00, 0x00, 0x01, 0xE2, 0xFE, 0x71, 0x80, 0x11, 0xF0};
Power Off:
Timestamp : 001637.008
Encoding : SAMSUNG_AC
Code : 02B20F000000C001D20F000000000102FF718011C0 (168 bits)
Mesg Desc.: Power: Off, Mode: 0 (AUTO), Temp: 16C, Fan: 0 (AUTO), Swing: Off, Beep: Off, Clean: Off, Quiet: Off
Library : v2.5.0
Raw Timing[349]:
+ 676, - 17814, + 3054, - 8940, + 564, - 462, + 538, - 1436,
+ 560, - 462, + 538, - 462, + 536, - 464, + 536, - 486,
+ 512, - 488, + 572, - 426, + 534, - 464, + 538, - 1436,
+ 560, - 464, + 536, - 462, + 540, - 1432, + 566, - 1434,
+ 564, - 460, + 538, - 1434, + 564, - 1456, + 542, - 1456,
+ 542, - 1460, + 538, - 1458, + 544, - 484, + 536, - 462,
+ 560, - 438, + 538, - 462, + 536, - 462, + 538, - 460,
+ 540, - 458, + 540, - 458, + 540, - 456, + 542, - 458,
+ 540, - 458, + 540, - 458, + 542, - 458, + 540, - 458,
+ 540, - 458, + 540, - 458, + 540, - 484, + 514, - 484,
+ 482, - 516, + 534, - 466, + 536, - 462, + 538, - 460,
+ 538, - 460, + 540, - 458, + 542, - 458, + 540, - 458,
+ 542, - 458, + 540, - 458, + 542, - 456, + 542, - 458,
+ 540, - 458, + 538, - 460, + 540, - 458, + 540, - 460,
+ 540, - 1458, + 600, - 1398, + 568, - 2920, + 3076, - 8938,
+ 564, - 1434, + 566, - 458, + 540, - 458, + 542, - 458,
+ 540, - 458, + 540, - 458, + 542, - 456, + 540, - 458,
+ 542, - 458, + 540, - 1454, + 544, - 460, + 540, - 484,
+ 514, - 1458, + 510, - 516, + 534, - 1440, + 560, - 1458,
+ 542, - 1432, + 566, - 1430, + 568, - 1432, + 566, - 1434,
+ 564, - 458, + 540, - 458, + 540, - 458, + 540, - 460,
+ 538, - 486, + 512, - 486, + 514, - 484, + 484, - 514,
+ 534, - 466, + 536, - 462, + 538, - 460, + 538, - 460,
+ 540, - 458, + 540, - 460, + 540, - 458, + 540, - 458,
+ 540, - 458, + 540, - 458, + 540, - 458, + 540, - 458,
+ 542, - 458, + 540, - 458, + 540, - 486, + 514, - 486,
+ 514, - 484, + 484, - 514, + 534, - 466, + 536, - 462,
+ 538, - 460, + 540, - 460, + 540, - 458, + 540, - 458,
+ 540, - 458, + 540, - 458, + 542, - 456, + 540, - 458,
+ 542, - 2944, + 3054, - 8960, + 544, - 1454, + 566, - 438,
+ 538, - 486, + 512, - 486, + 514, - 484, + 482, - 516,
+ 534, - 464, + 536, - 462, + 538, - 460, + 540, - 1432,
+ 564, - 458, + 540, - 458, + 562, - 436, + 540, - 458,
+ 540, - 460, + 564, - 434, + 564, - 1430, + 544, - 1454,
+ 566, - 1438, + 540, - 1458, + 558, - 1438, + 562, - 1462,
+ 540, - 1436, + 586, - 1408, + 566, - 1432, + 566, - 458,
+ 540, - 458, + 540, - 458, + 540, - 1454, + 542, - 1456,
+ 542, - 1464, + 594, - 428, + 482, - 516, + 532, - 466,
+ 536, - 464, + 536, - 462, + 538, - 460, + 540, - 458,
+ 562, - 436, + 540, - 1432, + 566, - 1432, + 566, - 460,
+ 540, - 460, + 562, - 436, + 540, - 1456, + 542, - 486,
+ 534, - 464, + 514, - 484, + 482, - 516, + 530, - 468,
+ 534, - 464, + 536, - 464, + 538, - 458, + 564, - 434,
+ 540, - 1434, + 564, - 1434, + 562
uint16_t rawData[349] = {676, 17814, 3054, 8940, 564, 462, 538, 1436, 560, 462, 538, 462, 536, 464, 536, 486, 512, 488, 572, 426, 534, 464, 538, 1436, 560, 464, 536, 462, 540, 1432, 566, 1434, 564, 460, 538, 1434, 564, 1456, 542, 1456, 542, 1460, 538, 1458, 544, 484, 536, 462, 560, 438, 538, 462, 536, 462, 538, 460, 540, 458, 540, 458, 540, 456, 542, 458, 540, 458, 540, 458, 542, 458, 540, 458, 540, 458, 540, 458, 540, 484, 514, 484, 482, 516, 534, 466, 536, 462, 538, 460, 538, 460, 540, 458, 542, 458, 540, 458, 542, 458, 540, 458, 542, 456, 542, 458, 540, 458, 538, 460, 540, 458, 540, 460, 540, 1458, 600, 1398, 568, 2920, 3076, 8938, 564, 1434, 566, 458, 540, 458, 542, 458, 540, 458, 540, 458, 542, 456, 540, 458, 542, 458, 540, 1454, 544, 460, 540, 484, 514, 1458, 510, 516, 534, 1440, 560, 1458, 542, 1432, 566, 1430, 568, 1432, 566, 1434, 564, 458, 540, 458, 540, 458, 540, 460, 538, 486, 512, 486, 514, 484, 484, 514, 534, 466, 536, 462, 538, 460, 538, 460, 540, 458, 540, 460, 540, 458, 540, 458, 540, 458, 540, 458, 540, 458, 540, 458, 542, 458, 540, 458, 540, 486, 514, 486, 514, 484, 484, 514, 534, 466, 536, 462, 538, 460, 540, 460, 540, 458, 540, 458, 540, 458, 540, 458, 542, 456, 540, 458, 542, 2944, 3054, 8960, 544, 1454, 566, 438, 538, 486, 512, 486, 514, 484, 482, 516, 534, 464, 536, 462, 538, 460, 540, 1432, 564, 458, 540, 458, 562, 436, 540, 458, 540, 460, 564, 434, 564, 1430, 544, 1454, 566, 1438, 540, 1458, 558, 1438, 562, 1462, 540, 1436, 586, 1408, 566, 1432, 566, 458, 540, 458, 540, 458, 540, 1454, 542, 1456, 542, 1464, 594, 428, 482, 516, 532, 466, 536, 464, 536, 462, 538, 460, 540, 458, 562, 436, 540, 1432, 566, 1432, 566, 460, 540, 460, 562, 436, 540, 1456, 542, 486, 534, 464, 514, 484, 482, 516, 530, 468, 534, 464, 536, 464, 538, 458, 564, 434, 540, 1434, 564, 1434, 562}; // SAMSUNG_AC
uint8_t state[21] = {0x02, 0xB2, 0x0F, 0x00, 0x00, 0x00, 0xC0, 0x01, 0xD2, 0x0F, 0x00, 0x00, 0x00, 0x00, 0x01, 0x02, 0xFF, 0x71, 0x80, 0x11, 0xC0};
ESP8266 IRTX Remote:
Power On
Timestamp : 001626.397
Encoding : SAMSUNG_AC
Code : 02920F000000F001E2FF71000DF0 (112 bits)
Mesg Desc.: Power: On, Mode: 0 (AUTO), Temp: 16C, Fan: 6 (AUTO), Swing: Off, Beep: Off, Clean: Off, Quiet: Off
Library : v2.5.0
Raw Timing[233]:
+ 752, - 17904, + 3170, - 8814, + 680, - 376, + 652, - 1346,
+ 678, - 378, + 652, - 374, + 652, - 378, + 652, - 376,
+ 654, - 372, + 652, - 380, + 628, - 400, + 628, - 1366,
+ 658, - 402, + 652, - 376, + 652, - 1340, + 684, - 378,
+ 628, - 400, + 652, - 1340, + 682, - 1346, + 682, - 1340,
+ 660, - 1366, + 658, - 1368, + 682, - 374, + 628, - 400,
+ 652, - 378, + 628, - 400, + 654, - 378, + 630, - 398,
+ 628, - 400, + 654, - 374, + 628, - 402, + 630, - 396,
+ 630, - 398, + 654, - 378, + 628, - 398, + 654, - 378,
+ 630, - 396, + 616, - 414, + 630, - 404, + 640, - 384,
+ 628, - 402, + 630, - 400, + 652, - 378, + 628, - 398,
+ 630, - 398, + 654, - 376, + 654, - 374, + 652, - 376,
+ 652, - 380, + 652, - 376, + 652, - 378, + 628, - 400,
+ 628, - 398, + 630, - 398, + 630, - 1370, + 682, - 1340,
+ 682, - 1342, + 682, - 1344, + 682, - 2802, + 3082, - 8874,
+ 682, - 1346, + 658, - 398, + 630, - 398, + 654, - 378,
+ 652, - 374, + 654, - 376, + 628, - 402, + 628, - 400,
+ 630, - 398, + 628, - 1368, + 660, - 398, + 630, - 398,
+ 628, - 402, + 630, - 1364, + 660, - 1366, + 658, - 1368,
+ 682, - 1340, + 660, - 1364, + 660, - 1370, + 656, - 1366,
+ 658, - 1364, + 682, - 1346, + 658, - 1366, + 658, - 1364,
+ 660, - 1368, + 660, - 398, + 654, - 374, + 630, - 400,
+ 630, - 1364, + 660, - 1364, + 660, - 1368, + 682, - 376,
+ 654, - 374, + 630, - 402, + 630, - 398, + 630, - 398,
+ 630, - 400, + 654, - 374, + 630, - 398, + 630, - 402,
+ 630, - 1364, + 660, - 398, + 614, - 1384, + 682, - 1340,
+ 660, - 398, + 630, - 402, + 628, - 400, + 654, - 376,
+ 654, - 376, + 630, - 398, + 654, - 374, + 654, - 378,
+ 654, - 1340, + 658, - 1366, + 658, - 1370, + 656, - 1364,
+ 682
uint16_t rawData[233] = {752, 17904, 3170, 8814, 680, 376, 652, 1346, 678, 378, 652, 374, 652, 378, 652, 376, 654, 372, 652, 380, 628, 400, 628, 1366, 658, 402, 652, 376, 652, 1340, 684, 378, 628, 400, 652, 1340, 682, 1346, 682, 1340, 660, 1366, 658, 1368, 682, 374, 628, 400, 652, 378, 628, 400, 654, 378, 630, 398, 628, 400, 654, 374, 628, 402, 630, 396, 630, 398, 654, 378, 628, 398, 654, 378, 630, 396, 616, 414, 630, 404, 640, 384, 628, 402, 630, 400, 652, 378, 628, 398, 630, 398, 654, 376, 654, 374, 652, 376, 652, 380, 652, 376, 652, 378, 628, 400, 628, 398, 630, 398, 630, 1370, 682, 1340, 682, 1342, 682, 1344, 682, 2802, 3082, 8874, 682, 1346, 658, 398, 630, 398, 654, 378, 652, 374, 654, 376, 628, 402, 628, 400, 630, 398, 628, 1368, 660, 398, 630, 398, 628, 402, 630, 1364, 660, 1366, 658, 1368, 682, 1340, 660, 1364, 660, 1370, 656, 1366, 658, 1364, 682, 1346, 658, 1366, 658, 1364, 660, 1368, 660, 398, 654, 374, 630, 400, 630, 1364, 660, 1364, 660, 1368, 682, 376, 654, 374, 630, 402, 630, 398, 630, 398, 630, 400, 654, 374, 630, 398, 630, 402, 630, 1364, 660, 398, 614, 1384, 682, 1340, 660, 398, 630, 402, 628, 400, 654, 376, 654, 376, 630, 398, 654, 374, 654, 378, 654, 1340, 658, 1366, 658, 1370, 656, 1364, 682}; // SAMSUNG_AC
uint8_t state[14] = {0x02, 0x92, 0x0F, 0x00, 0x00, 0x00, 0xF0, 0x01, 0xE2, 0xFF, 0x71, 0x00, 0x0D, 0xF0};
Power Off:
Timestamp : 001630.184
Encoding : SAMSUNG_AC
Code : 02B20F000000C001E2FF71000DF0 (112 bits)
Mesg Desc.: Power: Off, Mode: 0 (AUTO), Temp: 16C, Fan: 6 (AUTO), Swing: Off, Beep: Off, Clean: Off, Quiet: Off
Library : v2.5.0
Raw Timing[233]:
+ 750, - 17860, + 3150, - 8840, + 682, - 374, + 652, - 1346,
+ 682, - 378, + 650, - 376, + 652, - 376, + 652, - 378,
+ 652, - 376, + 652, - 376, + 654, - 374, + 654, - 1340,
+ 682, - 376, + 652, - 378, + 650, - 1344, + 658, - 1364,
+ 682, - 380, + 652, - 1346, + 680, - 1344, + 682, - 1342,
+ 684, - 1340, + 682, - 1344, + 680, - 380, + 650, - 376,
+ 652, - 376, + 650, - 382, + 652, - 376, + 652, - 378,
+ 652, - 376, + 628, - 400, + 652, - 378, + 652, - 376,
+ 652, - 376, + 652, - 376, + 652, - 376, + 650, - 376,
+ 624, - 406, + 652, - 378, + 652, - 374, + 628, - 402,
+ 652, - 376, + 652, - 376, + 628, - 404, + 652, - 376,
+ 628, - 398, + 628, - 402, + 652, - 376, + 628, - 400,
+ 628, - 402, + 652, - 376, + 652, - 374, + 652, - 378,
+ 628, - 400, + 650, - 376, + 652, - 378, + 628, - 400,
+ 628, - 1366, + 680, - 1348, + 656, - 2828, + 3082, - 8874,
+ 684, - 1342, + 682, - 376, + 628, - 400, + 630, - 402,
+ 652, - 376, + 628, - 398, + 652, - 378, + 628, - 400,
+ 650, - 376, + 652, - 1346, + 658, - 400, + 628, - 400,
+ 628, - 402, + 628, - 1368, + 680, - 1342, + 680, - 1348,
+ 656, - 1368, + 656, - 1368, + 656, - 1370, + 658, - 1366,
+ 658, - 1366, + 682, - 1344, + 658, - 1366, + 658, - 1366,
+ 658, - 1368, + 658, - 400, + 628, - 400, + 628, - 402,
+ 630, - 1366, + 656, - 1366, + 682, - 1346, + 656, - 400,
+ 628, - 398, + 628, - 404, + 654, - 374, + 628, - 400,
+ 650, - 380, + 628, - 400, + 628, - 400, + 630, - 400,
+ 628, - 1366, + 680, - 376, + 628, - 1372, + 654, - 1366,
+ 658, - 400, + 628, - 402, + 628, - 398, + 630, - 400,
+ 630, - 398, + 654, - 374, + 630, - 402, + 628, - 400,
+ 628, - 1366, + 658, - 1366, + 658, - 1370, + 656, - 1366,
+ 660
uint16_t rawData[233] = {750, 17860, 3150, 8840, 682, 374, 652, 1346, 682, 378, 650, 376, 652, 376, 652, 378, 652, 376, 652, 376, 654, 374, 654, 1340, 682, 376, 652, 378, 650, 1344, 658, 1364, 682, 380, 652, 1346, 680, 1344, 682, 1342, 684, 1340, 682, 1344, 680, 380, 650, 376, 652, 376, 650, 382, 652, 376, 652, 378, 652, 376, 628, 400, 652, 378, 652, 376, 652, 376, 652, 376, 652, 376, 650, 376, 624, 406, 652, 378, 652, 374, 628, 402, 652, 376, 652, 376, 628, 404, 652, 376, 628, 398, 628, 402, 652, 376, 628, 400, 628, 402, 652, 376, 652, 374, 652, 378, 628, 400, 650, 376, 652, 378, 628, 400, 628, 1366, 680, 1348, 656, 2828, 3082, 8874, 684, 1342, 682, 376, 628, 400, 630, 402, 652, 376, 628, 398, 652, 378, 628, 400, 650, 376, 652, 1346, 658, 400, 628, 400, 628, 402, 628, 1368, 680, 1342, 680, 1348, 656, 1368, 656, 1368, 656, 1370, 658, 1366, 658, 1366, 682, 1344, 658, 1366, 658, 1366, 658, 1368, 658, 400, 628, 400, 628, 402, 630, 1366, 656, 1366, 682, 1346, 656, 400, 628, 398, 628, 404, 654, 374, 628, 400, 650, 380, 628, 400, 628, 400, 630, 400, 628, 1366, 680, 376, 628, 1372, 654, 1366, 658, 400, 628, 402, 628, 398, 630, 400, 630, 398, 654, 374, 630, 402, 628, 400, 628, 1366, 658, 1366, 658, 1370, 656, 1366, 660}; // SAMSUNG_AC
uint8_t state[14] = {0x02, 0xB2, 0x0F, 0x00, 0x00, 0x00, 0xC0, 0x01, 0xE2, 0xFF, 0x71, 0x00, 0x0D, 0xF0};
In both cases the IRrecvDumV2 detects the power status either On or Off but the code length sent by the Original Samsung Remote is not the same one sent by the ESP8266 IRTX.
I didn't tried it yet on a proper Samsung AC Split for now, will try it soon but i just noticed this difference of the IR code transmitted between the Samsung remote and ESP8266 IRTX.
Thank you
Hollako
on 26 Sep 2018
Two things:
1) Can please ensure you've git pulled the latest in that branch? I think you might be slightly behind.
2) Can you list the code you are using to send the on/off message? If you are doing it from inside the IRSamsungAC class via the send() method, then it isn't going to work. That only sends the 112 bit message at present.
For now, you'll need to do:
uint8_t state[21] = {0x02, 0xB2, 0x0F, 0x00, 0x00, 0x00, 0xC0, 0x01, 0xD2, 0x0F, 0x00, 0x00, 0x00, 0x00, 0x01, 0x02, 0xFF, 0x71, 0x80, 0x11, 0xC0}; // Taken from your Original Remote "Power off" above.
irsend.sendSamsungAC(state, 21); // Note: 21, not the usual 14.
Well Done !!
What i did is when i want to send the power state, i send irsend.sendSamsungAC(stateon, 21) or irsend.sendSamsungAC(stateoff, 21). and the stateon or stateoff are 2 unit8_t constants defined at the beginning of the sketch.
And when i want to send the rest of the commands i use IRSamsungAc.send().
It working perfectly with the IRrecvDumpV2, hopefully today i will try it with a real Split Samsung AC to confirm 100% that Samsung AC codes are fully functional.
Thank you for your effort and support.
Hollako
on 26 Sep 2018
Glad it's working for you.
Just added an IRSamsungAc.sendExtended() method to the class in that branch.
It should send a message equiv of irsend.sendSamsungAC(internal_state) but as irsend.sendSamsungAC(internal_state, 21), all from within the class.
crankyoldgit
on 26 Sep 2018
Yes, the real tests are on the actual device itself. Looking forward to the results.
crankyoldgit
on 26 Sep 2018
Hello Again,
I could test the IR codes on a Split Samsung AC and i got a half success result unfortunately.
Only Power Off and On commands are working. All the rest is not working, noting that exactly the same code received from the Samsung AC remote i could receive them via the ESP8266 using the IRrecvDumpV2, exactly same Hex Code received. Really weird and couldn't understand why.
Power On and Off using the irsend.sendSamsungAC(stateon, 21) command while the rest i used IRSamsungAc.send(). Is there any difference between them, maybe you did some improvements and i used the last revision before you added IRSamsungAc.sendExtended(). Do you think that these improvements solved the issue cause i didn't use the IRSamsungAc.sendExtended().
Any advise please ?!?
A small note David my name is Hollako not Hallako, i noticed that you mentioned someone else in
[https://github.com/markszabo/IRremoteESP8266/pull/529]
Regards,
Hollako
on 28 Sep 2018
First off, sorry for the typo in your name. My bad. Fixed.
Is there any difference between them? [edited]
Yes. irsend.sendSamsungAC() differs from IRSamsungAc.sendExtended() & IRSamsungAc.send() in the former case does not try to construct a state/settings, it only uses a captured state you've recorded. The latter two both try to build a completely new state/settings from scratch.
It's most like that the building from scratch part is not working properly yet.
Do you think that these improvements solved the issue cause i didn't use the IRSamsungAc.sendExtended().
No. sendExtended() is only for those messages which produce a state[21], not a state[14].
Any advise please ?!?
As I don't have access to the remote (but you do ;-), I need to you capture some messages using the dev code & the original remote, and report what the full state[]s are for them, and exactly what all of the settings are set on the remote for each one. We don't need the rawData lines. Just the state lines.
Sort of like what you did for the original spreadsheet, however this time all the numbers have changed.
Note: This is separate from what I'm asking you to do below, but do the below stuff first, if that's wrong we have more fundamental problems. The above bit is for making sure we are able to do custom state creation correctly.
I can then try to construct completely synthetic versions (i.e. changing the settings of the A/C via setMode() etc) to see if I can get it to produce the same state[] code.
In the meantime, there are some other things you can do to help test to see if it is a different problem.
1) Capture your desired settings (not for one of the power on/off extended sequences, just a normal '14' length setting), and write down ALL the settings on the remote.
2) Then try something like:
uint8_t the_state_you_just_collected[14] = {0x02, 0x92, 0x0F, 0x00, 0x00, 0x00, 0xF0, 0x01, 0x02, 0xAF, 0x71, 0x80, 0x11, 0xF0};
irsend.sendSamsungAC(the_state_you_just_collected);
If that works, then we know sending "normal" codes should work.
3) Then try something like:
uint8_t the_state_you_just_collected[14] = {0x02, 0x92, 0x0F, 0x00, 0x00, 0x00, 0xF0, 0x01, 0x02, 0xAF, 0x71, 0x80, 0x11, 0xF0};
IRSamsungAc sammy(IR_PIN_YOU_ARE_USING_TO_SEND_ON); // Creates the class and which pin to use.
sammy.begin(); // Set everything up so we can start.
sammy.setRaw(the_state_you_just_collected); // Set the internal state of the class to be what you captured.
sammy.send(); // Send the new internal state as a IR message.
In theory, they should all produce the same result. i.e. Doing what ever the collected state/message from the remote was.
If none of those work, then there is probably something wrong in our understanding of the protocol, and we'll need to go back to the rawData captures and frequencies etc.
If some of those work, it will confirm we understand the basic protocol (timings/freq etc) and will help point out what may be wrong.
crankyoldgit
on 29 Sep 2018
@Hollako I've updated the samsung-ac-fixes branch, but I doubt any of the changes I've added/made will affect the usage.
Of the limited data I have from your spreadsheet (I had to use the raw data for some message, and even then the description for the message really doesn't match up with the data. i.e. Please be 100% sure what the settings are for the state[]s you give above. i.e Double check or triple check.
I've tried constructing messages from _new_, and it seems to work. EXCEPT for the issue I've asked you to look into previously. i.e. the lowest bit in the swing byte (state[9]) changes, and doesn't have an explanation e.g. Sometimes 0xAE or 0XAF for swing move etc.
Some of your captures have it as 1 (0xF) or sometimes it's 0 (0xE).
Other than that, my tests as they are seem to all check out. So, the ball is now firmly in your court for more testing and data.
crankyoldgit
on 29 Sep 2018
Hello,
Hopefully by tomorrow i will do some test on the real Samsung AC split.
But the thing that i don't understand is that in the IRrecvDumpV2 the codes sent y the Samsung AC and the codes sent by the ESP8266 are typically the same.
So what make the codes from Samsung AC work and the ones from the ESP8266 don't. If the same HEX numbers is generated from both are typically the same !!
Hollako
on 30 Sep 2018
The devil is in the details. Also, typically is not good enough, they need to be the same for the device to be 100% certain the unit will accept it. i.e. a single bit off could cause the programming in the AC unit to reject it.
Reasons why the real remote might be working and the ESP8266 not, because there could be other factors involved.
i.e. We may have the frequency wrong. We might be missing some of the message. The duty cycle of the LED might not be 50% on/50% off. It may any one of these features.
I'm pretty confident that the frequency is okay, and normally the duty-cycle never affects anything. So, that leaves "the wrong bits" or "we are missing part of the message" as the likely candidates.
crankyoldgit
on 30 Sep 2018
Hello,
I was decoding the IR codes with the latest Samsung AC library and i noticed that the bits are not the same ones that i decoded previously. and the HEX codes that was issued from the IRrecvDumpV2 are not the same as well. For example i had a fix sequence in all the codes which was 4049F000000003 now it's 02920F000000F00 so now the bits numbers are not the same as the previous ones. it's like inverted. for example the temp 24 was 0001 now it's 1000 and even the bits number is not same.
So now I am working on a totally new spread sheet based on the latest library. And hopefully this should solve the problem.
By the way the byte 9 what was confusing us regarding the Swing mode now i got the explanation. and it's true that the Swing mode change the byte 9 between A and F.
Hollako
on 1 Oct 2018
@Hollako Yes. I have said this a number of times, when we changed to LSBF ordering of the data, the bit patterns/bytes will have changed. Basically as you indicated, they (the bits) are all flipped (order) for each byte. Sorry.
So, yes. Please use the new data format. It will save me having to convert to your one-off system all the time. Oh, and as with other spreadsheets for this sort of thing, I recommend the free Google Sheets spreadsheets as it's web based, no download, and updated in real-time, and if you set the options, people can comment on it directly etc. It's great for collaboration.
By the way the byte 9 what was confusing us regarding the Swing mode now i got the explanation. and it's true that the Swing mode change the byte 9 between A and F.
Yes, but there is also another bit that changes that you haven't explained that seems linked to Swing some how.
crankyoldgit
on 1 Oct 2018
Hello,
Sure i will adopt Google Sheet.
Regarding the swing other bits, they are the Checksum. The bits of checksum and Swing are close to each other.
Will upload the sheet once ready !!
Hollako
on 1 Oct 2018
I'll reiterate what I said earlier:
Byte 8 contains the checksum, so you can ignore that change.
But byte 9 changes from 0xAF (On) to 0xFE (Off). The first nibble (top 4 bits) of each byte (A/on and F/off respectively) is explained by your spreadsheet/comments about how swing works. However the lowest bit of that byte (Your bit 40) changes. i.e. F to E)
@Hollako You need to explain that.
The checksum is in a different byte. Yes, it's close, but no, I don't think it's the checksum that is changing it. That doesn't seem to fit with the checksum alg. But hey, it could be an overflow. It would be very very odd for it to be though. I've never seen an A/C protocol have a checksum that extends into another byte. But there is always a first time potentially. ;-)
crankyoldgit
on 1 Oct 2018
Hello David,
here is below the link for the new spread sheet, you can find the Summary Rev.1, Code Rev.1 and Power Code Rev.1 sheets which are the updated ones.
https://drive.google.com/drive/folders/11P3DhyQz7O1-d74jNk1Q5rgmrh4DMw50?usp=sharing
As well i uploaded a word file whee i copied all the results received form the IRrecvDumpV2.
Regarding Swing, actually 3 bits are changed from On or Off, 111 for Off and 010 for On. Byte number 10 A for On and F for Off. And these are the only bits (other than the checksum) that are changing between Swing On and Swing On. Please find it in the Code Rev.1 Sheet I have Rows 18 and 19 where is only changed the Swing mode.
thank you,
Hollako
on 1 Oct 2018
Hey @Hollako, I've converted that spreadsheet to a Google Docs/sheets spreadsheet, given you edit access, and allowed everyone with the link to view it.
That link is: https://docs.google.com/spreadsheets/d/1SlqxuxZpj8TwsZ4lNE5pXCtDx770DGWgN5Yb2aqlgD4/edit?usp=sharing
crankyoldgit
on 2 Oct 2018
Similarly, here is the Google Doc equivalent of the docx file: https://docs.google.com/document/d/1Sm9azPX9L38OYWIr1PrSEq8YrpN5r3F6kj_6XntmCsA/edit?usp=sharing
crankyoldgit
on 2 Oct 2018
And these are the only bits (other than the checksum) that are changing between Swing On and Swing On. Please find it in the Code Rev.1 Sheet I have Rows 18 and 19 where is only changed the Swing mode.
If you go to the spreadsheet, in the 'Raw' tab/sheet, on row 19 (I've highlighted in in the Google Sheets version) it has another bit that changes.
I've used two raw samples from that tab/page to use as unit test data.
See:
https://github.com/markszabo/IRremoteESP8266/blob/samsung-ac-fixes/test/ir_Samsung_test.cpp#L813
&
https://github.com/markszabo/IRremoteESP8266/blob/samsung-ac-fixes/test/ir_Samsung_test.cpp#L854
i.e.
The decode from the raw data you collected to:
Example 1 which is derived from Row 19 of the 'Raw' tab:
uint8_t expectedState[kSamsungAcStateLength] = {
0x02, 0x92, 0x0F, 0x00, 0x00, 0x00, 0xF0,
0x01, 0x02, 0xAF, 0x71, 0x10, 0x41, 0xF0};
and Example 2 which is derived from Row 7 of the 'Raw' tab:
uint8_t expectedState[kSamsungAcStateLength] = {
0x02, 0x92, 0x0F, 0x00, 0x00, 0x00, 0xF0,
0x01, 0xE2, 0xFE, 0x71, 0x40, 0x11, 0xF0};
The bytes we are interested in/talking about are expectedState[9]. i.e. the 10th byte (or 9th when counting from zero)
They differ. e.g. 0xAF vs 0xFE. The upper half of they bytes (0xA0 & 0xF0) are explained by your spreadsheet. They are the swing state changing. That part is okay. It's the lower half (0x0F & 0x0E) that are different and require explanation.
I think there are other examples in the raw data you provided.
I've tried to document this as clearly and succinctly as possible here:
https://github.com/markszabo/IRremoteESP8266/blob/samsung-ac-fixes/src/ir_Samsung.cpp#L387
and here: https://github.com/markszabo/IRremoteESP8266/blob/samsung-ac-fixes/src/ir_Samsung.cpp#L393
i.e. Sometimes the swing byte changes for "swing move" not like you've explained.
Yes, all the data in your 'Swing" tab/page is consistent with your description, it's just not all the data you provided is consistent.
The byte that stores the checksum is: expectedState[8]`. i.e. the 9th byte, ((or 8th when counting from zero)
Sidenote:
FYI, you should really number the bits from the start to the end of the code, not from end of the code to the start.
crankyoldgit
on 2 Oct 2018
FYI, the fixes thus far have been included in v2.5.1 that I just released.
crankyoldgit
on 2 Oct 2018
Hello David,
Sorry for the late reply, but didn't have time till today to try the latest release.
At last i can say clearly that everything work perfectly including the swing On and Off.
So Samsung AC IR codes are fully supported now.
Thank you very much.
Hollako
on 6 Oct 2018
Okay. If you say both sending and receiving with swing etc is all working fine, I'll mark it closed. But I am concerned about that unexplained bit change. i.e. https://github.com/markszabo/IRremoteESP8266/issues/505#issuecomment-426108102
crankyoldgit
on 7 Oct 2018
Hello David,
I still have a doubt that something is wrong with the swing bits. You mentioned in the 2 Rows that you highlighted it that there is another bit is changing. But these 2 raws was related to the old decoding where i was working on MSB sequence. So this sheet is not valid anymore with the new sequence.
Am totally sure that the swing mode affecting only 1 byte. which is byte N° 10. When it's Off this byte is 1111 which is F and when is On this byte is 1010 which is A. True that 2 bits are changing but both are related to Swing mode only.
Else if i still don't get your point.
Hollako
on 8 Oct 2018
@Hollako per https://github.com/markszabo/IRremoteESP8266/issues/505#issuecomment-426108102
I.e. please re-read it again, then read this, then read that comment again.
The states/data for what I am talking about comes from the RAW data you collected, That's before any MSB/LSB bit ordering analysis. i.e. Your spreadsheet has nothing to do with the analysis of that data anymore. I'm using your "original" recording. So, trust me. The data (state) is correct and independant of your spreadsheet analysis & bit ordering/sequencing etc.
Yes, we all agree that swing is off when it's F, and on when it's A. We are not talking about those four bits, I'm talking the other half of the byte. There are 8 bits in a byte. For those given states, the OTHER half of they byte has a change too. Not just the A & F section of the byte.
So, just assume that the state[] data I'm using is correct.
For most of the cases you originally provided, the byte that controls the _swing_ is either 0xAE for on, and 0xFE, for Off. However, your RAW data (as in what was recorded by the rawData line in your IRrecvDumpV2 captures and placed as comma separated values in your raw table in the spreadsheet) occasionally has the _swing_ byte as 0xAF (instead of the usual 0xAE) for on, and 0xFF (instead of the usual 0xFE) for off.
To put it bluntly, there is something else changing in that byte. Not just those "two bits" and not just the Most significant four bits. There is a _third_ bit that is also changing, in the same byte.
crankyoldgit
on 9 Oct 2018
Closing this issue as it seems stale. Reply and I'll reopen etc.
crankyoldgit
on 26 Oct 2018
i am very much interested to do it...I need the sample code for esp8266.. link which you mentioned in github is not opening. kindly send me the link of the file if possible. Thanks in advance.
yogesh102011
on 23 Nov 2018
@yogesh102011 The code was merged in to the master branch and has been included in the released versions of the library ever since v2.5.1.
You can see the final code mentioned earlier here: https://github.com/markszabo/IRremoteESP8266/blob/master/src/ir_Samsung.cpp
https://github.com/markszabo/IRremoteESP8266/blob/master/src/ir_Samsung.h
&
https://github.com/markszabo/IRremoteESP8266/blob/master/test/ir_Samsung_test.cpp
crankyoldgit
on 23 Nov 2018
Thank you very much for your immediate reply
On Fri, Nov 23, 2018 at 11:10 AM David Conran notifications@github.com
wrote:
@yogesh102011 https://github.com/yogesh102011 The code was merged in to
the master branch and has been included in the released versions of the
library ever since v2.5.1.You can see the final code mentioned earlier here:
https://github.com/markszabo/IRremoteESP8266/blob/master/src/ir_Samsung.cpp
https://github.com/markszabo/IRremoteESP8266/blob/master/src/ir_Samsung.h
&https://github.com/markszabo/IRremoteESP8266/blob/master/test/ir_Samsung_test.cpp
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/markszabo/IRremoteESP8266/issues/505#issuecomment-441159714,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Aj2NWVaJ5pP1lFIbB7tj-yo2PN6ideghks5ux4pkgaJpZM4WM1c8
.
yogesh102011
on 23 Nov 2018
@crankyoldgit : Great work!!!! everything seems to be working fine with the code. But I have a small issue. I am trying to send the raw codes directly to control the Samsung AC. I am able to switch ON and change the temperatures but I am unable to switch OFF the AC using raw codes. Any advise??
I am sending the below Raw code for switching off:
uint16_t rawData[231] = {3200, 9366, 516, 1500, 538, 560, 534, 558, 550, 546, 556, 538, 534, 560, 534, 558, 536, 560, 536, 560, 534, 1498, 536, 560, 534, 558, 536, 1496, 536, 558, 536, 1496, 538, 1496, 538, 1496, 538, 1496, 538, 1496, 538, 1496, 564, 532, 536, 560, 534, 558, 536, 560, 536, 558, 536, 560, 536, 558, 560, 534, 536, 558, 536, 560, 536, 558, 536, 560, 536, 560, 534, 560, 534, 558, 536, 560, 560, 534, 536, 560, 536, 558, 536, 560, 536, 558, 536, 560, 536, 558, 560, 536, 560, 532, 536, 558, 536, 558, 536, 560, 560, 532, 536, 560, 536, 558, 560, 534, 536, 558, 560, 536, 560, 532, 560, 534, 562, 5434, 3168, 9346, 540, 1496, 538, 560, 552, 542, 536, 558, 538, 558, 536, 560, 536, 558, 560, 534, 536, 558, 536, 1494, 538, 560, 560, 534, 560, 534, 560, 532, 536, 560, 536, 558, 536, 1494, 538, 1496, 538, 1496, 538, 1496, 536, 560, 538, 1494, 538, 560, 536, 1494, 538, 1496, 538, 558, 536, 558, 536, 558, 536, 558, 536, 558, 556, 540, 536, 1494, 538, 1496, 538, 560, 536, 558, 562, 534, 536, 1496, 536, 560, 536, 1494, 538, 1496, 538, 1494, 538, 558, 538, 1494, 538, 560, 538, 1492, 538, 560, 536, 558, 536, 558, 536, 558, 536, 558, 536, 558, 536, 558, 562, 532, 536, 558, 536, 1496, 536, 1498, 538}; // VESTEL_AC FD201
Thanks in advance.
rsandkumar
on 12 Oct 2019
- Without seeing the rest of the code, I can't be sure. i.e. Are you sending it at 38kHz and all 231 values?
- Please create a new issue rather than piggy backing on an existing _closed_ issue.
Sending raw codes _should_ work if you've captured them correctly and are using the correct frequency.
crankyoldgit
on 13 Oct 2019
Related issues
jlhavens
·
7Comments
NewUser9
·
6Comments
andreimos
·
3Comments
the-mentor
·
5Comments
wahibmichael
·
4Comments
Most helpful comment
Hello David,
Here is below the decoding received in the
IRrecvDumpV2:Swing On:
Swing Off:
And Regarding the power codes i noticed that the timing is not same as the other codes during Power On and the bits also are not same, didn't noticed this difference before.
Power On:
Power Off: