I am trying to figure out how to handle failed requests to the cloud service that provides access to my thermostat. HA recognizes the requested changes, fires the appropriate integration request, which calls the cloud API, but the cloud service is either unavailable or drops the request. HA believes all is well but on the next successful poll (moments or hours later), the thermostat entity updates back to the pre-change request state.
My setup:
- Home Assistant is currently at 0.104.2 running in docker container on a raspberry pi (this issue has been happening since I started with HA in a venv sometime before 0.79)
- Lennox iComfort WiFi Thermostat connected to myicomfort.com
- myicomfort custom HA integration component GitHub
The frustration - My wife and I are gone, and one of us returns home which causes HA to change the state of the house to occupied. This occupancy change triggers a couple of automations, one of which is a request to the thermostat to exit away mode. Some time later we realize the house is way off temp and we check HA and see the thermostat still in away mode. The log book shows everything fired correctly but the cloud service for the thermostat apparently failed to accept the change of state for whatever reason. This also happens with manual changes like set point adjustments. HA initially shows the requested state but on the next successful poll, the entity state in HA updates to the old cloud value.
I am not alone and we don’t believe it to be an integration bug (but you never know). Others who are using the integration have reported similar issues. Some have even confirmed my blaming the cloud by having the Lennox Android app open and seeing it reporting service unavailable at the same time that changes to the HA thermostat entity fail to stick.
Possible solutions?
- Obviously getting a locally controlled Tstat would be the holy grail solution - this comes at a big $$ cost and system functionality cost.
- Secondary time based automations to check that a thermostat item is how it should be based on other conditions - This is possible but leads to multiple automations per item, which leads to a pain to manage.
- Queueing/retrying requests on failed integration calls - I wrote the myicomfort integration that is in use and there was no error reporting/handling options like this that I remember seeing, but HA has blossomed in the last year, so maybe?
- Generic ‘Bad Cloud’ Component / Desired state tracking - a component to track desired entity state, that is updated when a tracked entity gets updated, and that has a time/event trigger to fix entities that are obstinate.
Besides the personal frustration, this question was posed to me as an issue on the integration’s GitHub repository, and I am bringing it to the community because I needed more smart people giving this a few cycles. In this world of cloud driven devices, I’m sure that someone else has had similar cloud based frustrations. I’m hoping to find someone who has found a workaround or if not, maybe inspire some conversation and ideas.