Interesting, thanks for the tip! Wasn’t aware that the module existed.
Install @namadori’s code as a custom component. One way is to name the file honeywell.py (and ‘overwrite’ the built-in version, the other way to to name it (say) evohome.py, and you’ll have to make a corresponding change to configuration.yaml).
1 Like
i use @namadori code as custom components and work very well for around 1 hour, then stop working.
I think the problem is already know : Update Honeywell thermostat component to new API
Someone have a fix for this?
Thank you.
I am getting the same error after an hour. I note also that - except for initialization - the thermometer temps/setpoints are never updated. I have only just started looking at the cause (but my python debugging skills are limited)…
TL;DR: Honeywell evohome components (zones, not locations) should have one of the following (proposed) operating modes: FollowSchedule (per schedule), TemporaryOverride (until a time), PermanentOverride (indefinitely), or Override (by the controller of the location). For example, Away mode should be configured at the location level, but evohome locations are yet to be implemented in Hass.
…or, for the courageous:
I am working on creating a custom component for the evohome location/controller (not the zones, a.k.a. thermostats) using @namadori’s GIST as a basis (i.e. evohome-client v2 api, Hass currently uses v1) - just stuck with an OAuth token expiring after an hour…
Anyway, there is an ‘architectural’ issue that should be raised. I should start by saying (for those who don’t know) that a evohome implementation almost always consists of a location, which has a number of zones (which are not mere thermostats, but often a ‘master’ thermostat, and a number of actuators, one for each radiator in the zone).
- each evohome zone can have operating modes (Away mode isn’t one of them), i.e. “PermanentOverride”, “FollowSchedule”, “TemporaryOverride” (although it can be overridden by a mode from its location) - it doesn’t have an Off either (it used 5C, PermanentOverride for that)
- each evohome location/controller (actually a hierarchical gateway, location, controller triplet assumed to be 1:1:1) can have it’s own (distinct from the above) operating modes, being: “Away”, “Auto”, “AutoWithEco”, “AutoWithReset”, “DayOff”, “Custom” and “HeatingOff”
That is, to set Away mode, you configure the controller, not the zone. However, I note that Hass does not currently implement the location/controller as a separate component.
So, from a UI point of view, I think there should be a separate component for the evohome location (e.g. Home, Work), and maybe the component should be implemented as a group, which includes it ‘child’ zones?
Interestingly, the climate component class (the UI, anyway) seems to fail to accept that a climate object may not have a temperature. In fact, the evohome location may have a setpoint, or not (but never a temperature, unless you count outside air temp, which is not exposed by the API) - e.g. setpoint=10C for Away mode.
Yes @namadori’s code does stop working after an hour. It’s because it uses evohome-client2 (which uses v2 of the honeywell API), after the OAuth token runs out. There is a way to extend token life - but it seems (to my noob eyes) that this is not exposed within the evohome-client2 code.
Anyway, I have added the following work-around to @namadori’s code (my update code is different to @namadori’s , for val in self.client.temp...):
def update(self): try: ... except TypeError: _LOGGER.error("Update failed: TypeError (has token timed out?)") self.client.access_token = None self.client._login() return
I don’t think it is very pretty, but it works! My log file looks like this (FYI, HA was started at 18:07):
root@lxc-home:/home/hass/.homeassistant# cat home-assistant.log | grep -E ERROR 2018-04-03 19:07:21 ERROR (SyncWorker_7) [custom_components.climate.evohome] Update failed: TypeError (has token timed out?) 2018-04-03 19:07:21 INFO (MainThread) [homeassistant.core] Bus:Handling <Event system_log_event[L]: timestamp=1522778841.8843508, level=ERROR, message=Update failed: TypeError (has token timed out?), exception=, source=custom_components/climate/evohome.py> 2018-04-03 20:07:33 ERROR (SyncWorker_8) [custom_components.climate.evohome] Update failed: TypeError (has token timed out?) 2018-04-03 20:07:33 INFO (MainThread) [homeassistant.core] Bus:Handling <Event system_log_event[L]: timestamp=1522782453.8973763, level=ERROR, message=Update failed: TypeError (has token timed out?), exception=, source=custom_components/climate/evohome.py> 2018-04-03 21:07:45 ERROR (SyncWorker_8) [custom_components.climate.evohome] Update failed: TypeError (has token timed out?) 2018-04-03 21:07:45 INFO (MainThread) [homeassistant.core] Bus:Handling <Event system_log_event[L]: timestamp=1522786065.8959394, level=ERROR, message=Update failed: TypeError (has token timed out?), exception=, source=custom_components/climate/evohome.py>
Notice an ERROR every hour, rather than every 5 mins after the first hour. Other than that, it behaves as expected.
I think this is wrong the wrong approach - the evohomes Zones (a.k.a. thermostats) have their own operating modes (Auto, TemporaryOverride, PermanentOverride). It’s the evohome Controller that has the Auto, AutoWithEco, Away, etc. modes.
I am refactoring @namadori’s code to expose the controller as a component.
Also, I have suggested a change to the setup_platform routine, which I think significantly reduces startup time for the component. See my comment at @namadori’s GIST for more information.
Hi everyone,
first, thank you all for reviving the interest on the topic and for trying my (dirty) code 
I’m sorry I’m really busy at work and currently I have a little time to devote to HA and the Evohome component, I will try to read the thread and all the useful comments this weekend. I hope combining our effort we will have soon a working implementation of zones and operating modes.
The code is still dirty, but (IMHO) somewhat improved. There are still plenty of bugs. Please use the gist, below & I would appreciate any helpful suggestions- I only started learning Python a week ago!
When it starts up, just give it enough time to update (scan_interval) - there’s a bug during init(). You can set the system mode of the location/controller (AutoWithReset doesn’t work yet), and it should show you the operating mode of each zone.
https://gist.github.com/zxdavb/3556bc7f59847d70f695e855f11721ff
FYI: If you get an error message UnicodeEncodeError: 'ascii' codec can't encode character '\xb0' in position..., I used this workaround (search the thread for ‘workaround’):
1 Like
Hey guys, any update on this matter?
So as an Evohome and Domoticz user, that has implemented with cloud free option of the HGI80 the work that the team over at Domoticz has done is flawless.
The protocol was reverse engineering all the way and the results has been amazing. To integrate Evohome with Hass, until someone is going to covert one of the 3 implementation approaches used and proven in Domoticz as native reimplement components there is one solid option
Implement Evohome native with Domoticz and bridge the two systems (Domoticz and Evohome with Home Assistant) using the reliable MQTT protocol.
I am personally pulling out of Evohome due to major challenges with stable communication between the hub and the TRVs and Relays. As there is no repeater or meshed options. My home is simply to large.
I completely re-wrote the thing (there are various reason why that is a good idea). I’m also in the middle of adding functionality (e.g. WindowOpenMode).
One major change from the above version (so far) is that the controller no longer reports a temperature, only a state (e.g. in Eco mode) [yes, I know the controller can be used as the thermometer for a zone, but it is still the zone that has the current_temperature, not the location/controller].
Also, the temps are reports in tenths, instead of halves using a combination of v1 and v2 of the client api.
Things are on pause because another project came up, and (it’s an old story, I know) my dev platform died.
I will make it my mission to upload a working version ASAP & will post here when it is done. In the meantime, you can try it as is, and I’d be grateful for any feedback there (i.e. on github):
For those who don’t know a HGI80 is a USB gateway to the evohome RF network.
Yes: cloud-free, but also approx £100 for a HGI80 (if you can get one). FWIW, there is a project about to use an off-the-shelf device for this:
Curious, after spending so much money on all those expensive TRVs, what are you moving to?
I have successfully sold most of them at a little less than my original cost due to the bulk purchase, thankfully. I will have a few more insitu which will be removed in the next 6-8 weeks after running in parallel with the replacement.
So to answer the question. Eurotronic Spirit TRVs (€37 on amazon.de once a month) and using Heaty AppDaemon as the scheduling engine. Initial tests have been good, and the mesh from Zwave is holding well so far.
More testing needed but so far the only issue I have with openzwave and home assistant is that it the build has no support for v4 thermostat which translates to the valve position sensor not being processed. Not a show stopper, and looking to drop the hass container approach for now to use a python venv with a beta build of openzwave which has the features. (At least to validate)
Evohome is a great solution do not get me wrong, just without the mesh fails to have reliable communication in my home. Which results in lots of problems with heat not demanded when needed or not cancelled when it’s already closed the TRVs valve in the zone.
Damian
@namadori, @eh50, @PItax , @jarrah, @AlexBeumer (who may be interested in this post)
I wonder if any of you may be able to start using/testing the latest version of my evohome component. It is completely new. I have two screenshots, one showing the controller and its state (e.g. Auto, AutoWithEco), and another showing a zone with temp & state (they are very boring because my house is in Away mode).
I know it’s getting warmer, but maybe some lives a little further north than me?
Anyway, my goal is to get it accepted by HA before next EU winter. It has a lot of work required in terms of complying with HA’s style guidelines, and I am sure it has a few bugs to iron out.
Although it’s quite warm. If you have some sort of howto for me to implement it I will test gladly.
Okey so we got a Bean recently too… so excuse me. I’m looking at the extensive install instructions now.
Ha! my Bean is now 6.
Just check which version you clone - I just made a very recent commit.
Hi - happy to help, thanks for your effort integrating evohome into HA!
Hit a snag during testing of the config:
Testing configuration at /home/homeassistant/.homeassistant
Failed config
evohome:
- Invalid config for [evohome]: required key not provided @ data['platform']. Got None. (See ?, line ?). Please check the docs at https://home-assistant.io/components/evohome/
Evohome has been extracted into custom_components:
pi@hassbian:/home/homeassistant/.homeassistant/custom_components $ ls -al
total 64
drwxr-xr-x 5 homeassistant homeassistant 4096 Jun 9 20:12 .
drwxr-xr-x 10 homeassistant homeassistant 4096 May 2 21:26 ..
drwxr-xr-x 2 homeassistant homeassistant 4096 Jun 9 19:57 climate
drwxr-xr-x 3 homeassistant homeassistant 4096 Jun 9 20:05 evohome
-rwxr-xr-x 1 homeassistant homeassistant 32833 Jun 9 19:57 evohome.py
-rwxr-xr-x 1 homeassistant homeassistant 1210 Jun 9 19:57 LICENSE
drwxr-xr-x 2 homeassistant homeassistant 4096 Jun 9 20:05 __pycache__
-rwxr-xr-x 1 homeassistant homeassistant 3612 Jun 9 19:57 README.md
The main configuration.yaml just has these 3 lines as advised:
evohome:
username: !secret evohome_username
password: !secret evohome_password
Won’t be able to test anymore this evening but can try any suggestions tomorrow.
Thanks!