Support for Honeywell (EU-only) Evohome installations: one controller, multiple heating zones and (optionally), DHW.
It provides much functionality that the existing Honeywell climate component does not (e.g. 3 & 4, below) and you can usually run it alongside that component (but see below).
This is beta-level code, YMMV.
NB: this is for EU-based systems only, it will not work with US-based systems (it will only use the EU-based API).
To install this custom component, copy it to ${HASS_CONFIG_DIR}/custom_components, for example:
git clone https://github.com/zxdavb/evohome ~/.homeassistant/custom_components
The configuration.yaml is as below (note evohome: rather than climate: & - platform: honeywell)...
evohome:
username: !secret evohome_username
password: !secret evohome_password
# scan_interval: 180 # how often to poll api, rounded up to nearest 60 seconds, minimum is 60
# high_precision: true # use additional api calls for PRECISION_TENTHS rather than PRECISION_HALVES
# use_schedules: false # long story, but much slower initialisation & other downsides...
# use_heuristics: false # trys to update state without waiting fro next poll of the api
# location_id: 0 # if you have more than one location
- Uses v2 of the (EU) API via evohome-client: several minor benefits, but v2 temperature precision is reduced from .1C to .5C).
- Leverages v1 of the API to increase precision of reported temps to 0.1C (actually the API reports to 0.01C, but HA only handles 0.1); transparently falls back to v2 temps if unable to get v1 temps.
- BIG: Exposes the controller as a separate entity (from the zones), and...
- Correctly assigns operating modes to the controller (e.g. Eco/Away modes) and it's zones (e.g. FollowSchedule/PermanentOverride modes)
- Greater efficiency: loads all entities in a single
add_devices()call, and uses fewer api calls to Honeywell during initialisation/polling. - The DHW is exposed.
- It takes about 60-180 seconds for the client api to accurately report changes made elsewhere in the location (usu. by the Controller).
- Zones may incorrectly report OpenWindowMode (e.g. when Controller is set to HeatingOff). The hueristics will be improved in future releases.
- FIXED, option b): The controller, which doesn't have a
current_temperatureis implemented as a climate entity, and HA expects all climate entities to report a temperature. So you will see an empty temperature graph for this entity. A fix will require: a) changing HA (to accept a climate entity without a temperature (like a fan entity), or; b) changing the controller to a different entity class (but this may break some of the away mode integrations planned for the future). - Away mode (as understood by HA), is not implemented as yet - however, you can use service calls to
climate.set_operation_modewith the controller or zone entities to set Away mode (as understood by evohome). - FIXED: The underlying api (evohomeclient2) has some issues (e.g. no provision to refresh OAuth tokens, that caused failure after 1 hour). A proper fix will require changes to evohomeclient2 (possibly causing the existing honeywell component to break).
- FIXED (architecturally, but still a little messy): The code is currently messy, and architecturally unsatisfying (e.g. the controller updates the zones' private attributes directly).
- FIXED: No provision for DHW (yet). This is in progress.
- WIP: No provision for schedules (yet). This is in progress.
- The
scan_intervalparameter defaults to 180 secs, and could be as low as 60 secs. This is OK as this code polls Honeywell servers only 1x (or 3x) per scan interval (+2 polls for v1 temperatures), or 60 per hour. This compares to the existing evohome implementation, which is at least one poll per zone per scan interval. I understand that up to 250 polls per hour is considered OK, YMMV. - DHW is represented as a switch (with an operating mode) and a switch (for temp). Presently, there is no 'boiler' entity type in HA.