Support for Samsung AR12TXEAAWKNEU

[xorbital]

Version/revision of the library used

Latest dev (bfa5201)

Actual behavior

I'm trying to use this library, more specifically the MQTT server example with my AC, however this fails.
It works for the most part with the ControlSamsungAC example, however using the mqttserver doesn't work. The reason is that (I've confirmed this with ESPEasy) some of the commands seem to differ.
Example: Sending "Cool, 22°C, Fan Auto" works, but sending "Cool, 22°C, Fan Auto, Beep on" seems to break the protocol, since the A/C doesn't do anything when sending this command.

The model is a Samsung AR12TXEAAWKNEU.

Circuit diagram and hardware used (if applicable)

The one from the wiki with a 1 Ohm resistor added in series with the LED, works.

I have followed the steps in the Troubleshooting Guide & read the FAQ

Yes.

Other useful information

It's a bit tricky. Have a look at the remote:

There are a lot of buttons, but those actually do nothing on my unit:

• Purify
• Indirect / Direct

This is intended as stated in the manual for the A/C, seems like other models have different feature combinations then.
I've captured a lot of IR codes with the arduino-heatpumpIR library and decoded the signal as far as I could, is this applicable to this library as well? If not, I'll create some dumps with your tools, which ones would make the most sense?
This is what I could get, it is the command for Cooling, 16°C, Windfree (Fan Auto):
02,92,0F,00,00,00,F0,01,D2,FE,7B,00,11,F0

02 - ??
92
  9 - Quiet mode: 8: quiet / special, 9: normal
  2 - ?
0F - ??
00
  0 - 0: normal, 1: indirect, 2: direct
  0 - ??
00 - ??
00
  0 - Beep, 0: off, 2: on
  0 - ?
F0 - ??
01 - ??
D2 - Checksum 
FE
  F - Swing: A: vertical, B: horizontal, C: vertical+horizontal, F: off
  E - Not sure; F:swing, E: no swing, also E: 17-30°C, F: 16°C
7B
  7 - options? 7: normal, 6: Display off, E: Clean
  B - B: Windfree, 1: normal, 7: Fast, F: ECO
00
  0 - temperature (0: 16°C bis E: 30°C), always 8 in Fan Mode, when selecting "Fast" the last set temperature is sent
  0 - ?? 0: (normal), [1: purify] 2: clean
11
  1 - Mode; 1: Cool, 2: Dry, 3: Fan, 4: Heat, 8: Auto
  1 - Fanspeed; 1: Auto, 5: Low, 9: Medium, B: High, F: Turbo
F0 - ??

Some bytes change without making too much sense to me, like F after the checksum controls the swing, but E is also there when the temp. is set to 16°C, weird.
Some combinations of commands are invalid, like setting a high fan speed in dry mode. Also, as you might see there's horizontal swing in this unit as well.
Turning the unit on or off results in a longer chain off commands, which include timer information, haven't taken a look at that yet.

Let me know what additional information I can provide, I'll have a look in a day 👍

[crankyoldgit]

I've captured a lot of IR codes with the arduino-heatpumpIR library and decoded the signal as far as I could, is this applicable to this library as well? If not, I'll create some dumps with your tools, which ones would make the most sense?

Dunno. Maybe. Please use data captures using our tools. e.g. IRrecvDumpV2 or V3.

Samsung's protocol has been tricky for us to work out & support. There are certainly aspects of it we don't understand.

Our existing "Beep" byte is in byte[13] (the last byte), where as you report it as in byte[5], yet your temperature share the same byte as in our support. That is byte[11]

This indicates where there is a good overlap of the existing model support, but they do differ.
We are going to need to work out how we can detect the model difference from a raw incoming IR signal some how.

