WHIRLPOOL_AC related issues

[the-mentor]

Version/revision of the library used

I'm using Tasmota 8.4.0 which is using v2.7.8.10 according to the release notes

Expected behavior

I'll try to explain my issue to the best of my ability and hopefully it will all make sense.
I'm using an IR receiver/blaster that I've flashed with Tasmota 8.4.0.
From my understanding, Tasmota 8.4.0 uses IRremoteESP8266 v2.7.8.10 so I figured I'll come here to explain my issue.

When I capture codes from the remote it seems to not differentiate between the On and Off commands correctly.

On Capture

{"IrReceived":{"Protocol":"WHIRLPOOL_AC","Bits":168,"Data":"0x0x830605A200008C0200000000002900010000080009","Repeat":0,"IRHVAC":{"Vendor":"WHIRLPOOL_AC","Model":2,"Power":"On","Mode":"Cool","Celsius":"On","Temp":26,"FanSpeed":"Max","SwingV":"Off","SwingH":"Off","Quiet":"Off","Turbo":"Off","Econo":"Off","Light":"On","Filter":"Off","Clean":"Off","Beep":"Off","Sleep":-1}}}

Off Capture

{"IrReceived":{"Protocol":"WHIRLPOOL_AC","Bits":168,"Data":"0x0x830605A200008C0100000000002A00010000080009","Repeat":0,"IRHVAC":{"Vendor":"WHIRLPOOL_AC","Model":2,"Power":"On","Mode":"Cool","Celsius":"On","Temp":26,"FanSpeed":"Max","SwingV":"Off","SwingH":"Off","Quiet":"Off","Turbo":"Off","Econo":"Off","Light":"On","Filter":"Off","Clean":"Off","Beep":"Off","Sleep":-1}}}

As you can see in both cases the Power is "ON"

Here are captures of the remote adjusting the temperature

{"IrReceived":{"Protocol":"WHIRLPOOL_AC","Bits":168,"Data":"0x0x830601B200008C0400000000003B0002000008000A","Repeat":0,"IRHVAC":{"Vendor":"WHIRLPOOL_AC","Model":2,"Power":"Off","Mode":"Off","Celsius":"On","Temp":27,"FanSpeed":"Max","SwingV":"Off","SwingH":"Off","Quiet":"Off","Turbo":"Off","Econo":"Off","Light":"On","Filter":"Off","Clean":"Off","Beep":"Off","Sleep":-1}}}
{"IrReceived":{"Protocol":"WHIRLPOOL_AC","Bits":168,"Data":"0x0x830601A200008C0400000000002B0002000008000A","Repeat":0,"IRHVAC":{"Vendor":"WHIRLPOOL_AC","Model":2,"Power":"Off","Mode":"Off","Celsius":"On","Temp":26,"FanSpeed":"Max","SwingV":"Off","SwingH":"Off","Quiet":"Off","Turbo":"Off","Econo":"Off","Light":"On","Filter":"Off","Clean":"Off","Beep":"Off","Sleep":-1}}}

As you can see in the temperature adjustments it sends the Power as "Off"

I hope this is enough information for you to help me out.
If you have any questions or need more info to help me out please let me know.

Thank you!
-DM

[crankyoldgit]

