Hey all - anyone else getting a warning about the climate._home entity needing renaming?
I don’t think the latest version of evohome/HA gives this message any more? Can you provide the actual text of the message?
Latest ‘released’ version of custom component is 1.2.1:
https://github.com/zxdavb/evohome/blob/master/custom_components.json
Latest version of HA is 0.90.2:
Aah I’m on 0.90.1 - let me update and check if it still shows up
There is a new version, v1.4.5. It has a few changes, and leverages the newest client library:
- code tidy-up
- much less logging
- more tolerant of API rate limits, especially with v1 api calls
- sets groundwork for resuming state between HA restarts (to stop blowing API rate limits)
- high-precision (to 0.05) temps for DHW
- ultra-high precision (to 0.01) option is available via sensors
- much better exception handling / error messages
- DHW shows current temp as target temp workaround
This post shows how to try it - I will push it to master if there are no complaints: Official Honeywell evohome/Round Thermostat integration (EU-only)
Ah sorry, missed this. I will try it out today and report back. Thank you very much!
v1.4.9 released to master. Those using custom_components.json
(recommended) can update automatically.
For HA v0.92+, see:
https://github.com/zxdavb/evohome/issues/44
It will eventually be merged into master.
Hey @zxdavb, did you ever get around to pulling that HGI80 out of the box? I’d love to eventually move over to a local solution.
Sorry, this project is on hold until I finish the other projects I am actively working on.
I would be planning to have something in place before next Winter though.
That would be awesome. Thanks for the update!
Hi all, sorry for bothering you but I searched around this forum without finding a response.
This custom component allows using the evohome system as Local?
Because looking at the recent closure of nest’s API I’m a bit scared of cloud solution.
Thank you all in advance.
That was the question I just asked about the HGI80 (which would be the local solution). He said he’d try before next winter… But you’d have to buy a HGI80. For now, cloud only…
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…
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.