For reference, here is the Issue/thread for adding Samsung A/C support (#505) .. as you'll see, it's a mess.

If you can express your finding & data in a Google Spreadsheet, that'd be great/handy/helpful to get it supported.
See https://github.com/crankyoldgit/IRremoteESP8266/wiki/Adding-support-for-a-new-AC-protocol

[xorbital]

Thank you for your quick answer 🙂
I've pointed my remote at the IR receiver, but I could only pick up UNKNOWN codes, no matter the mode.
I've played around with the DumpV2 and DumpV3, changed kTimeout and kMinUnknownSize, however no luck sadly.

After a bit more testing it seems like the beep command is not even persistent, and just toggles the state of it in the A/C.

I took a look at #505, yeah, looks like it 🙁

Since I only got "UNKNOWN" as a result, is this of any use? I can expand it if it is: https://cryptpad.fr/sheet/#/2/sheet/view/e1PSfhwjfTGCAPbse4h28RjvvG+YCiLgH3SxhxTNFQQ/

[crankyoldgit]

@xorbital After looking at the raw data (e.g. Row 5 of your spreadsheet) and doing a lot of debugging, I was able to find out that your "raw data" is terribly out of spec/tolerance for the library to match it by default.
I was able to get it to match at a value of 40%. e.g. irrecv.setTolerance(40); or change:

IRremoteESP8266/src/IRrecv.h

Line 35 in bfa5201

const uint8_t kTolerance = 25; // default percent tolerance in measurements.

See f3b4d75 for more details.

There are a number of things that could cause this (in no particular order):
a) Low batteries in the remote. (Possible)
b) Environmental noise. (Unlikely)
c) Your A/C remote is just old/out of spec/poor etc. (Possible)
d) The hardware IR demodulator you are using is not of sufficient quality. (Likely)
e) You're running something else on the ESP chip that is bogging it down. (Unlikely)
f) The distance you're capturing it at is too short/long etc. (Possible)

Anyway, there is nothing in the library that needs fixing. The protocol isn't a new variant, and it does "match" with a lot of coercion.

You've at least got a software-only settings change solution to your issue. Good luck.

[xorbital]

@crankyoldgit Thank you very much!

a) Probably not, the remote works across the whole room and it doesn't show a battery warning.
b) Unlikely as you said, I've tried receiving while it was inside a box, so completely dark, didn't get anything different
c) The A/C is one of the most recent models, highlighted by the fact that it can only use the glorious smartthings cloud instead of a local API. Maybe they did something crazy to the IR protocol..
d) Yeah, this could be it. I'll order a new one and report back. Any suggestions?
e) Not that I know of, I can swap it for a ESP32 for testing and report back.
f) Alright, I'll try some distance changes, guess I buy a new demodulator first.

In the meantime I will try receiving codes with the tolerance change you've suggested. There are probably still issues with the data since sending is inconsistent.

[xorbital]

So, decoding is still not great, setting the tolerance to 40-55% helps, but power on and power off commands can't be decoded 95% of the time. However, since the other commands work most of the time, I've found the output to be identical to what https://github.com/ToniA/Raw-IR-decoder-for-Arduino gives me, interestingly that works, it can't decode all commands, but spit out the hex values of the bytes themselves.
It's probably some weird hardware issue on my side, since this runs on an arduino (same cheap IR receiver), I'll test further. However, I can confirm that the data in the first post is correct, dumpv3 and rawirdecode output the same for a command like the one mentioned in the first post.
Still, I have to take a look at the stuff that's sent when pressing the power button, here's an example of "Cool, 22°C, Fan Auto":

02,92,0F,00,00,00,F0,01,D2,FE,71,60,11,F0

This is the stuff that's sent when pressing the button to turn it off now:

02,B2,0F,00,00,00,C0,01,D2,0F,00,00,00,00,01,F2,FE,71,60,11,C0

And turning it back on:

02,92,0F,00,00,00,F0,01,D2,0F,00,00,00,00,01,D2,FE,71,60,11,F0

Taking a closer look:
"Normal": 02,92,0F,00,00,00,F0,01,D2,FE,71,60,11,F0
Power off: 02,B2,0F,00,00,00,C0,01,D2,0F,00,00,00,00,01,F2,FE,71,60,11,C0
Power on: 02,92,0F,00,00,00,F0,01,D2,0F,00,00,00,00,01,D2,FE,71,60,11,F0

The longer commands also get sent when setting a timer, here's the same setting with a timer of 0.5h to turn the A/C off:

02,92,0F,00,00,00,F0,01,A2,3F,00,00,04,00,01,D2,FE,71,60,11,F0

Increasing the timer one step at a time:

02,92,0F,00,00,00,F0,01,B2,8F,00,00,04,00,01,D2,FE,71,60,11,F0
02,92,0F,00,00,00,F0,01,92,BF,00,00,04,00,01,D2,FE,71,60,11,F0
02,92,0F,00,00,00,F0,01,B2,0F,01,00,04,00,01,D2,FE,71,60,11,F0
02,92,0F,00,00,00,F0,01,92,3F,01,00,04,00,01,D2,FE,71,60,11,F0
02,92,0F,00,00,00,F0,01,A2,8F,01,00,04,00,01,D2,FE,71,60,11,F0

