I wouldn’t switch. I researched all the options thoroughly before buying and I think I made the best choice for me.
And, if I may, what components of the system you’re using? I’m trying to asses the bare minimum for it to work decently with HA, possibly without cloud, but I may live with it for now. As I mentioned I am looking at HR91/92 that seems to be reasonably priced for the features it offer.
I’m using almost everything they offer, only thing I think that I’m missing is the hot water controller (I always want my hot water ready to go). I have some of the round thermostats, 12 zones of TRV’s, boiler controller, the main evotouch controller, underfloor heating controller, etc…
I wouldn’t change a thing, but @zxdavb is working on allowing you to control the TRV’s directly from an HGI-80 so you could potentially get by without the evotouch controller, but it will probably take a while before he’s able to that done, a lot of things to finish before then.
Those are some important improvements! I’ve been hoping for something like those for a while. Nice one!
I have installed Evohome through the simple addition of:
evohome:
username:
password:
IN my configuration.yaml but only get basic control.
Do I have to install further components or lines to get the expanded control?
If so is there any instructions. I apologise if this is covered further up but I have read quite a lot but may have missed it.
What functionality are you calling “basic” and extended”? Most of the functionality is in the official integration now.
Thanks for response. Having read a bit further I understand the recent references are around RF using the HGI-80 which I actually have installed but never made use of it…
What I am looking for is an easy way to temporarily increase a zone temperature for X hours or turn on HW for X mins.
Thanks.
@scstraus Thanks for getting involved, I don’t have a lot of time one my hands, and it’s great if other people can help answer these questions.
Having said that…
There is a PR already awaiting review from a senior dev that will do this for the RESTful evohome inegration via HA service calls.
You can set a new SP indefinitely, until next scheduled setpoint change, or for a duration, or until a time in the future (within the current limits of evohome, e.g. 1-24h or 1-99d). It will require a change to the underlying client to be fully functional.
It is not fully tested - so I will be looking for volunteers.
There is no equivalent PR for DHW, and I will not be able to do anything before the end of Feb (I have a big exam in early Feb)…
Great thanks.
I do it purely selfishly so that you have time to work on the HGI-80 and all the other great features you are putting up 
I’m trying it like this, but it doesn’t even change the temperature. If I do it without setting preset_mode, then it changes the temperature but it uses temporary override… Any idea what I’m doing wrong? I used to get permanent override when I just set the temp, but that appears to have changed.
- id: fire_in_fireplace_now
alias: "Fire in Fireplace Now"
hide_entity: true
initial_state: 'true'
trigger:
platform: state
entity_id: input_boolean.fire_in_fireplace_now
to: 'on'
action:
- service: climate.set_temperature
data:
entity_id: climate.dining_room
temperature: 21
- service: climate.set_preset_mode
data:
entity_id: climate.dining_room
preset_mode: 'permanent'
The issue is the limits HA places upon all Climate entities (which is needed to ensure, for example, seamless interoperability with alexa, google, etc.)
Sorry, I am really short of time, and cannot address your specific question, but I can say this…
The solution to your problem: I have added services to the integration (see below) - the code is done/tested/documented/reviewed/refactored/etc - it is waiting a second review & is ready to go (will need another round of testing - you are welcome to give it as go, but you’ll need to use my repo of HA).
It is only Christmas that is holding this back from being merged into HA.
With services all evohome functionality is now exposed to HA in a form compatible with the evohome UI/UX.
Okay good enough, happy just to know that it’s not because of sometime I’m doing wrong.
Hypothetical question: if I got an HGI-80 (are they still for sale?), would it allow me to have more than 12 zones?
I have a system based on the old (non-wifi) controller and an RFG100 gateway, and it all works fine. But I have more than 12 rooms (once you include en-suites etc)…
You can’t do it with a HGI80, you have to use a arduino nanoCUL, or similar.
Theoretically, yes. In reality - not one has implemented this yet… Someone has implemented a repeater, though.
I have the evo color controller - I believe it supports multi-room zones - will that no do the trick?
I have some multiroom zones in my config, they are adjacent rooms connected by a large sliding door… Actually the controller doesn’t know if all the TRV’s are in the same room or not so you can arrange it how you want… I had to group some stuff together, because I actually needed about 14 zones, but it works fine like this, the zones I grouped don’t really need to have different temperatures.
Yes, I don’t really need more zones, but it would be interesting - in particular I’d like to monitor the temperatures independently. If you have two radiators in the bedroom and a towel-rail in the en-suite, all in a multi-room zone, I wonder how the controller decides on which is the canonical temperature? Does it average them?
Also, since some of mine are towel-rails, it’s really nice to given them a brief burst of heat independent of the others in the middle of the morning, to make sure the towels are dry 
Have you seen:
The canonical temp is from a nominated thermometer sensor (usually a round thermostat, if there is one, or one of the TRVs) - which one is used can be managed (non-intuitively) in the evohome UI.
2 Likes
sorry all, dumb question im sure but i just want to check and confirm as i didnt see a clear description.
when it comes to
Zones support only three setpoint modes: FollowSchedule , TemporaryOverride , and PermanentOverride .
FollowSchedule = whatever has been set via the main hub and the calendar timings etc…
TemporaryOverride = Delay/pause/change for “x” amount of time, will then go back to the “followSchedule” settings
PermanentOverride = set it to whatever you want, until its actually changed. eg. it stays on/off or at “x” temp forever…
so i work at home, i have my office rad on all day, set to 20.
if im out for the day, in meetings/travel - then i want to either turn off the rad or set it down to like 14 (the minimum for all rooms in the house)
does this mean i create an auotmation to set my office rad to change to PermanentOverride = off, after ive been gone for 30min, or i use temoraryoverride and set it to 14, but for how long or do you just do like 999hours or something?
then when i get back, i set the rad back to FollowSchedule ?
would this then just pickup with whatever the standard hub schedule has been set to?