BST (GMT + 1) - I’m in Bristol. UK.
I have refactored evohome (again) - to fix some bugs (e.g. issue #25985), and improve the behaviour, e.g.
- changing the temp of a zone is temporary, and reverts at the next setpoint
- DHW now supports away mode (permanently off)
I really need some people to test it, including DHW (I don’t have DHW) which was broken. Is anyone up for that?
Easiest way would be to create a dev environment (on, say, Ubuntu), but using my repo instead of HA’s.
You can keep your existing HA running - you shouldn’t exceed any API limits.
2 Likes
I’ve recently added a new zone to my evohome system, how do I get HA to recognise it ?
Reboot HA? If that doesn’t work - submit a bug via: https://github.com/home-assistant/home-assistant/issues
Good luck.
Hi @zxdavb I just want to say thanks for the hard work you’ve put into this component.
Specially regarding the DHW, I’ve always had an issue where by the water was cold when someone used the hot water between the scheduled heating cycles I have but now that its reporting the correct current temperature as well as having the option to turn it on or off I was able to create a node-red routine to keep the water hot between schedules.
Thanks again.
Thanks!
The next project will be HGI80 (or similar) integration - this means no need for Honeywell’s servers.
1 Like
Ok, that’s got it.
1 Like
HGI80 integration would be great, especially if it gets to the point where temperature sensors within HA could be used as inputs to Evohome.
1 Like
Will be a huge benefit for responsiveness of it, and to get around the sometimes spotty availability of the honeywell cloud service.
With Homeassistant 0.101; how can I now enable high precision? According to the changelog it should be included now, but the addition of “high_precision: true” returns an error…
It should just do high_precision (you can’t turn it off, nor on).
If there is a problem with retrieving HP temps, it will fall back to using ‘normal’ precision - check your logs fro the relevant error message, “Unable to obtain the latest high-precision temperatures”.
Although HA deals in temps to 0.1, the HP temps are available to 0.01 via sensor templates.
I have used a rather klunky implementation with an HGI80 and my main issue is dependability. I find the Honeywell Server approach much more reliable, no missed information (except when their servers are down).
What I do like is being able to get at the individual heating demand from each zone though. It would be great in your next version if you could support both modes concurrently to augment the cloud information or totally fall back to local if the servers were AWOL. Or maybe load and run two versions of the app ?
Are you referring to a competitor HA platform - I know of only one other… or MQTT with HA?
Anyway, all the code I’ve seen is not suitable for my plans: evohome-radio will be a big project - could easily take over a year to get right.
It will probably be implemented as distinct integration.
The initial implementation will be read-only, so: temp, demand, actuator and window states. I hope to get that up & running in a few months…
When the time comes, I will need people with HGI80s (or HGS80s, or bespoke equivalents) to get involved in testing, particularly with DHW and UFH (which I don’t have).
Yes - the D… one.
I use MQTT extensively here and hadn’t thought through that possibility… I’ll do a bit of research… I assume you didn’t just mean onwardly bridged from D? I see you mention HA/MQTT. There isn’t an HGI80<>MQTT app I’ve missed on some platform is there ?
Yours sounds a great project, and very thorough, I shall watch with interest. I can help with HGI80 and DHW although no UFH.
At the risk of losing business to a competitor: 
I haven’t used it, I find MQTT relatively unreliable - my plan is to bypass MQTT altogether.
I’ve got UFH and furnace control and a HGI80… I’m ready to test
Got it! And is working now.
Another quick question; what does the green area in the graph mean? Is it the time that the system is actually heating an area?
1 Like
Hey looks good!
The green bit (CURRENT_HVAC_HEAT) is supposed to be when the zone is calling for heat. Whether it is actually getting heat - or not - is up to the boiler, and the TPI algorithm.
However, in the case of evohome, it is an educated guess:
def hvac_action(self) -> Optional[str]:
"""Return the current running hvac operation if supported."""
if self._evo_tcs.systemModeStatus["mode"] == EVO_HEATOFF:
return CURRENT_HVAC_OFF
if self.target_temperature <= self.min_temp:
return CURRENT_HVAC_OFF
if not self._evo_device.temperatureStatus["isAvailable"]:
return None
if self.target_temperature <= self.current_temperature:
return CURRENT_HVAC_IDLE
return CURRENT_HVAC_HEAT
1 Like
TBH, the green bit is a little unsatisfactory (it is misleading) - I am looking at tweaking it, but TBH, I think I should just take it out.
1 Like