Can this library work with those codes? If so, I'll continue decoding everything into a spreadsheet, since there are definitely differences to the other Samsung AC protocols 🙂

[crankyoldgit]

Glad you got it some-what working.

SamsungAC, as I indicated earlier, is a mess. It is one of, if not the protocol we've had most trouble with.

To answer some of your questions:

Yes, it can handle the "extended"/long codes.
e.g.

uint8_t long_state[kSamsungAcExtendedStateLength] = [0x02, 0x92, 0x0F, 0x00, 0x00, 0x00, 0xF0, 0x01, 0xA2, 0x8F, 0x01, 0x 00, 0x04, 0x00, 0x01, 0xD2, 0xFE, 0x71, 0x60, 0x11, 0xF0];
irsend.sendSamsungAC(long_state, kSamsungAcExtendedStateLength);

There is limited support for these "extended" messages in the IRSamsungAC class.

The biggest hold-back from the library working with the "extended" messages (i.e. Power on/off, & timer etc) is we've been unable to consistently determine/replicate the checksum calculation for them. The "normal" ones, we've got worked out mostly. Extended, well, I've wasted far too many hours and had no success. Solve that issue, and we can look at those messages.

The library uses custom "known good" values for sending the on & off extended messages at present when sending via the class method.
See:

IRremoteESP8266/src/ir_Samsung.cpp

Lines 383 to 407 in bfa5201

	/// Send the special extended "On" message as the library can't seem to
	/// reproduce this message automatically.
	/// @param[in] repeat Nr. of times the message will be repeated.
	/// @see https://github.com/crankyoldgit/IRremoteESP8266/issues/604#issuecomment-475020036
	void IRSamsungAc::sendOn(const uint16_t repeat) {
	const uint8_t extended_state[21] = {
	0x02, 0x92, 0x0F, 0x00, 0x00, 0x00, 0xF0,
	0x01, 0xD2, 0x0F, 0x00, 0x00, 0x00, 0x00,
	0x01, 0xE2, 0xFE, 0x71, 0x80, 0x11, 0xF0};
	_irsend.sendSamsungAC(extended_state, kSamsungAcExtendedStateLength, repeat);
	_lastsentpowerstate = true; // On
	}
	/// Send the special extended "Off" message as the library can't seem to
	/// reproduce this message automatically.
	/// @param[in] repeat Nr. of times the message will be repeated.
	/// @see https://github.com/crankyoldgit/IRremoteESP8266/issues/604#issuecomment-475020036
	void IRSamsungAc::sendOff(const uint16_t repeat) {
	const uint8_t extended_state[21] = {
	0x02, 0xB2, 0x0F, 0x00, 0x00, 0x00, 0xC0,
	0x01, 0xD2, 0x0F, 0x00, 0x00, 0x00, 0x00,
	0x01, 0x02, 0xFF, 0x71, 0x80, 0x11, 0xC0};
	_irsend.sendSamsungAC(extended_state, kSamsungAcExtendedStateLength, repeat);
	_lastsentpowerstate = false; // Off
	}

[crankyoldgit]

b) Unlikely as you said, I've tried receiving while it was inside a box, so completely dark, didn't get anything different

Unless the box is quite big, it was probably too close. About 1 meter is probably optimal. Less than 30cm and I've seen problems with some demodulators.

d) Yeah, this could be it. I'll order a new one and report back. Any suggestions?

Don't get a VS1838b. See/read: https://github.com/crankyoldgit/IRremoteESP8266/wiki/Frequently-Asked-Questions#help-im-getting-very-inconsistent-results-when-capturing-an-ir-message-using-a-vs1838b-ir-demodulator

Read the discussions there in. See also: https://www.analysir.com/blog/2014/12/08/infrared-receiver-showdown-tsop34438-vs-vs1838b-winner-revealed/

[xorbital]

The library uses custom "known good" values for sending the on & off extended messages at present when sending via the class method.

Ah that makes sense, since I've seen my A/C turn on to 24°C before switching to the set temperature.
What I've also noticed is that the "Power On" message actually isn't necessary for my unit (don't know if that's true for other ones as well?)
So just sending the short commands also turns on the A/C, no matter what.
Turns out the one I have actually is a VS1838B, although I always used 5V for it. While I wait for a better one to arrive, it seems to work consistent with my setup now.

I'll take a look at the checksum calculation soon, in the meantime I'll create a spreadsheet with all the other commands I could decode so far.

Thank you for your time 👍

[crankyoldgit]