For the whirlpool protocol, power control is a toggle setting (See https://crankyoldgit.github.io/IRremoteESP8266/doxygen/html/classIRWhirlpoolAc.html#a61bec25edce5bc244acb41f79df561e7)
The remote sends the same signal for on as it does for off.
I.e. The protocol lacks the ability to tell the device to be "on" or "off", directly. It only has the ability to say "change the power setting from what it was".

[the-mentor]

thanks for all the info @crankyoldgit i apprieciate your insight

[ayavilevich]

@crankyoldgit thanks for this open source project.

With regards to this issue of ACs with power toggle.
I have an AC using the AIRWELL protocol which suffers from the same issue as the WHIRLPOOL.

You mentioned, and I have seen in the code, that you have implemented a handleToggles() function to address state tracking.
Can you provide more information on how you indented this to be used by the users of this library?
Is the prev/new state already tracked and calculated by IRremote?
It seems this doesn't work correctly in tasmota-ir. Does somebody needs to implement something additional to use state toggling?
How would we "sync" state initially or if it goes out of sync?

For the record here are links to the various issues from other projects in the stack:

#1002 - some changes to make power toggle better

https://github.com/hristo-atanasov/Tasmota-IRHVAC - a component to integrate tasmota-ir into homa-assistant
hristo-atanasov/Tasmota-IRHVAC#6 - attempts to solve this at the display level. might not be the right solution.

https://github.com/arendst/Tasmota - tasmota, the firmware that uses this library
arendst/Tasmota#9004
arendst/Tasmota#9060
seems it is not clear whose responsibility it is to implement state tracking.
also it seems they modify the fields power/mode.

[crankyoldgit]

The IRac class if used only via the next attribute should handle toggles internally (via IRac::handleToggles() when used in conjunction with/via IRac:sendAc(void)

TL;DR: If (and only if) you only ever use the internal state (next) in the IRac` object, it should do the right thing for you. There are caveats of course (like changing protocol/model of the AC etc).

seems it is not clear whose responsibility it is to implement state tracking.

Anything outside of what I mentioned above, it's solely up to the user of the library to manage state.

also it seems they modify the fields power/mode.

Yes, in some cases, and situations. See:

IRremoteESP8266/examples/IRMQTTServer/IRMQTTServer.h

Lines 137 to 151 in 30be145

	// Use Home Assistant-style operation modes.
	// TL;DR: Power and Mode are linked together. One changes the other.
	// i.e.
	// - When power is set to "off", the mode is set to "off".
	// - When the mode changes from "off" to something else, power is set to "on".
	// See: https://www.home-assistant.io/components/climate.mqtt/#modes
	// *** WARNING ***
	// This setting will cause IRMQTTServer to forget what the previous operation
	// mode was. e.g. a power "on" -> "off" -> "on" will cause it to use the
	// default mode for your A/C, not the previous mode.
	// Typically this is "Auto" or "Cool" mode.
	// Change to false, if your home automation system doesn't like this, or if
	// you want IRMQTTServer to be the authoritative source for controling your
	// A/C.
	#define MQTT_CLIMATE_HA_MODE true

[crankyoldgit]

Is the prev/new state already tracked and calculated by IRremote?

the next state is basically what the user wants an A/C to be in. The prev state is for internal use only mostly. When using SendAc(void) it will calculate & transmit a temporary state to send that should make the actual A/C unit transition from the "old" desired "human" state (prev) to the "new" desired "human" state(next). This temporary state is not stored.

It seems this doesn't work correctly in tasmota-ir. Does somebody needs to implement something additional to use state toggling?

No idea. That's out of scope for this library. You'll need to talk to the Tasmota peeps or look at their code for how they implemented it.
See also: https://github.com/crankyoldgit/IRremoteESP8266/wiki/Troubleshooting-Guide#things-we-are-unlikely-to-help-you-with
Fixing code in some other maintained project that includes our library, unless you're one of the maintainers of that project. You should probably report an issue with them instead of us.

How would we "sync" state initially?

Initial state setup.

// Pseudo-untested-uncompiled-code ahead!
IRac my_ac_obj(4);
my_ac_obj.next.protocol = decode_type_t::WHIRLPOOL_AC;
my_ac_obj.next.mode = stdAc::opmode_t:kCool;
my_ac_obj.next.celsius = true;
my_ac_obj.next.degrees = 27;
...
my_ac_obj.markAsSent();  // Basically copy `next` to `prev`. e.g. pretend we sent it. Now `next` and `prev` should basically be the same.

or if it goes out of sync?

That's up to the user to work out. IR protocols are an optimistic transmission method. There is no acknowledgement back. We can only try our best when there are "toggle" commands in a message. This is why they are (IMHO) a poor design decision in a manufacturers IR control implementation w.r.t. home automation. They designed it for a real user, with a real remote in their hand, and rely on the user looking at both devices to work out if they need to mash a button again. They didn't design it with the idea of independent 3rd party home automation systems that can't sense the actual operating mode of an A/C typically.