Samsung AC - "Clean" gets toggled twice

[bogd]

I am back again, with a very similar issue as #78 and #106 .

With recent changes in IRRemoteESP8266 (mainly this one ), the toggling of the "clean" setting is handled on the library side automatically, with the "clean" bit being set in the IR signal only when the desired state for "clean" is different from the previous (stored) state.

Unfortunately, this brings me back to the situation described in #78 - no matter what I do, it is impossible to turn on and off the unit without "clean" being toggled twice.

I did remove the "clean" setting from tasmota_irhvac's toggle_list, but the behavior is the same.

As per @nao-pon 's comment on #106 (taking the example with "clean: off", because my unit always starts with clean mode set to off):

• Device clean mode is OFF
• Air conditioner operation start
• Send clean mode ON once
• Perform various operations such as temperature control
• Air conditioning stop
• Clean mode is enabled.

This does not work as expected. Here are the details:

• Device clean mode is OFF

• Air conditioner operation start

  • Tasmota sends "clean: off". This is identical to the previous state, so the "clean" bit is off in the IR signal, the unit stays in "clean: off".
    Tasmota console:
    stat/tas/RESULT = {"IRHVAC":{"Vendor":"SAMSUNG_AC","Model":1,"Mode":"Cool","Power":"On","Celsius":"On","Temp":26,"FanSpeed":"Auto","SwingV":"Off","SwingH":"Off","Quiet":"Off","Turbo":"Off","Econo":"Off","Light":"On","Filter":"Off","Clean":"Off","Beep":"Off","Sleep":-1}}

• Send clean mode ON once

  • calling tasmota_irhvac.set_clean. Tasmota sends "clean: on" (different from the previous state), so the bit is on in the IR signal. The unit toggles to "clean: on".
    Tasmota console:
    stat/tas/RESULT = {"IRHVAC":{"Vendor":"SAMSUNG_AC","Model":1,"Mode":"Cool","Power":"On","Celsius":"On","Temp":26,"FanSpeed":"Auto","SwingV":"Off","SwingH":"Off","Quiet":"Off","Turbo":"Off","Econo":"Off","Light":"On","Filter":"Off","Clean":"On","Beep":"Off","Sleep":-1}}

• Air conditioning stop

  • calling climate.set_hvac_mode. Tasmota sends "clean: off" (why? with "clean" no longer being part of toggle_list, shouldn't it keep sending the previous state??). This is different from the previous state recorded by Tasmota, so the IR bit is once again set to on. The AC unit toggles again, to "clean: off".
    Tasmota console:
    stat/tas/RESULT = {"IRHVAC":{"Vendor":"SAMSUNG_AC","Model":1,"Mode":"Off","Power":"Off","Celsius":"On","Temp":26,"FanSpeed":"Auto","SwingV":"Off","SwingH":"Off","Quiet":"Off","Turbo":"Off","Econo":"Off","Light":"On","Filter":"Off","Clean":"Off","Beep":"Off","Sleep":-1}}

• Clean mode is enabled.

  • no, because it was toggled twice

One more thing I noticed: when looking at the climate entity's state from home assistant, the "clean" attribute stays off even after calling tasmota_irhvac.set_clean (and this is probably why the power off call sends clean: off):

current_temperature: 23
temperature: 26
fan_mode: auto
hvac_action: 'off'
preset_mode: none
swing_mode: 'off'
econo: 'off'
turbo: 'off'
quiet: 'off'
light: 'on'
filters: 'off'
clean: 'off'
beep: 'off'
sleep: -1
last_on_mode: cool
swingv: 'off'
swingh: 'off'
fix_swingv: 'off'
fix_swingh: 'off'
friendly_name: Bedroom AC
supported_features: 57

So the main question here is: why does tasmota_irhvac send clean: off on that last message (even though clean is no longer in toggle_list), and what can I do to change this behavior?

[nao-pon]

@bogd Did you forget to restart HA after changing the toggle_list setting?

[bogd]

You are absolutely right - in recent versions of HAss, I got used to using the "quick reload" setting (either via restart/quick reload, or via the "reload all configuration YAMLs" buttons). I did a full restart now, and it does seem to behave properly (sending "clean: on" at power off as well).

However, this leaves me with a different issue - once the cleaning cycle is complete, the unit will disable its "clean" feature (the local setting, stored on the AC unit). But, of course, tasmota_irhvac will not be aware of that. Which means that tasmota_irhvac will still remember internally that "clean" is set to "on", and not set the "clean" bit in future IR commands.

Is there a way to tell tasmota_irhvac to change its internal state, without sending an IR command? My use case would be:

1. power on AC unit
2. set "clean" to "on" by calling tasmota_irhvac.set_clean
3. power off AC unit
4. wait for about 20 minutes, the length of the cleaning cycle
5. send a command to flip the internal state of tasmota_irhvac, so that I can perform the exact same steps and get a cleaning cycle at the next AC power on

[ Edited to add: I could probably template this to do a "set_clean" with "not current_state" in step 2, but I would prefer to keep the state in tasmota_irhvac consistent with the one on the actual unit. :) ]