Turns out the one I have actually is a VS1838B, although I always used 5V for it. While I wait for a better one to arrive, it seems to work consistent with my setup now.

Be careful if you use it on an ESP32. 5V in via a GPIO can kill the ESP. The 8266 can take 3.3/5V input. The 32 can't.

[xorbital]

Yes, I read that in the FAQ. Again, decoding works with the arduino for now, sorry for wasting your time with that.
Still, the main issue is that sending doesn't work since the data is different, so I'll continue capturing that.

[xorbital]

I think that's all: https://cryptpad.fr/sheet/#/2/sheet/view/REURkHbGuQdU+wQkBcwKBXmccftjIB+Tyzin34EXs-g/

EDIT: Not sure about Power on/off, however this unit can be powered on and off without long messages.

Gonna take a look at the long codes and the checksum issues next.

[crankyoldgit]

EDIT: Not sure about Power on/off, however this unit can be powered on and off without long messages.

Ooo. That's an interesting development! Can you supply a kSamsungAcStateLength (i.e. not extended) hex/state code for some other users to try to see if the shorter "off" code works for them too?

[xorbital]

Ooo. That's an interesting development! Can you supply a kSamsungAcStateLength (i.e. not extended) hex/state code for some other users to try to see if the shorter "off" code works for them too?

I'll have a look into it! The trick is to cover the LED of the remote, turn it on, uncover it and then set it to the setting you want. This sends out a short signal, but it turns on the A/C.
Similarly, if you turn off the remote while covering it, you'll block the long signal, however if you then set a timer and then unset it, it will send out a short command that will turn it off. This might be possible with other units as well.

[crankyoldgit]

FYI, the changes mentioned above (i.e. the additional unit tests) have now been included in the new v2.7.11 release of the library.

[xorbital]

Nice. Still probably due to my shitty IR decoder. I'll run a few sending tests now so that I can finish up the short codes.

[xorbital]

@crankyoldgit I've run a few tests, sending codes and receiving. I can confirm this is how my A/C works with short codes: https://cryptpad.fr/sheet/#/2/sheet/view/REURkHbGuQdU+wQkBcwKBXmccftjIB+Tyzin34EXs-g/

The trick to get the short codes for turning the A/C off is to:

• Turn the A/C off with the remote
• Set a timer on the remote (e.g. on in 0.5h)
• Change the settings to which the A/C should wake up to (e.g. reduce the temperature)

This sends out a short code which will turn off the A/C. Some features are ignored when sending the power off command, like fan speed and swing, but since the unit is off I don't think that matters.
Again, for my unit, you don't need long codes at all. Maybe someone with a different model can test this behaviour with their own unit as well. The long codes are used for timers only and the "good' sleep" function, which regulates the temperature while sleeping. Neat idea, doesn't work well though, so I wouldn't really miss it.

Is there anything else I should provide?

[crankyoldgit]

When PR #1554 is merged, we should be able to use custom extended/long Samsung messages. So we me able re-visit this issue soon.

[crankyoldgit]

@xorbital I've created branch https://github.com/crankyoldgit/IRremoteESP8266/tree/samsung_timers / PR #1662 which should add the On & Off timers. Please download and test etc. Let me know how it goes.
I'll add the Sleep stuff in a later commit to that branch.
It's not super covered with unit tests yet, but it probably works. Should work for decoding via IRrecvDumpV3 etc.
Sending is currently untested.

[crankyoldgit]

@xorbital Can you please supply your remote model number if you can find it?

[crankyoldgit]

And now that branch should also have sleep timer support. Please test etc etc.

I think that's it. Is there anything else I needed to add?

[xorbital]

@xorbital Can you please supply your remote model number if you can find it?

The model number is "DB96 24901C", seems like there are multiple variants with and without windfree mode, that's the one I have.

Thank you very much for your time, I'll be testing in a few hours.

[crankyoldgit]

The model number is "DB96 24901C"

Thanks. Added.

[xorbital]

And now that branch should also have sleep timer support. Please test etc etc.

I think that's it. Is there anything else I needed to add?

First of all, thank you very much for your time. One thing I'd like you to add is a way to donate as a way to give back :D
Anyway, from my testing:

• Horizontal Swing doesn't seem to be supported in the Samsung protocol implementation, is that correct? IRrecvDumpV3 doesn't pick it up. Vertical Swing only gets picked up when not combined with horizontal Swing.

• Beep: On is swapped with the Filter Reset one, (Only sending "Filter Reset" from the remote causes Beep: On to show up) that's probably because of bad data on my end, I'll investigate further.

