Support for Samsung AC to turn off

[gladson1990]

Hi ,. I just tried the controlsamsungac example. First I did an on and off which worked. Then I tried off and again off , the second time the ac turned on. Now when I try to turn off the ac it's not turning off. The ac receives the code but doesn't turn off and I don't see any temperature on the display. Can someone tell me how can I make the AC off. All I wanted was to turn on, set temp and turn off. Now only the last part turn off is pending. Kindly help .

[crankyoldgit]

Why didn't you follow the template that was created when you opened this issue? That contains valuable info for us.

Are you using the "controlsamsungac example" completely unmodified? Are you saying the 2nd time through the example code's loop it failed to turn off? Do the other commands etc in the program work still? e.g. Have you tried turning it off with the actual remote to see if the program is still successfully sending?

[gladson1990]

I wanted to provide more info , but since I am very new to this, some of them I did not understand. I had used the "controlsamsungac example" unmodified at first to verify whether my AC is working fine or not, and it worked well. ie it turned ON and OFF as per the command it sent. Next I tried to check what happens if we send the same command twice, So I had send turn on twice and checked - it worked well. Next I tired turn OFF twice, The AC turned off at first and then turned on at the second time. Now when I try to turn off the AC using the ac.off() code it is not turning off, I would get a beep sound from the AC and the temperature disappears , but the AC is still on. I turned off using the AC remote and that time it turned off.
Set temp, set mode , set swing works well.

[crankyoldgit]

Can you please include the entire code in which it fails to turn off, so we can try to reproduce the problem?

[crankyoldgit]

Also, what version of the library or master commit are you using?

[gladson1990]

/* Copyright 2019 David Conran
*
* An IR LED circuit *MUST* be connected to the ESP8266 on a pin
* as specified by kIrLed below.
*
* TL;DR: The IR LED needs to be driven by a transistor for a good result.
*
* Suggested circuit:
*     https://github.com/crankyoldgit/IRremoteESP8266/wiki#ir-sending
*
* Common mistakes & tips:
*   * Don't just connect the IR LED directly to the pin, it won't
*     have enough current to drive the IR LED effectively.
*   * Make sure you have the IR LED polarity correct.
*     See: https://learn.sparkfun.com/tutorials/polarity/diode-and-led-polarity
*   * Typical digital camera/phones can be used to see if the IR LED is flashed.
*     Replace the IR LED with a normal LED if you don't have a digital camera
*     when debugging.
*   * Avoid using the following pins unless you really know what you are doing:
*     * Pin 0/D3: Can interfere with the boot/program mode & support circuits.
*     * Pin 1/TX/TXD0: Any serial transmissions from the ESP8266 will interfere.
*     * Pin 3/RX/RXD0: Any serial transmissions to the ESP8266 will interfere.
*   * ESP-01 modules are tricky. We suggest you use a module with more GPIOs
*     for your first time. e.g. ESP-12 etc.
*/
#include <Arduino.h>
#include <IRremoteESP8266.h>
#include <IRsend.h>
#include <ir_Samsung.h>

const uint16_t kIrLed = 4;  // ESP8266 GPIO pin to use. Recommended: 4 (D2).
IRSamsungAc ac(kIrLed);     // Set the GPIO used for sending messages.

void printState() {
  // Display the settings.
  Serial.println("Samsung A/C remote is in the following state:");
  Serial.printf("  %s\n", ac.toString().c_str());
}

void setup() {
  ac.begin();
  Serial.begin(115200);
  delay(200);

  // Set up what we want to send. See ir_Samsung.cpp for all the options.
  Serial.println("Default state of the remote.");
  printState();
  Serial.println("Setting initial state for A/C.");
  ac.off();
  ac.setFan(kSamsungAcFanLow);
  ac.setMode(kSamsungAcCool);
  ac.setTemp(25);
  ac.setSwing(false);
  printState();
}

