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

Hi @zxdavb

Here’s the updated packet log uploaded on pastebin:

On the CM927 I don’t have any schedule, it’s in manual mode and I modify the target temperature manually.
I hope you have enough data out of it ? I don’t know how to interpret it.
When I’m running evohome_rf manually I have more human readable data on stdout.


If anyone has a HM80, I would love to see the packet log from:

python execute /dev/ttyUSB1 --device-id 01:145038 -o packet.log

You will need to use the bleeding_edge branch of

And you may want to test:

python execute /dev/ttyUSB1 --device-id 01:145038 --get_schedule

I have already ordered my nanoCUL to work with the HM80. I’ll send the packet.log as soon as I had received it. :slight_smile:

1 Like

Hi, will this work with T87RF? (I have T87RF2025)
I’m running hass on Pi4, if I understand the setup correctly, I can connect nanoCUL to it and get the thermostat readings directly, is that right?

What is the round thermostat connected to? Only a BDR91A?

I haven’t specifically tested this, but (I understand the thermostat periodically broadcasts temperature, so) yes, it will work as you describe.

Hello @zxdavb,
Here’s some news with the HM80. I received my nanoCUL, I successfully flashed it with evofw3 0.4.4.

I tried to execute your first command:
sudo python3.8 execute /dev/ttyUSB0 --device-id 01:145038 -o packet.log

I had first results by downgrading to the commit e35e879d0d7485dbb2ab99e994c5eefa92353cf8, “Minor tweak” of the bleeding_edge branch. Otherwise, I got this (with the latest version): Starting evohome_rf...
23:47:46.149 Discovery scripts specified, so disabling probes Finished evohome_rf, results:
01:145038 (CTL) Finished evohome_rf.

If I try to run the second command, each time I get the following error with every version:

Usage: execute [OPTIONS] SERIAL_PORT
Try ' execute -h' for help.
Error: no such option: --get_schedule

Here’s the requested packet.log issued by the first command (commit e35e879d0d7485dbb2ab99e994c5eefa92353cf8):
I don’t know if that will be relevant.

Thank you for your help.

By the way, what’s the difference between master and bleeding_edge branches ? :thinking:

Bleeding edge says it all - no? :rofl:

In truth - there are so many changes to bleeding edge per unit time, even I have problems keeping up. I just did a git diff between bleeding edge and master and it is a lot, here is a selection:

  • added get-schedule, get-faults methods to evohome_rf, added execute command to
  • re-wrote fetcher - exposed as a protocol (a callback), re-wrote packet processor
  • cleaned up signal/exception handler
  • cleaned up QoS (packet layer) and RQ/RP processor (message layer)
  • bugfix parsers, message processors
  • pulled out a system as separate from a controller (lots of work - still WIP)

@Supermarco333 The device 01:145038 is my controller, I doubt your nanoCUL will reach it from where you are. :sunglasses:

So (using the bleeding_edge branch)…

First, you need to eavesdrop your system, and pick up all your device IDs, or least your controller’s device ID (which, if it is battery-powered, is not of much use for probing):

python monitor /dev/ttyUSB0 -o eavesdrop.log

If you wish, you can try an automated probe - this will puzzle each device as they are first seen:

python monitor /dev/ttyUSB0 -p -o probe.log

Once you’ve the device IDs, you can do a deep probe of a device:

python execute /dev/ttyUSB0 --device-id 13:123456 -o deep_probe.log

Let me know how that works for you.

All right, sorry for this confusion. So, after running this command: sudo python3.8 monitor /dev/ttyUSB0 and changing the requested temperature, I got this: Starting evohome_rf...
2020-11-15T17:09:50.203354 # evofw3 0.4.4 
2020-11-15T17:09:55.658374 ||            | THm:193204 |  I | setpoint         | 010866   || {'other_idx': '01', 'setpoint': 21.5} Finished evohome_rf, results:

Schema[gateway] = {"main_controller": null, "orphans": ["12:193204"]}

Params[gateway] = {"devices": {"12:193204": {}}}

Status[gateway] = {"devices": {"12:193204": {"temperature": null, "setpoint": 22.0, "battery_state": null}}} Finished evohome_rf.

This gives me the controller ID.

I ran this: sudo python3.8 execute /dev/ttyUSB0 --device-id 12:193204 -o deep_probe.log

