core: Radio Thermostat Constantly Swings Between Working and Unavailable

The problem

The climate entity (and the hold switch entity) both constantly flip back and forth between working and unavailable. It seems to stay in either status for fairly random intervals, but usually it’s between 2-15 minutes.

The thermostats are, unfortunately, old and single threaded and don’t always respond within Home Assistant’s timeout.

Previous behavior before I upgraded was that Home Assistant would keep trying the thermostat, and would keep the entity status unless the thermostat was well and truly down.

What version of Home Assistant Core has the issue?

core-2022.8.0

What was the last working version of Home Assistant Core?

core-2022.6.7

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Radio Thermostat

Link to integration documentation on our website

https://www.home-assistant.io/integrations/radiotherm

Diagnostics information

config_entry-unifi-cd79fcd59fe9472a93f5838750383581.json.txt

Example YAML snippet

No response

Anything in the logs that might be useful for us?

Logger: homeassistant.components.radiotherm.coordinator
Source: helpers/update_coordinator.py:151
Integration: Radio Thermostat (documentation, issues)
First occurred: 6:32:48 PM (40 occurrences)
Last logged: 8:51:12 PM

Error fetching radiotherm Thermostat data: Thermostat (192.168.0.240) was busy (invalid value returned):
Error fetching radiotherm Thermostat data: Thermostat (192.168.0.240) connection error: timed out

Additional information

These log entries were present in core-2022.6.7, but the status of the entities were not made unavailable when the timeout happened, but after an unknown (to me) number of timeouts happened. (Sometimes things would hang if you wanted to update the temperature or change the mode,)

About this issue

Original URL
State: open
Created 2 years ago
Reactions: 1
Comments: 32 (9 by maintainers)

Most upvoted comments

At least you can stop the cloud phone-home by setting enable to zero and clearing the authkey:

curl http://$THERMOSTAT_IP/cloud -d '{"enabled":0}' -X POST curl http://$THERMOSTAT_IP/cloud -d '{"authkey":""}' -X POST

That seems to help a bit on the dropouts.

There’s also someone who has reverse engineered the cloud connection if it’d be easier to do a Local-Push type control https://github.com/ceesb/radiothermostat_cloud

AdShea on Oct 15, 2023

To reiterate, there is a work around for this issue:

Disable Polling on the Radio Thermostat: Home Assitant -> “Settings” -> “Devices and Services” -> “Radio Thermostat” kebab menu -> “System Options” -> deselect “Enable polling for updates”
Create an polling automation (note the below is untested, but should work): Home Assistant -> “Settings” -> “Automations and Scenes” -> “Automations” -> “Creat Automation” -> “Create new automation” -> kebab menu -> “Edit in YAML”

alias: Force RadioTherm Update
description: 'Query radiotherm status when polling is disabled.'
mode: single
trigger:
  - platform: time_pattern
    minutes: 1
action:
  - service: homeassistant.update_entity
    target:
      entity_id:
        - climate.<radiothermostat_entity_name>

Note: the radiothermostats have an issue where they occassionally do not respond to API requests. This is not a function of WIFI signal strength and appears to be an inherint issue with the thermostats. There is also an issue where the thermostat can take longer to respond than HA’s http request timeout allows. In both situations the only workaround/solution is to requery the device.

Edit 1: Fixed (2) replacing “seconds: 60” with “minutes: 1”

vinnyfuria on Jun 5, 2023