Irremoteesp8266: 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 :+1:

[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 :slightly_smiling_face:
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 :slightly_frowning_face:

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:
https://github.com/crankyoldgit/IRremoteESP8266/blob/bfa52019fc9aed7ca6c68c4cbcd3b12075249c5f/src/IRrecv.h#L35

See https://github.com/crankyoldgit/IRremoteESP8266/commit/f3b4d7585e2b6f10ffe3258ed31da464571df1d8 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 :slightly_smiling_face:

[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:
https://github.com/crankyoldgit/IRremoteESP8266/blob/bfa52019fc9aed7ca6c68c4cbcd3b12075249c5f/src/ir_Samsung.cpp#L383-L407

[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 :+1:

[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?