Thank you very much for your quick response!
Actually, there’s no reason why we couldn’t use a generic RF module instead of the HGI80. It would be much cheaper.
I have both sitting in my drawer…
I already bought a HGI80 so I vote for that ;-), but both would be best.
Hello will custom version of the evohome component allow me to see the tempreature of my hot water?
I’ve tried the official evohome component and it does not show me my hot water temp, while the depreciated honeywell component shows me my hot water temp, so the API is giving out the info, I just need the right component to read that info.
The short answer is: Yes.
The good news is that I’m the one deprecating Honeywell-EU!
So, I will add DHW to the Evohome integration before deprecating the above.
The other issue is high-definition temperatures…
1 Like
So, I will add DHW to the Evohome integration before deprecating the above.
Thanks, that’s good to know. I have a few automations that rely on the hot water temp sensor, so I’ll stick to the honeywell component until the DHW in evohome is up and running.
The other issue is high-definition temperatures…
I did notice that temps from the evohome component show in 0.5 degree increments, while it would be nice to have 0.1 increments like the honeywell it’s not essential for me, but nice to have I guess.
I’m running a few other custom-components already so am happy to provide feedback during testing, if needed. 
Actually, the temps are in 0.01 increments!
You can get at them via the custom_component, but HA only handles 0.1 by default - you can see the difference with a custom graph, see this graphic (note the temp is 20.31C):
See this one for DHW (T=53.91C):
Upon reflection, but suggestion to you is to switch to the custom component for now. This is true, even though I have a PR ready to go for HW for the official evohome integration.
@corneyl (and others with an EU Honeywell Round Thermostat):
I have only had a chance to very quickly test the official evohome (which really should be called “TCC Climate (EU)”) with a RoundThermostat. To me, it seems to be working as expected - although it is split into a controller and a zone (rather than a combination of the two as you’d expect).
A draft PR exists to make the official evohome functionally equivalent to the custom_component, with the exception of higher-precision temps (which will be added later).
My intention is to ensure _that_PR fully supports a RoundThermostat (with the exception of higher precision temps).
This new PR forms the basis for greatness and - with the exceptions of contrived circumstances - is virtually immune to API rate limits, even with multiple reboots, and a poll interval of 60 seconds!
After that PR, I may consider creating a new class that is a merge of the controller class, and the zone class, for those circumstances where - like RoundThermostat - there is only a single Zone.
@zxdavb Thanks for looking into this!
I did some more testing and it indeed seems to work. It takes a bit more time until the temperature really changes compared to the honeywell component. Maybe it was because of that that I thought it didn’t work.
I’m looking forward to the new features you’re planning to implement in the evohome component, and will keep using the honeywell component until it’s deprecated or evohome supports higher precision.
Yes, the evohome component has a scan_interval of 180 secs rather than 60 secs. This is very boring, but essentially:
In the old days, there was an api rate limit on polling for data that meant an evohome system with 12 radiator zones (like mine) would end up being throttled if the scan_interval was (say) 60 seconds:
- 12 polls per scan_interval = 720 polls per hour (was actually 780/hr).
This didn’t apply to RoundThermostat, which functioned as a single zone = 60 polls / hr - so it was OK to remain on 60 sec for them.
A while ago, Honeywell changed teh way their api rate limits worked, instead severely limiting the number of Authentications per unit time, and you would notice this if you restarted HA (say) 5 times in a few minutes (which is not that uncommon if you’re debugging a new automation or some such).
I got involved with the author of the client library and we re-wrote it to cache the authentication tokens to get past this limit - the new PR (which is to be merged before honeywell component deprecates RoundThermostat support) supports this & will have a 60 seconf scan_interval again (default 180 seconds).
FWIW, when developing/testing, I use a scan_interval of just 10 seconds!!
This is just one example of the many improvements between honeywell and evohome. Another (for evohome users) is that evohome uses only one poll per location (rather than one per zone) per scan_interval.
@corneyl would you consider closing the issue on HA’s github?
2 Likes
Hi excuse my late reply, I’m not too good with how this forum works an didn’t see your reply until today.
I’ve just installed the latest version of the custom component v1.5.1 and it seems to be working OK even with the DHW (hot water) temperature.
I had to change my automations to use water_heater.dhw instead of climate.hot_water but now that I’ve done that, it all seems to be working as intended. I’ll keep an eye on my logs for anything strange.
Also 0.01 temp increments would be nice, but not really essential for me. Also I have hit the rate limit in the past with the old climate component, and by the sounds of it the new component should not have the same issues, I’m just using the defaults for everything, I want to walk before i can run!
FYI - the new climate architecture is coming out for Home Assistant very soon (beta in a week, maybe).
I am actively migrating evohome as we speak!
When that happens, the next feature PR will be for higher-precision temps, and we can drop the custom_component version!
1 Like
Just in time for Summer!
I’m holding my breath for the new architecture release. And also for migration to the standard component. I came to rely on the custom component for so long and really appreciate all the hard work that went into it. So thank you for this component and good luck to all for the next steps. Thank you zxdavb
The final evohome PR has been merged - woot!
I would love people to test when it goes beta - expect a bit of a mess: climate support has been completely re-architectured, but it is definitely going to be worth it!
Will be in 0.96b2
2 Likes
I am gonna test it! Thx for your great work! Do i have made changes to configuration.yaml when the beta is released?
evohome:
username: !secret evohome_user
password: !secret evohome_password
scan_interval: 300 # seconds, you can probably get away with 60
v0.96b2 has been tagged (released).
Please do install the beta test it & report any bugs (the whole thing was re-architectured). The YAML is the same, but the scan interval can now be 60 seconds! The updated docs are here:
Please feedback any issues via https://github.com/home-assistant/home-assistant/issues?
I have update my HA and delete my custom component, but i get the error doesn’t setup evohome.
2019-07-13 21:07:53 ERROR (MainThread) [homeassistant.setup] Error during setup of component evohome
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/setup.py", line 153, in _async_setup_component
hass, processed_config)
File "/usr/src/homeassistant/homeassistant/components/evohome/__init__.py", line 98, in async_setup
if not await broker.init_client():
File "/usr/src/homeassistant/homeassistant/components/evohome/__init__.py", line 135, in init_client
await self._load_auth_tokens()
File "/usr/src/homeassistant/homeassistant/components/evohome/__init__.py", line 185, in _load_auth_tokens
if app_storage.get(CONF_USERNAME) == self.params[CONF_USERNAME]:
AttributeError: 'NoneType' object has no attribute 'get'
@Cinamon I have been able to reproduce this bug - will sort out a fix today.
You couldn’t submit a issue at: github.com/home-assistant please - it will make it easier for the bugfix PR to get into the beta.
Are you (or anyone else) willing/able to edit one of the python source files?
If so, edit /usr/src/homeassistant/homeassistant/components/evohome/__init__.py so that is has (from about line 190):
async def _load_auth_tokens(self) -> Tuple[
Optional[str], Optional[str], Optional[datetime]]:
store = self.hass.helpers.storage.Store(STORAGE_VERSION, STORAGE_KEY)
app_storage = self._app_storage = await store.async_load()
if app_storage is None:
app_storage = self._app_storage = {}
if app_storage.get(CONF_USERNAME) == self.params[CONF_USERNAME]:
refresh_token = app_storage.get(CONF_REFRESH_TOKEN)
...
You’re adding these two lines:
if app_storage is None:
app_storage = self._app_storage = {}
I will submit an urgent PR to homeassistant.