Honeywell Evohome thermostat: work started, need advice

Development
1

Hi everyone. As I already shared in previous threads, I’m not satisfied on how the current Honeywell implementation works with the Evohome thermostat.
My main concern is that the thermostat can control different zones (working), but has both an individual state and a common “system mode”.

The System modes supported are not the standard “home”, “away”, “off”, but:

  • Base
  • Economy
  • Away
  • Day Off
  • Custom
  • Off

I already started porting the basic functionalities from the “EvohomeClient” to the “EvohomeClient2” library. Now I’m stuck with the system modes, with my basic knowledge I don’t understand if I’m forced to use the modes from the Climate component or I can define some custom modes.
The code to set the system to a specific mode is already in the library (see here ) , the code to read the mode is already implemented. I don’t know how to create the correct interface in HA.

I’m sharing the code in a Gist at https://gist.github.com/namadori/3f3a15bbbae4f8783394993c148cb555 . Any help in making the code better or adding new features is really welcome.

I’m adding people that might be interested: @flashoftheblades, @M00s, @AlexBeumer, @dansarginson

2

Yes please! :slight_smile:

3

The Homematic component uses non-standard modes if you’re looking for a starting point.

4

@andrewdolphin That’s a good hint. Thanks :+1:

5

Thanks to @andrewdolphin suggestion, I managed to make the Honeywell component display the current operation mode and change it.

image
image386×543 20.2 KB

Next steps (as usual help is welcome):

  • connect the system mode of different zones to a single variable (as is it takes some time to propagate the change from the single zone to the other zones
  • friendly names
  • check if component is not making too many requests (one per zone) to avoi hitting server limit rate

Updated code is on linked gist.

1 Like
6

Hi there, will this stuff work if the Honeywell evo home is not connected to the internet? In other words, does is use a local connection or is it only useable through a cloud solution?

I’d like to prevent using clouds and was thinking of using this component with the evo home I am considering to buy.

7

No, afaik the only way to interface with the Evohome thermostat is via the API of the Honeywell Total Connect service.

8

I would just like to pass on my thanks and best wishes with your improvements to the evohome client HA integration. I was hoping someone would be able include these extra features as the ability to change status is a welcome addition.

Btw, how do you produce that graph showing both demand and actual temps? I suppose a more appropriate question is how do I test your code in my HA? Do I just copy the py file somewhere and then reference it in yaml? Does it include that graph capability?

Do you think the backup and restore api feature in whatchforstock’s library could be utilised too, so that many custom schedules could be set to give more options than the default modes?

9

Actually I think you can use a Honeywell HGI80 to talk directly to the evohome controller, or even a 3rd-party RF stick pretending to be a HGI80:

2 Likes
10

Interesting, thanks for the tip! Wasn’t aware that the module existed.

11

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
12

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.

13

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)…

14

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).

  1. 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)
  2. 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.

15

@PItax,

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.

16

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.

17

Hi everyone,
first, thank you all for reviving the interest on the topic and for trying my (dirty) code :slight_smile:

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.

18

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
19

Untitled
Untitled1032×675 53.6 KB

20

Hey guys, any update on this matter?