void loop() {
  // Turn the A/C unit on
  Serial.println("Turn on the A/C ...");
  ac.on();
  ac.send();
  printState();
  delay(5000);  // wait 15 seconds
  // and set to cooling mode.
  Serial.println("Set the A/C mode to cooling ...");
  ac.setMode(kSamsungAcCool);
  ac.send();

  printState();
  delay(15000);  // wait 15 seconds

  // Turn the A/C unit off.
  Serial.println("Turn off the A/C ...");
  ac.off();
   ac.send()

  printState();
  delay(15000);  // wait 15 seconds
  // Turn the A/C unit off.
  Serial.println("Turn off the A/C ...");
  ac.off();
   ac.send()

  printState();
  delay(15000);  // wait 15 seconds
}

library is the latest lib_deps = crankyoldgit/IRremoteESP8266@^2.7.19

I am using it in esp32. Let me know if there is any particular pin that I got to use for this to work.

[crankyoldgit]

// Turn the A/C unit off.
  Serial.println("Turn off the A/C ...");
  ac.off();
   ac.send()

  printState();
  delay(15000);  // wait 15 seconds
  // Turn the A/C unit off.
  Serial.println("Turn off the A/C ...");
  ac.off();
   ac.send()

Btw. You're missing ;s from the end of your ac.send() lines. I'm surprised it compiled.

Okay. The Samsung A/C class will not send a second special "Off" message when it thinks the A/C is already off. So, the first ac.off(); ac.send(); should generate an extended "Off" message per the protocol as we understand it. The next ac.send(); will only send a normal "Off" message, because it believes the A/C is already off. A normal message typically is not enough to tell the A/C unit to turn off or on reliably. Extended Samsung messages are required to make sure the unit powers on or powers off.

As long as the power state changes in the class between ac.send();s then it should do the correct thing and send the appropriate extended Samsung message.

See: https://github.com/crankyoldgit/IRremoteESP8266/blob/203a61e7d035f773695c4e38465cad1f38f6d706/src/ir_Samsung.cpp#L358-L361

Or put another way, sending two "off" messages without turning the device "on" (via the class), the second off will never send the correct message because it believes it is already off.

[rg2k]

Mine was working till I upgraded to 2.7.19 / 2.7.20 - Samsung AC will no longer turn off. I rolled back to version 2.7.18 and everything working as it used to. @gladson1990 - try forcing the version and check again?

[crankyoldgit]

@gladson1990 & @rg2k I've created a branch that might address your issues. But I need to you test & check it does. Please download & test the code in branch https://github.com/crankyoldgit/IRremoteESP8266/tree/Issue1648 / PR #1650 and let us know how it goes.

I've created a test to verify the code you submitted, and it seems to (now at least) do what I said it should in https://github.com/crankyoldgit/IRremoteESP8266/issues/1648#issuecomment-950317124 e.g. https://github.com/crankyoldgit/IRremoteESP8266/blob/e2b01f502e9353c65434dd2d8c2a76ffdec9bc2b/test/ir_Samsung_test.cpp#L1675-L1766

FYI @xorbital @IceOnly ... That PR should address https://github.com/crankyoldgit/IRremoteESP8266/issues/1277#issuecomment-946621431

[gladson1990]

Sure @crankyoldgit I ll try and let u know. Appreciate your knowledge of fixing things fast!

[gladson1990]

@crankyoldgit I tried with the branch, and it did not work for me. then i used urs IRrecv and IRsend example, I was able to understand it well and now I am able to turn off with the following data.