Thank you!

[bogd]

Since I honestly do not know whether this could be more easily fixed in the library (IRRemoteESP8266), or in tasmota_irhvac, I opened an issue in both places - see mention above. Looking forward to your feedback on how this should be best handled.

Thank you once again!

[bogd]

I think @crankyoldgit put me on the right path here... With his response to the issue, I believe that Tasmota would be the best place to implement this "feature".

And taking a closer look at the docs, I found this:

"StateMode":
SendOnly (default)
StoreOnly
SendStore

I cannot test this right now, but it might be the winning solution. If I do:

• power on
• set clean: on
• power off
• wait for 15 minutes (or however long the cleaning cycle is)
• set "clean" to "off", but using "StoreOnly". This should bring the state back in sync between tasmota and the AC unit.

It would be nice to get support in tasmota_irhvac for StoreOnly (as suggested here , a link I found while looking for some documentation on that StateMode setting :) ). But for now, it should also be possible to do this via a direct MQTT send to Tasmota.

[nao-pon]

@bogd I think I have a good understanding of this issue. I think that skillful use of StateMode can solve this problem. By allowing the StateMode to be specified when running the service, it should work. for example···

service: tasmota_irhvac.set_clean
data:
  clean: "off"
  state_mode: StoreOnly
target:
  entity_id: climate.living_ac

I will work on this implementation.

[nao-pon]

@bogd I created a branch state_mode that might fix this issue. can you try that branch?

• https://github.com/hristo-atanasov/Tasmota-IRHVAC/tree/state_mode

[bogd]

You people are incredible... I ask for help (on a Sunday!!), and a few hours later there's already a branch with the changes! (plus a lot of help and guidance on the two issues posted). Thank you!!

One quick note, though - according to the Tasmota docs, the default for StateMode should be SendOnly. And even though the docs are not 100% clear (the Tasmota docs have this habit :) ), they seem to suggest that this is because otherwise tasmota would see its own IR signal and toggle the setting twice.

And if I'm reading the code correctly, this would always set StateMode in messages, with a default of SendStore. Which differs from the current default, and might break things for other people. Maybe consider adding SendOnly to the list, and making it the default?

I will get to testing, and post the results back here.

[nao-pon]

Previously this Tasmota-IRHVAC always sent StateMode as "SendStore". The current implementation of Tasmota-IRHVAC defaults to "SendStore" and does not support "SendOnly". If there seems to be a case where it is necessary to use "SendOnly", I will deal with it at that time.

[bogd]

I went through several cleaning cycles, and I can confirm everything works as expected. And like you said, I have seen no problems using SendStore (unlike what the Tasmota docs seem to suggest :) ), even though I do have an IR receiver on the Tasmota unit.

I will keep using this branch until it gets merged into the main one.

Thank you once again for your help, and for all the work that you are doing with this component!

[nao-pon]

@bogd Thank you for your cooperation in verifying the operation. Thanks to you, I can perform a merge into the master branch. An open source project is not only the work of the committers, but also the collaboration of the people who use it. Let's continue to work together! 👍