Fujitsu ARREB1E power on failure.

[s0170071]

my Fujitsu ARREB1E remote sends byte 8 bit 0 (LSB) as power on bit. The current implementation always sets this bit to 0 as part of the stay-on command.

I resolved this by adding a flag in ir_Fujitsu.cpp in the send function like this:

void IRFujitsuAC::send(const uint16_t repeat) {
  this->buildState();
  if ((!isOn) && (_cmd == kFujitsuAcCmdTurnOn)) {
    isOn= true; 
  }
  if  (_cmd == kFujitsuAcCmdTurnOff) {
    isOn= false; 
  }

This keeps track of the state and only transmits this bit once if the unit is to be switched on.

Furthermore in IRac.cpp there is no reference to the ARREB1E remote in the strToModel function. I fixed it like this:

int16_t IRac::strToModel(const char *str, const int16_t def) {
  // Fujitsu A/C models
  if (!strcasecmp(str, "ARRAH2E")) {
    return fujitsu_ac_remote_model_t::ARRAH2E;
  } else if (!strcasecmp(str, "ARDB1")) {
    return fujitsu_ac_remote_model_t::ARDB1;
  } else if (!strcasecmp(str, "ARREB1E")) {
    return fujitsu_ac_remote_model_t::ARREB1E;
  // Panasonic A/C families
  } 
...

I am not sure if this fix is appropriate or if there are other mechanisms in place. Seems like the root cause of this is that the current implemtation always sets temp, swing and opmode, which always triggers the "stay on" mode i.e. the power on bit is reset.

[crankyoldgit]

my Fujitsu ARREB1E remote sends byte 8 bit 0 (LSB) as power on bit. The current implementation always sets this bit to 0 as part of the stay-on command.

I resolved this by adding a flag in ir_Fujitsu.cpp in the send function like this:

void IRFujitsuAC::send(const uint16_t repeat) {
  this->buildState();
  if ((!isOn) && (_cmd == kFujitsuAcCmdTurnOn)) {
    isOn= true; 
  }
  if  (_cmd == kFujitsuAcCmdTurnOff) {
    isOn= false; 
  }

This keeps track of the state and only transmits this bit once if the unit is to be switched on.

Furthermore in IRac.cpp there is no reference to the ARREB1E remote in the strToModel function. I fixed it like this:

int16_t IRac::strToModel(const char *str, const int16_t def) {
  // Fujitsu A/C models
  if (!strcasecmp(str, "ARRAH2E")) {
    return fujitsu_ac_remote_model_t::ARRAH2E;
  } else if (!strcasecmp(str, "ARDB1")) {
    return fujitsu_ac_remote_model_t::ARDB1;
  } else if (!strcasecmp(str, "ARREB1E")) {
    return fujitsu_ac_remote_model_t::ARREB1E;
  // Panasonic A/C families
  } 
...

I am not sure if this fix is appropriate or if there are other mechanisms in place. Seems like the root cause of this is that the current implemtation always sets temp, swing and opmode, which always triggers the "stay on" mode i.e. the power on bit is reset.

Can you please supply some capture data from IRrecvDumpV2 for this behaviour? I should only need the state[] lines and a description from you as to what the mode of the A/C remote is.

As far as I understand it, Fujitsu only sets that bit when the last remote button pressed is a "power on". i.e. That bit is off when a subsequent mode/setting is changed. Is that different for this model?

Or are you saying the operation via IRMQTTServer is what is causing your problem?

When I glanced over the code just now, it should be setting that bit to 1 when the last operation on that class is a setPower(true) or on() etc.

As for the strToModel() thing, yep, that sounds like a bug/oversight. I'll fix it shortly.

[s0170071]

As far as I understand it, Fujitsu only sets that bit when the last remote button pressed is a "power on". i.e. That bit is off when a subsequent mode/setting is changed. Is that different for this model?

Thats correct.
But if you call the
sendAc(protocol, model, power, opmode, degrees, celsius, fanspeed, swingv, swingh, quiet, turbo, econo, light, filter, clean, beep, sleep, clock);

method, that invokes the
fujitsu(...)
constructor. That one gets passed all the parameters at once. There is no way to only send a power-on command. The fujitsu code inevitabely sets swing, mode and temp along with it.

If you look at the fujitsu code, setting swing, temp and mode triggers the stay-on command which is just clearing the power-on bit.

As for temp, sending a -1 could avoid setting it (not implemented), but swing is a bool. No way to indicate here that it shouldn't be set at all.

I'll post the IR dump tomorrow.

[crankyoldgit]

But if you call the
sendAc(protocol, model, power, opmode, degrees, celsius, fanspeed, swingv, swingh, quiet, turbo, econo, light, filter, clean, beep, sleep, clock);

method, that invokes the
fujitsu(...)
constructor. That one gets passed all the parameters at once. There is no way to only send a power-on command. The fujitsu code inevitabely sets swing, mode and temp along with it.

Got it. That info would have been helpful in the opening text of the issue. ;-)

[s0170071]

Here come the remote recordings:

turn on (FAN)
uint8_t state[16] = {0x14, 0x63, 0x00, 0x10, 0x10, 0xFE, 0x09, 0x30, 0x51, 0x03, 0x04, 0x00, 0x00, 0x00, 0x20, 0x58};

switch to HEAT:
uint8_t state[16] = {0x14, 0x63, 0x00, 0x10, 0x10, 0xFE, 0x09, 0x30, 0x50, 0x04, 0x04, 0x00, 0x00, 0x00, 0x20, 0x58};

change temp to 22°C
uint8_t state[16] = {0x14, 0x63, 0x00, 0x10, 0x10, 0xFE, 0x09, 0x30, 0x60, 0x04, 0x04, 0x00, 0x00, 0x00, 0x20, 0x48};

turn off:
uint8_t state[7] = {0x14, 0x63, 0x00, 0x10, 0x10, 0x02, 0xFD};

Here are the outputs from the library (as per PR862)

turn on (was off):
uint8_t state[16] = {0x14, 0x63, 0x00, 0x10, 0x10, 0xFE, 0x09, 0x30, 0x51, 0x03, 0x02, 0x00, 0x00, 0x00, 0xA0, 0xDA};

switch to HEAT:
uint8_t state[16] = {0x14, 0x63, 0x00, 0x10, 0x10, 0xFE, 0x09, 0x30, 0x51, 0x04, 0x02, 0x00, 0x00, 0x00, 0xA0, 0xD9};

change temp to 22°C
uint8_t state[16] = {0x14, 0x63, 0x00, 0x10, 0x10, 0xFE, 0x09, 0x30, 0x61, 0x04, 0x02, 0x00, 0x00, 0x00, 0xA0, 0xC9};

So it is like I suspected, the current implementation keeps the power bit at 1 even if the unit is already on.
Maybe my fix above is not so bad after all ?
Somewhere the lib needs to track if the AC is already on, I just cant find where that is if it does....

[crankyoldgit]

Does the AC change modes and operate as expected with the PR#862 changes?

[crankyoldgit]

Does the AC change modes and operate as expected with the PR#862 changes?

Repeating the question. @s0170071 does it work, even with that bit almost always set to 1?

[crankyoldgit]

FYI: The changes mentioned above have been included in v2.6.5 of the library which has just been released.