Honeywell CH/DHW via RF - evohome, sundial, hometronics, chronotherm

zxdavb · November 29, 2019, 6:03pm

This uses RF to eavesdrop honeywell-based CH/DHW traffic, including evohome, sundial, hometronics, etc. - it does not use MQTT, node-red, etc.

This is beta code. It almost certainly wont break anything, but you never know

NOTE: you will need a USB dongle, either a HGI80 or something running this firmware (~£30)

It uses a client library, evohome_rf (WIP) that listens to the RF traffic and maintain a data structure that HA can poll.

The long-term plan for this library is to replace your controller (possibly with enhancements such as, e.g. more zones).

There is a corresponding HA custom_component, evohome_cc, that will expose the following data:

Thermostats (temperature, battery_level)
TRVs (temperature, heat_demand, window_open, setpoint, battery_level)
other stuff, with more to come

You will need to add the custom component in the usual way - eventually it will be added to HA as an official integration.

Note that the most reliable/up-to-date information will be on the two github.com repos, above.

Untitled

Cinamon · November 30, 2019, 9:28am

How can I help?

zxdavb · November 30, 2019, 9:58am

Sorry, I should have already provided instructions…

See the (just created now) Installation Instructions here:

github.com

zxdavb/evohome_cc/blob/master/README.md

# evohome_cc

(WIP) HA custom_component for Honeywell Evohome RF protocol.

Uses https://github.com/zxdavb/evohome_rf (requires a Honeywell HGI80 or [similar](https://www.automatedhome.co.uk/vbulletin/showthread.php?5085-My-HGI80-equivalent-Domoticz-setup-without-HGI80)).

## Installation Instructions

You will need a working version of HA, after verion 0.100.  You will need a HGI80, or [similar](https://www.automatedhome.co.uk/vbulletin/showthread.php?5085-My-HGI80-equivalent-Domoticz-setup-without-HGI80).

Download the custom component in your custom_components folder, in `custom_components/evohome_rf` (best way):
```bash
git clone https://github.com/zxdavb/evohome_cc evohome_rf
```
... or (if you cant/wont be using git):
```bash
mkdir evohome_cc
curl -L https://api.github.com/repos/zxdavb/evohome_cc/tarball | tar xz -C evohome_cc --strip-components=1
```

This file has been truncated. show original

Please provide feedback here.

GadgetUK · November 30, 2019, 10:19am

@zxdavb I’ll give it a go just as soon as I’ve either
a) Moved my HGI80 interface onto the HA Server
b) Figured out how to send the HGI serial info over the network to the HA server

zxdavb · November 30, 2019, 10:25am

What are you using it for now, I wonder?

The client library uses pyserial-asyncio, so there is a chance you can use the serial port over the network, see: URL Handlers — pySerial 3.4 documentation

GadgetUK · November 30, 2019, 10:28am

Current use, mainly tinkering with MQTT, used it originally with Domoticz when the system first went in to get an idea of what it was actually doing.

Serial over the network would be great, means that a PiZero with the HGI80 could be located for optimal reception eg where the current evohome controller is.

zxdavb · November 30, 2019, 10:49am

Eye candy from last night (I do not know why there are gaps [EDIT - now fixed]):

Note: Zone temperatures (°C) / heat demand (%) are not on these graphs, only Device temperatures / demand.

You need to know:

FC is the central heating (i.e. what evohome is asking the central heating to do, once it’s considered what the devices are saying to it)
04 is a TRV
34 is a round thermostat

Demand is roughly the % time that a device thinks it should be provided with heat (you can think of how far the current temp is from the setpoint).

FC demand (you see the equivalent of this in the evohome controller’s UI) is the max of all the zone demand (you see the equivalent of this in the controller’s UI), which themselves is the max of all the device demand for devices in that zone.

I believe a zone’s temp is the average of the temps of all devices in that zone, so will be skewed by the TRVs - which are sitting on top of hot water pipes.

zxdavb · November 30, 2019, 10:54am

Sound like a great idea - happy to work with you on this (I don’t have any Pis).

GadgetUK · November 30, 2019, 12:15pm

Great, think I might spin up a new HA Docker instance for this, should help with debugging.

scstraus · November 30, 2019, 11:42pm

Awesome to see this become a reality! I am busy fixing some things that broke during a migration to new hardware, but when I get that sorted and the work travel settles down, I’m going to make the plunge.

Quick question, how does this interoperate with the existing Evohome system? ie
-Can I run this alongside the existing evohome integration?
-If I set thermostats with this, will it have any negative effect on the normal evohome controller, or will it sync up with the changes requested by this integration?
-Is there anything else I should avoid doing to ensure my heating doesn’t go hawire?

scstraus · November 30, 2019, 11:50pm

Wow, seems a lot more powerful already… Does the demand work better than the standard evohome integration? Seems like it’s more “real” rather than “estimated”.

zxdavb · December 1, 2019, 8:53am

I have pushed an update to both repos this morning with several bugfixes/improvementnts, including the return of zone data (is read only), and elimination of the ‘gaps’ in the graphs…

