Core: Changes to evohome take minutes to appear in the UI

[corneyl]

Home Assistant release with the issue: 0.96.2

Last working Home Assistant release (if known): -

Operating environment (Hass.io/Docker/Windows/etc.): Docker

Component/platform: evohome

Description of problem:
When the target temperature is set using the HA interface for a Round Connected thermostat, the set temperature jumps back to the old value.
The temperature is changed on the thermostat though.
After a regular poll update, it's updated to the set temperature.

Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

evohome:
  username: !secret honeywell_username
  password: !secret honeywell_password

Additional information:
Screen capture of the process:

[ghost]

Hey there @zxdavb, mind taking a look at this issue as its been labeled with a integration (evohome) you are listed as a codeowner for? Thanks!

_This is a automatic comment generated by codeowners-mention to help ensure issues and pull requests are seen by the right people._

[zxdavb]

@corneyl Try reducing your scan interval to 60 seconds:

evohome:
  username: !secret honeywell_username
  password: !secret honeywell_password
  scan_interval: 60

And then: is it the case that the UI reverts, but changes to the new value shortly after (when the next 60 second cycle come around).

[corneyl]

@zxdavb That's exactly the case indeed. UI reverts but changes to set temperature after half a minute.

[zxdavb]

I think this is expected behavior for an internet-polled device.

Or did the old version change to the new value without first reverting to the old value?

[corneyl]

The old module (honeywell) indeed didn't revert to the old value in between.

From a user experience point of view I'd also opt for this, because otherwise it looks like it failed to set the target temperature. One would try again or think the system/connection is broken.

From a developers perspective I think we can assume that the target temperature is changed if the call to the API to set the temperature succeeded. Maybe it's possible to persist the state of the target temperature if no error was raised during the update?

[bennealon]

I'm also having this same issue with my evohome integration, i'm using the recommended polling of 180.
My biggest problem isn't the temperature glitch, but the fact it's almost impossible to set a temperature AND choose whether to have this temperature persistent or temporary. It appears that once you change the temperature it is immediately submitted, then changing the preset or heat field are submitted as seperate calls, but there lies the bigger problem: changing the preset field for example appears to send a temperature to evohome aswell, but since the UI has reverted the temperature back almost instantly to the previous value, this previous value is then sent to evohome and you get stuck in an endless cycle of trying to fix either the temperature OR preset. The same issue happens if you select the preset and temperature in the reverse order.

Would it not be a better solution to have a submit button instead? To allow the user to configure the request how they want, then send one API request once they are ready?

Is it possible to enforce a default preset value, as the default permanent does not mimick the behaviour on the evohome native app, which is to set as an temporary temperature until the next set point - and is a little frustrating as i don't want my family to accidentally set a permanent override in HA for my heating system.

I also have an issue with my evohome DHW integration, i am unable to alter the state from the UI (i have not tried through an automation yet).

[zxdavb]

All, I am having a think about this issue (lack of convergence between requested/reported state).

@bennealon Could you open a new issue for your other problems, and provide as much detail as you can? For example: evohome, or round thermostat?

[bennealon]

All, I am having a think about this issue (lack of convergence between requested/reported state).

@bennealon Could you open anew issue for your other problems, and provide as much detail as you can? For example: evohome, or round thermostat?

Yeah sure, i have the evohome system for reference. Do you want me to log another ticket for both the DHW issue AND the preset issue? If so, how do i make one of those screencapture gif's as shown in this issue?

[zxdavb]

They are two separate issues - I wrote the code, so if you submit them, I will look at them, honest!

[bennealon]

@zxdavb thank you very much, i have submitted two issues, i hope there is enough information in there to help you out. I will be moving my environment over to docker soon, so hopefully that means i can help out with testing if you do not have the hot water hardware, or evo controller in your setup. I have not linked the DHW issue to this one, but the issue can be seen here: #25985. Cheers 👍

[zxdavb]

@corneyl

The old module (honeywell) indeed didn't revert to the old value in between.

FWIW, honeywell and evohome both us the same underlying client API, although evohome uses v2 rather than v1.

The problem with evohome is that it is a good citizen, and limits its API calls.

After chatting with the devs, I have come up with another solution that doesn't require a major re-write...

... but things will be delayed as I am half-way through converting evohome to asyncio.

[zxdavb]

OK, I've got a version that converges in 2 seconds (I am reluctant to make it less).

Only thing is, it is based upon a new evohomeclient library that is now async & it will need some testing.

Any volunteers?