• All timers and everything else works :)

[crankyoldgit]

First of all, thank you very much for your time. One thing I'd like you to add is a way to donate as a way to give back :D

Haha. I'm fine with no donations at this point.
You can buy me a beverage if ever we meet.
Personally, in just glad to be able to finally close this long-open issue!

Anyway, from my testing:

• Horizontal Swing doesn't seem to be supported in the Samsung protocol implementation, is that correct? IRrecvDumpV3 doesn't pick it up. Vertical Swing only gets picked up when not combined with horizontal Swing.

Correct. No one has reverse engineered that bit of had that setting... Yet.

• Beep: On is swapped with the Filter Reset one, (Only sending "Filter Reset" from the remote causes Beep: On to show up) that's probably because of bad data on my end, I'll investigate further.

It could be a model difference or poor earlier analysis. Dunno.

• All timers and everything else works :)

Awesome! Thanks for the verification!

[xorbital]

• Horizontal Swing doesn't seem to be supported in the Samsung protocol implementation, is that correct? IRrecvDumpV3 doesn't pick it up. Vertical Swing only gets picked up when not combined with horizontal Swing.

Correct. No one has reverse engineered that bit of had that setting... Yet.

Since for my unit it's just setting F-Off, A-Vertical, B-Horizontal, C-Both in the first Nibble of Byte 9 / 16 I hope this can be resolved at some point - but I guess there's more to it than that?

• Beep: On is swapped with the Filter Reset one, (Only sending "Filter Reset" from the remote causes Beep: On to show up) that's probably because of bad data on my end, I'll investigate further.

It could be a model difference or poor earlier analysis. Dunno.

Hm, I've just confirmed my original capture, and the conclusion was correct - the very last nibble sends the "beep toggle" or "filter reset" command, 4=Beep, 2=Filter Reset

[crankyoldgit]

Since for my unit it's just setting F-Off, A-Vertical, B-Horizontal, C-Both in the first Nibble of Byte 9 / 16 I hope this can be resolved at some point - but I guess there's more to it than that?

Probably not. Create a new issue and I'll do something about it.

I'll try to look back at the original history of the beep setting/analysis to see if I can find something.

[crankyoldgit]

Your horizontal swing should now be supported in a new branch: https://github.com/crankyoldgit/IRremoteESP8266/tree/samsung_swing / PR #1667

Please confirm if it works as you expect.

[xorbital]

The new PR works for setting the Swing Mode, thank you very much, I'm now testing the new Eco Setting.

Two things aren't working properly, if you want I can create a new issue for each instead.

• I didn't notice it earlier, the sleep timer isn't set properly, sending Power: On, Mode: 4 (Heat), Temp: 21C, Fan: 0 (Auto), Swing(V): Off, Swing(H): Off, Beep: Off, Clean: Off, Quiet: Off, Powerful: Off, Breeze: Off, Light: On, Ion: Off, Sleep Timer: 08:00 results in:

Original Remote:

0x02820F000010F001A20F04000C0001D2FE715041F0

IRremoteESP8266:

0x02920F000000F001A20F04000C0001D2FE715041F0

They both get decoded to the same command string, but the A/C only sets the sleep timer for the first one.
Seems like Byte 1 and 5 need to be different.

• The "Beep" Setting isn't set correctly for my unit:

Original Remote (short code since "Beep" is a toggle command, it can't be sent while turning on the unit):

0x02920F000000F001C2FE715041F4 

IRremoteESP8266:

0x02920F000000F001D20F0000000001C2FE715041F2

Seems like the very last nibble is causing issues. I've checked the codes sent by the remote again, and confirmed that the last nibble normally is 0, 2 when sending the "Filter Reset" command and 4 when sending the "Beep" command.

I've also noticed that the Tasmota Docs (at the bottom of that section) state that the sleep timer is specified in seconds. However, the library is expecting this value to be in minutes.
I don't know if that's just an issue for the Samsung Protocol or maybe a documentation issue on their end.

[crankyoldgit]

Yep, new issue for both please. This issue has gone on far to long and too much history. It will be easier for people to track later in separate issues.

[crankyoldgit]

FYI, when reporting the code for a A/C message., please use the state[] code from a normal IRrecvDumpV3 prog's output. It means I don't have to convert stuff by hand for the code/testing data.

[crankyoldgit]

The PR #1667 branch should now be able to construct the same sleep message as the remote generated.

[crankyoldgit]

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