Samsung AC - "clean" gets toggled twice
bogd opened this issue · 5 comments
This is related to issue #78 . In that issue, I mentioned the fact that on my Samsung AC unit, the "Clean" command is a unit-side (as opposed to remote-side) toggle, changing its state every time a "Clean: on" IR code is received.
You fixed that by introducing "clean" as a toggle, that I could call manually using tasmota_irhvac.set_clean
. And that worked for a while, but there seems to have been a recent change.
Now (using Tasmota 12.5.0), once I call tasmota_irhvac.set_clean
, the clean
flag is also set in the next IR command sent (the off
command), effectively toggling the setting once again and turning it off.
Steps to reproduce:
- call
climate.set_hvac_mode
, set tocool
- call
tasmota_irhvac.set_clean
, setclean
toon
- call
climate.set_hvac_mode
, set tooff
Expected result: unit should turn off, and enter clean mode
Actual result: unit turns off, clean mode is turned off
Details: the codes sent by tasmota_irhvac are below (captured using another tasmota device):
06:46:45.698 RSL: RESULT = {"IrReceived":{"Protocol":"SAMSUNG_AC","Bits":168,"Data":"0x02920F000000F001D20F0000000001D2FE719011F0","Repeat":0,"IRHVAC":{"Vendor":"SAMSUNG_AC","Model":-1,"Mode":"Cool","Power":"On","Celsius":"On","Temp":25,"FanSpeed":"Auto","SwingV":"Off","SwingH":"Off","Quiet":"Off","Turbo":"Off","Econo":"Off","Light":"On","Filter":"Off","Clean":"Off","Beep":"Off","Sleep":-1}}}
06:46:51.108 RSL: RESULT = {"IrReceived":{"Protocol":"SAMSUNG_AC","Bits":168,"Data":"0x02920F000000F001D20F0000000001B2FEF19211F0","Repeat":0,"IRHVAC":{"Vendor":"SAMSUNG_AC","Model":-1,"Mode":"Cool","Power":"On","Celsius":"On","Temp":25,"FanSpeed":"Auto","SwingV":"Off","SwingH":"Off","Quiet":"Off","Turbo":"Off","Econo":"Off","Light":"On","Filter":"Off","Clean":"On","Beep":"Off","Sleep":-1}}}
06:46:54.658 RSL: RESULT = {"IrReceived":{"Protocol":"SAMSUNG_AC","Bits":168,"Data":"0x02B20F000000C001D20F0000000001C2FEF1920DC0","Repeat":0,"IRHVAC":{"Vendor":"SAMSUNG_AC","Model":-1,"Mode":"Auto","Power":"Off","Celsius":"On","Temp":25,"FanSpeed":"Auto","SwingV":"Off","SwingH":"Off","Quiet":"Off","Turbo":"Off","Econo":"Off","Light":"On","Filter":"Off","Clean":"On","Beep":"Off","Sleep":-1}}}
Notice the "clean": "on" setting in the last (off
) message. That should actually be "clean": "off", to avoid toggling the setting once again. For details, see the last messages in #78 .
Edited for some additional details:
- as per @nao-pon 's comments on #78 : "Attributes in the toggle_list are always set to "Off", ignoring their default values. Sends On only when called on the Set Attribute Value service." This seems to have been reverted in a recent version, causing the behavior above.
- my full config for the device is below:
- platform: tasmota_irhvac
name: Bedroom AC
unique_id: bedroom_ac
command_topic: "cmnd/ac02/irhvac"
state_topic: "tele/ac02/RESULT"
temperature_sensor: sensor.th_temperature #optional this sensor is used to display current temp on the AC card
protocol: "SAMSUNG_AC"
min_temp: 16 #optional - default 16 int value
max_temp: 30 #optional - default 32 int value
target_temp: 25 #optional - default 26 int value
initial_operation_mode: "off" # optional - default "off" string value
away_temp: 24 #optional - default 24 int value
precision: 1.0 #optional - default 1.0 float value
supported_modes:
- heat
- cool
- dry
- fan_only
- auto
- "off" #Turns the AC off - Should be quoted and should be always included here
supported_fan_speeds:
- min
- medium
- high
- max
- auto
supported_swing_list:
- "off"
- vertical #up to down
toggle_list:
- Clean
hvac_model: "-1" # string value
celsius_mode: "On" #optional - default "On" string value - you can remove it
default_light_mode: "On"
@bogd I'm confused as to what this issue is about the toggle_list feature as there is no change.
Wait about 30 seconds before trying to change the command to eliminate the effects of the timing of sending the command.
If that's OK, we need to rethink how we implement this.
@nao-pon I admit I am confused as well. I even tried looking at the code, and it clearly shows all items in toggle_list
being turned off.
I tried enabling debug logging based on the instructions you gave me in the previous issue ( #78 ):
service: logger.set_level
data:
custom_components.tasmota_irhvac: debug
However there is nothing in the logs from tasmota_irhvac :( .
Doing a bit more testing, it seems that the behavior of the command has changed. It no longer acts like a toggle, but it seems... inverted (if I send "clean:on" from Tasmota, the self-clean light on the unit goes off). Based on this, it looks more like a change in IRRemoteESP8266 - so I think it would be best to close this issue, and ask more about this on the library's page.
Before I go, one unrelated thing - while digging through the logs, I found repeated instances of this:
Entity climate.bedroom_ac (<class 'custom_components.tasmota_irhvac.climate.TasmotaIrhvac'>) is using self.async_update_ha_state(), without enabling force_update. Instead it should use self.async_write_ha_state(), please report it to the custom integration author.
Should I open another issue to address this? Or is it something that can be safely ignored (for now, at least)?
Thank you!
Going through the issues of IRRemoteESP8266 (to make sure that the issue has not been already posted before opening a new one), I found these:
If I'm reading the changes correctly, this means that the "toggle" behavior is now handled on the library side, with "clean": "on" actually meaning "toggle the setting". Which would also explain the behavior I was seeing above (when sending "clean: on", the "clean" light on the unit would turn off because I was toggling the setting).
And indeed, after doing some more testing, this is exactly what is happening - "clean: on" toggles the unit's state.
So I know what has happened, now the question is "how do I fit this into TasmotaIRHVAC?". Because with these changes, "clean" does not need to be configured as a toggle in tasmotairhvac's toggle_list, but I still need to send "clean" only once, when powering off.
I can still use the previous workaround of manually calling "tasmota_irhvac.set_clean" once between power on and power off, but is there a better way of doing this?
Yes, parameters marked as toggle switches in the library will be toggled from on to off or from off to on by sending on. So as long as clean value is off in any sending data, the device should stay in clean mode.
That is, if I include clean in the toggle_list, I expect the following behavior:
-
Device clean mode is ON
- Air conditioner operation start
- Perform various operations such as temperature control
- Air conditioning stop
Clean mode is enabled.
-
Device clean mode is ON
- Air conditioner operation start
- Send clean mode ON once
- Perform various operations such as temperature control
- Air conditioning stop
Clean mode is disabled.
-
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.
If it doesn't work as described above, it is likely that there is an implementation error somewhere.
From what you've stated, it's possible that the async_update_ha_state() issue could be a property save timing issue, but I think it's unlikely.
Alternatively, if the equipment you use is designed to turn off clean mode when operation is stopped, you may need to send clean mode ON only once after starting operation.
Everything works exactly like you said. And indeed, since my unit automatically disables clean mode once a cleaning cycle is completed (i.e. after the unit turns off), I need to toggle the setting every time I turn it back on again. I am now doing this by calling tasmota_irhvac.set_clean
in an automation, but based on what you said this might also be a solution:
- Device clean mode is OFF
- Air conditioner operation start (with "clean: on" - this should toggle the setting and turn it on)
- Air conditioning stop (with "clean: off")
- Clean mode is enabled.
As for the other issue, async_update_ha_state()
, that is entirely unrelated to this thread. But it is something that my HomeAssistant logs on every start, urging me to report it to the custom integration author. I will open a new issue for that, since it is a different topic.
Thank you once again for your help!