Presently, this system operates in a ‘eavesdrop’ mode - it mostly listens, but does send some commands in the first minute or so to discover’ parts of the system.

Yes, you can run the two together. I have anecdotal evidence that it seems impossible to ‘break’ a controller by sending it dodgy commands over RF; infrequently the controller has had to be rebooted after being (intentionally) sent poorly-formed commands.

You cannot set temps with it at present - when it gets to the stage that you can, this will be OK (this RF integration will ask the controller to change it’s state, and the RESTful integration (original API) polls data that is sourced from the controller.

The long-term plan is to have this (optionally) replace the evohome controller - you can be listen-only, or read-write, or full replacement.

Yes, this integration has to be better - the RESTful integration is essentially guessing, and is binary rather than a %.
.

scstraus · December 1, 2019, 1:05pm

Cool, sounds great.

So when you say read-write or full replacement, do you mean that read write would work alongside an operational evohome controller, and full replacement would mean having no evohome controller? Would there be anything you could do without the evohome controller that you couldn’t do with the controller still there? Currently I override the evohome controller with automations that put it into permanent manual during the summer, spring, and fall months with the heat level changing based on the weather forecast, and also for special events like if we have a guest or someone staying home who would normally be at school/work. But once the temperature is low enough I hand over to the evohome controller’s standard schedule. I do like having that as a backup incase I do something to brick my hass setup, which is not completely unknown to happen.

Controlling locally would be quite nice for me too, as the REST interface performs very slowly for me, like 5-10 seconds before I see the requested changes take effect. It doesn’t inspire much confidence with my family when they use it because they think it didn’t do anything when the state goes back to what it was before prior to really changing to what they set it to.

But even just for more accurate graphs it will be very nice. The graphs are probably the thing I actually use the most, as when the system is working as intended, no manual intervention is needed.

zxdavb · December 1, 2019, 2:29pm

Three modes:
a) eavesdrop: listens for data that is not available via Honeywell’s official RESTful API
b) augment: send commands direct to controller, rather than via Honeywell’s internet servers
c) control: Honeywell controller turned permanently off (no devcies will be bound it it anyway) everything controlled by this code

a & b) will work with a HGI80, c) will require an RFbee or similar.

Yes. For example: more than 12 zones, more than 1 DHW, use devices other than from Honeywell as thermostats, TRVs, etc. Use different algorithms for zone temps, etc. All this is possible only with option c).

I am not sure what you mean by this: I cannot see option c) being any faster than IRL (i.e. if you make a change via your local controller).

Changes via HA (then to internet, then to controller) introduce a delay of a few seconds, but you’ve got to wait fro the TRVs to next poll the controller in any case (that takes minutes).

And the graphs of heat demand are very useful.

scstraus · December 1, 2019, 2:37pm

That answers all my questions, thanks! Some clarification below.

Making changes from the evohome controller shows up in the evohome UI instantly as being changed, so that’s not an issue, even if in reality it’s a few minutes before the TRV is updated.

But making changes from hass UI usually results in the setpoint in the hass UI going back to the temperature it was set at previously, and then after 10-20 seconds finally changing back to the setpoint I tried to set it to originally (at which time the evohome controller UI updates too). I’m assuming the lag is just the cloud API responding very slowly to the request and hoping this would be fixed with local control…

dariusz · December 1, 2019, 2:42pm

Can this also work with Hometronic Manager ‘HCM200D’?
As basically ‘HGI80’ was developed for ‘HCM200D’…
I’m asking because I have HCM200D based system working perfectly since many years.
The only ‘minus’ - no way to integrate it with other systems (no info in Internet).

hcm200d%20hgi80

zxdavb · December 1, 2019, 6:04pm

@dariusz I think your chances are fairly good, I’ve already picked up traffic that suggests the HGI80 is compatible with the Residential Network Protocol.

Easiest thing to do is download & run it! You’d have to connect the HGI80 directly to a system running python, but if it was needed for other purposes, there’s no reason why you couldn’t have two HGI80s, the second used by HA.

zxdavb · December 1, 2019, 6:10pm

This has got to do with convergence within HA - it is an issue with all polled systems. It is just that the convergence is greater for cloud-based systems, and thus more noticeable. Switching to b) would make this period of time very small, and to c) would eliminate convergence.

dariusz · December 1, 2019, 6:20pm

Well, I do not have yet HGI80, as I could not get answer/confirmation from local ‘Honeywell’ that it will work with ‘HCM200D’.
However I’ll consider to buy one (price ~150EUR) and give a try/test…

Easiest thing to do is download & run it! You’d have to connect the HGI80 directly to a system running python, but if it was needed for other purposes, there’s no reason why you couldn’t have two HGI80s, the second used by HA.

zxdavb · December 1, 2019, 6:45pm

Oh, I thought you were saying you’ve got one!

Maybe you could consider an RFbee (or similar) instead - it will be cheaper, and offer more functionality (but is possibly less compatible). see here:
https://www.automatedhome.co.uk/vbulletin/showthread.php?5085-My-HGI80-equivalent-Domoticz-setup-without-HGI80

Or maybe someone could loan you a HGI80?

The above forum is the best place to ask about Hometronic too.