I got the following error: Starting evohome_rf...
17:12:41.925 Discovery scripts specified, so disabling probes
Traceback (most recent call last):
  File "", line 213, in <module>
  File "/usr/local/lib/python3.8/site-packages/click/", line 829, in __call__
    return self.main(*args, **kwargs)
  File "/usr/local/lib/python3.8/site-packages/click/", line 782, in main
    rv = self.invoke(ctx)
  File "/usr/local/lib/python3.8/site-packages/click/", line 1259, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/local/lib/python3.8/site-packages/click/", line 1066, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/local/lib/python3.8/site-packages/click/", line 610, in invoke
    return callback(*args, **kwargs)
  File "/usr/local/lib/python3.8/site-packages/click/", line 33, in new_func
    return f(get_current_context().obj, *args, **kwargs)
  File "", line 104, in execute
    debug_wrapper(**obj, **kwargs)
  File "", line 141, in debug_wrapper, **config))
  File "/usr/local/lib/python3.8/asyncio/", line 44, in run
    return loop.run_until_complete(main)
  File "/usr/local/lib/python3.8/asyncio/", line 616, in run_until_complete
    return future.result()
  File "", line 164, in main
    await task
  File "/home/pi/evohome_rf-bleeding_edge/evohome_rf/", line 227, in start
    await asyncio.gather(*self._tasks)
  File "/home/pi/evohome_rf-bleeding_edge/evohome_rf/", line 78, in get_device
    device = gwy._get_device(dev_addr, ctl_addr=dev_addr)
  File "/home/pi/evohome_rf-bleeding_edge/evohome_rf/", line 263, in _get_device
    self.evo = ctl._evo
AttributeError: 'Thermostat' object has no attribute '_evo'

There was a typo in my previous post (missing -p, I’ve since corrected it), run that fro an hour or so:

python monitor /dev/ttyUSB0 -p -o probe.log

Is your controller battery powered (e.g. a a DTS92A)? If so, it will not respond to any messages sent to it.

The HM80 will probably respond to an RQ, but we won’t know until you run the probe for longer - you’ll need it’s address - it may be picked up with an automated quick probe, or…

You can deep probe the HM80, or whatever else turns up, once you have its address.

Ok, I’m now running the command. By the way, do you know the average range of the nanoCUL ? My Raspberry Pi server is maybe a bit far from the HM80.

Yes the controller is battery powered, there’s two batteries inside. If I remember well, the thermostat is a CMS927B1023.

What’s the effect of “-p” ? You send a message to trigger an answer from devices ?

When it sees a device of a type it recognizes, it sends a sequence of RQs to learn more about that device. This strategy doesn’t work for devices that are battery powered (your controller) - such devices don’t listen for packets to conserve their batteries.

It knows what messages to send which device types (e.g. it wont send a 0418 to a BDR91A).

Other than that, it will eavesdrop.

Here is the probe (discovery) code for a relay:

    def _discover(self, discover_flag=DISCOVER_ALL) -> None:
        if discover_flag & DISCOVER_PARAMS:
            for code in ("1100", "3B00"):  # only a heater_relay will respond? to 3B00

        if discover_flag & DISCOVER_STATUS:
            for code in ("0008", "3EF1"):

I had a question related to Evohome, but (only partially) connected to this topic; can somebody take a look at my other topic (not to spoil this one to much): Usefull upgrading my thermostat to Evohome?

At the risk of being accused of double-posting…

The best place for (HA-agnostic) technical evohome advice is here:

There are very knowledgeable people in that forum (although - for some weird reason - some persist in using Domoticz over HA).

1 Like

Hi zxdavb,

Thank you very much for all the work you have done with this integration. I’m really happy with the result! I have an nanoCUL running with home assistant and your CC, everything is smooth.

Before I got this nanoCUL, I was managing my heating with ‘schedy’, an appdaemon app which allows you to manage your schedule easily, allowing integration with things like window (door) sensors etc. It just controls ‘climate’ entities, in my case the ones from the official evhome API integration, and has been working perfectly the last 1.5 years.

Now with your project and the nanoCUL, I would like to ‘swap’ the entities from the official integration with the ones from your custom component. This is easy by changing the config (and or renaming the entities) but the problem I noticed is that changing the temperature using the climate entity that comes with your custom component, results into ‘temporary’ change (from evohome point of view). This means that it will start to follow the controller/unit’s schedule. Is it possible to make temperature changes done via your custom component are also ‘permanent’ to prevent falling back to the schedule of the controller? This is required to keep home assistant in charge instead of the controller. And yes I can remove all schedules in the controller but I guess at least once a day it will still modify the temperature.

I have searched in this topic and on google but couldn’t find an option to get it arranged. :slight_smile:

This will require a minor update to evohome_cc - you will then have to use a service call, like evohome.set_temperature

Ah so it is possible!

Does it mean that changing the temperature through the climate entity will not be permanent?

Can you point me a bit into the direction what should be changed? There is a good chance I can change it myself if it is a minor change. Or do you have any plans to integrate it in your official version? Would be really nice!

i think this can be done, by looking at how the code in the official API behaves if you don’t pass a duration with the SET_ZONE_OVERRIDE method.

Yes, the official API supports it and this is available by default using a selection-box when you open the climate entity in Home Assistant. This allows you to change it to ‘temporary’ or ‘permanent’. But we’re here talking about the custom component implementation of zxdavb, which doesn’t have this option/selection box.

This is reverse engineering work done to understand the protocol and I don’t think there’s any official documentation available about it…

So my questions regarding this option in this implemenation are still current :slight_smile: