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

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 :wink:

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 repos, above.



How can I help?

Sorry, I should have already provided instructions…

See the (just created now) Installation Instructions here:

Please provide feedback here.

@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

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:

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.

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.

1 Like

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

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

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?

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

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

1 Like

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.

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.

1 Like

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…

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


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

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.

1 Like

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.

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:

Or maybe someone could loan you a HGI80?

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