putting the controller into ‘Away’ turns the hot water off
putting the controller into ‘Auto’ or auto with reset or ‘AutoEco’ puts it back to ‘FollowSchedule’
HeatingOff doesn’t change the overrides
DayOff doesn’t change the overrides
No - I want to focus on getting it into HA - may take a while!
Sorry, but could you/@Isablend/someone kindly confirm all 8 scenarios:
- Controller goes to a)
Auto(orAutoWithEco,DayOff), b)AutoWithReset, c)Awayand d)HeatingOff - DHW was in 1)
TemporaryOverrideand 2)PermanentOverride
For example, I think:
a) will cause 1) (but not 2) to go into FollowSchedule, whereas
b) will cause both 1) and 2) to go into FollowSchedule
Sorry will be Saturday before I can fully test because I can’t confirm state at the evohome consol because ironically i’m Away.
One thought, not totally relevant but I must admit I never put it into Away mode, but I do turn off hot water, anyhow will do all tests if not complete when I’m back.
if hot water is in PermanentOverride then changing the settings to auto, autowitheco, autowithreset and day off does nothing to the permanent override of hot water. Away turns it off permanently, heating off does nothing to the override.
if hot water is in temporary override then changing the settings to auto, autowitheco, autowithreset and day off does nothing to the temporary override of hot water. Away turns it off permanently, heating off does nothing to the override.
Some of you have multiple locations. You may know that you can choose which location to use in HA.
I have just posted on how to have two (or more) locations active in HA at the same time - you can even have both with high_precision temperatures:
https://github.com/zxdavb/evohome/issues/10
@zxdavb finally got round to doing the testing you requested, my results are as follows;
| DHW - TemporaryOverride | DHW - PermanentOverride | ||
|---|---|---|---|
| Auto | FollowSchedule | PermanentOverride | |
| AutoWithEco | FollowSchedule | PermanentOverride | |
| AutoWithReset | FollowSchedule | PermanentOverride | |
| Away | FollowSchedule | FollowSchedule | |
| HeatingOff | PermanentOverride | FollowSchedule |
I put the system back to auto before each change, then applied the DHW setting, before applying the overall status, then going back to DHW to record its updated status. Hope that helps.
@zxdavb One other thought (not related). I remember reading a while back on another forum that Honeywell had provided access to information about individual zones heat calls. To get to the information you have to go into the settings->system summary menu on the primary controller where each zone is listed along with the % heat calling value. Is there any way that information could be exposed in HA? Its useful information in being able to understand and problem solve in the event that there is a problem.
I am aware of this feature, It is quite useful (in my case, it identified the room that was missing ceiling insulation & I wouldn’t have known otherwise).
Sadly, there is no known way of obtaining this information via the Honeywell api.
I understand the information is available via a HGI80 (a USB-RF gateway from Honeywell, but 3rd party gateways may work too), but HA (unlike domoticz) does not (yet) integrate with that device.
Although I do have a HGI80, I do not have the capacity to take on that project.
A version of this component has just been accepted into HA’s dev branch today (PR #16427). However, you will probably want to continue using this version for now…
Shout to @namadori!
2 Likes
That is GREAT!!!
I LOVE THIS! Great stuff!!!
Awesome news - thank you!!
@zxdavb Next question, arose today as a result of an actual experience where I had batteries in the Hot Water sensor which had died. Is there any way of getting the individual sensors to expose battery level? I checked the current entity attributes and see that that info is not available currently. Can it be?
Sorry, no: battery levels are not exposed via the api. What is exposed is: {'activeFaults': []}, and depending on your configurations, this may be in home-assistant.log.
Maybe you could find the data in your logs & - if so - post it here? Might be useful…
@zxdavb thanks for the response. I’ve got a Hassio setup so not sure where to search for the .log file, but will try. I think I will need to wait for another battery failure and then get logging on and see whats reported. In this case it was a battery report from the Hot Water sensor, but would imagine that any of the radiator sensors might also report in the same way. I’ll report back when I’ve got something of use.
@zxdavb ok found the log file and have an error in the system, reporting a comms fault with the heating valve actuator. Would be interested to know if there are any indications of this in the attached logs.home-assistant-log.yaml (349.4 KB)
@zxdavb Sorry should have also reported that given the time of year, I’ve started over-riding the schedule for certain rooms at certain times of the day. When I try and set a temporary over-ride, its reported back at the entity level as a permanent over-ride. I checked on the Evohome controller and its shown as permanent there also.
The the component is only telling you the same thing as the controller, no?
You have to give me more information. For a start: how are you setting the temporary override? At the TRV, the Controller, Honeywell’s website/app, or via HA?