make-all / tuya-local

Local support for Tuya devices in Home Assistant
MIT License
1.28k stars 505 forks source link

Climate toggle only working one way (off) - (Does not support climate turn on service) #1967

Closed jamesonuk closed 4 months ago

jamesonuk commented 4 months ago

Describe the bug I have some inkbird 306-A and 308 devices and have these added to a dashboard using a button with the tap action set to toggle. This works to turn it off but attempting to turn it back on it says failed to call service climate/turn on. Entity climate.<entity_name> does not support this service

To Reproduce Create a button for one of these devices and set tap action to toggle.

Expected behavior Button should toggle climate on/off correctly

Additional context This worked fine previously but the recent changes to avoid the deprecation warnings seems to have broken it.

Logger: homeassistant.components.websocket_api.http.connection
Source: components/websocket_api/commands.py:239
integration: Home Assistant WebSocket API (documentation, issues)
First occurred: 11:51:14 (2 occurrences)
Last logged: 11:58:26

[129084090788288] Unexpected exception
[129084304926400] Unexpected exception
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 239, in handle_call_service
    response = await hass.services.async_call(
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/core.py", line 2738, in async_call
    response_data = await coro
                    ^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/core.py", line 2779, in _execute_service
    return await target(service_call)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 957, in entity_service_call
    raise HomeAssistantError(
homeassistant.exceptions.HomeAssistantError: Entity climate.betta_inkbird does not support this service.
make-all commented 4 months ago

This is by design (of HA). Previously they just picked heat or cool to change to by default if the device does not support a turn on function that maintains the mode, but now they have deprecated that.

This device has a tristate power dp which is emulated as heat, fan, off in the HA allowed modes. So it isn't clear whether toggling from off to on should enable the heat or fan (pause in the app) mode.

jamesonuk commented 4 months ago

Just digging through the code and it looks like there is already processing in place to store the value turning off and restore when turning on

https://github.com/make-all/tuya-local/blob/ffe5241549c212a8d28dffb2d677357e1e42c024/custom_components/tuya_local/climate.py#L369-L370

Then looking at the docs for the climate changes I think the logic in
https://github.com/make-all/tuya-local/blob/ffe5241549c212a8d28dffb2d677357e1e42c024/custom_components/tuya_local/climate.py#L120-L121 is wrong (will this ever be boolean?) Given that the on/off implementation already stores / restores the mode, should it not just be the case that if there is at least one HVAC mode that isn't off then ON should be supported rather than checking the the HVAC mode is boolean?

make-all commented 4 months ago

Most tuya device provide a boolean on/off switch, so the above is correct for those devices. There is no state stored by the integration, as this would become out of sync if the device was controlled from its own control panel. Devices that have the separate boolean on/off switch will maintain the other settings themselves.