// Example of data captured by IRrecvDumpV2.ino uint16_t rawData[349] = {646, 17846, 3066, 8934, 556, 446, 552, 1442, 552, 446, 552, 444, 552, 444, 552, 446, 552, 444, 552, 446, 552, 446, 550, 1444, 550, 450, 548, 472, 526, 1468, 542, 1452, 552, 446, 552, 1442, 552, 1442, 552, 1442, 554, 1442, 552, 1442, 554, 446, 552, 446, 550, 446, 550, 448, 548, 448, 550, 472, 524, 472, 540, 456, 548, 448, 552, 446,
552, 444, 552, 444, 552, 444, 552, 444, 552, 446, 552, 446, 552, 444, 552, 446, 552, 444, 552, 446, 552, 446, 550, 448, 550, 448, 548, 472, 526, 472, 544, 452, 550, 448, 550, 446, 552, 446, 552, 446, 552, 446, 552, 444, 552, 444, 552, 446, 550, 1442, 554, 1442, 494, 3008, 3038, 8932, 556, 1440, 554, 472, 466, 530, 528, 468, 548, 448, 552, 444, 552, 446, 552, 446, 552, 444, 552, 1442, 552, 446, 552, 444, 552, 1442, 554, 446, 552, 1442, 552, 1442, 552, 1468, 468, 1526, 550, 1444, 554, 1442, 552, 446, 552, 444, 552, 444, 552, 444, 552, 444, 554, 444, 552, 444, 552, 446, 550, 446, 552, 446, 550, 448, 550, 472, 524, 472, 466, 530, 544, 452, 550, 446, 552, 444, 552, 446, 552, 444, 552, 444, 552, 444, 552, 444, 552, 444, 552, 446, 552, 446, 552, 446, 552, 446, 552, 446, 550, 448, 550, 470, 526, 472, 466, 530, 544, 454, 550, 446, 552, 444, 552, 446, 552, 2948, 3038, 8934, 558, 1440, 554, 444, 552, 444, 552, 444, 552, 444, 552, 446, 550, 446, 550, 446, 550, 472, 526, 1468, 468, 530, 546, 450, 552, 1442, 552, 446, 552, 444, 554, 444, 552, 1440, 554, 1440, 554, 1440, 554, 1442, 554, 446, 550, 1442, 552, 472, 526, 1468, 548, 1446, 552, 446, 552, 446, 552, 446, 552, 1440, 554, 1440, 554, 1440, 554, 446, 552, 444, 552, 446, 552, 446, 550, 446, 550, 448, 548, 472, 526, 472, 542, 1450, 552, 1442, 554, 444, 552, 1440, 554, 444, 552, 1442, 552, 444, 554, 444, 552, 446, 552, 446, 552, 446, 550, 446, 550, 448, 550, 472, 526, 470, 514, 1480, 550, 1444, 554}; // Example Samsung A/C state captured from IRrecvDumpV2.ino

const uint16_t kSamsungAcStateLengthlo =21;

uint8_t samsungState[kSamsungAcStateLengthlo] = {0x02, 0xB2, 0x0F, 0x00, 0x00, 0x00, 0xC0, 0x01, 0xD2, 0x0F, 0x00, 0x00, 0x00, 0x00, 0x01, 0x12, 0xAF, 0x71, 0x80, 0x15, 0xC0};

[rg2k]

I can also confirm that the branch did not work.

[crankyoldgit]

I can also confirm that the branch did not work.

Can you please capture the same sequence of signals/messages from the real remote? That way I can compare the two.

[crankyoldgit]

I think I've found the issue. It seems the power setting is located in two places in the protocol message, not the single place the initial analysis had determined. I've modified the code & branch to hopefully fix this. In the tests, I can exactly simulate/reconstruct the same samsungState[] code from https://github.com/crankyoldgit/IRremoteESP8266/issues/1648#issuecomment-950822399 So I fairly confident that it should fix the problem for you.

Can you please re-download and test the latest revision of that branch and confirm please?

[gladson1990]

@crankyoldgit The latest fix is working well. Thank u so much on that. Will u be pushing the fix to release ? or should i be using the temp branch.

[rg2k]

Still no luck on my side. I suspect it has something to do with the 'beep' setting, but I'll only be able to go into deep troubleshooting later in the week. Will stay on ver .18 for now.

[crankyoldgit]

@crankyoldgit The latest fix is working well. Thank u so much on that. Will u be pushing the fix to release ? or should i be using the temp branch.

I'll be merging it into master shortly. I'm waiting till the end of Hacktoberfest before I create a new release. So, soon.

[crankyoldgit]

Still no luck on my side. I suspect it has something to do with the 'beep' setting, but I'll only be able to go into deep troubleshooting later in the week. Will stay on ver .18 for now.

@rg2k without data etc, I'm unable to help.

[crankyoldgit]

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

[gladson1990]

Thank u much :)