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

Hi there,

So I started playing with the nanoCUL USB I bought on ebay.
My plan is to control the BDR91 wireless relay with it and integrate it in HA.
My HA setup runs in a docker env inside a VM. I managed to map the /dev/ttyUSB0 and install evohome_rf (not integrated yet).
I have no idea if I need to flash the nanoCUL device and with which firmware.
I’m trying to collect debug logs with evohome_rf but I got this error:

bash-5.0# python client.py monitor /dev/ttyUSB0
config {'schema': {}, 'allowlist': {}, 'blocklist': {}, 'use_schema': True, 'disable_discovery': True, 'disable_sending': False, 'evofw_flag': None, 'enforce_blocklist': True, 'enforce_allowlist': False, 'max_zones': 12, 'packet_log': 'packet.log', 'reduce_processing': 0, 'debug_mode': 0, 'serial_port': '/dev/ttyUSB0', 'execute_cmd': None, 'poll_devices': [], 'probe_devices': []}
Starting evohome_rf...
07:57:30.585 Starting evohome_rf, **config = {'schema': {}, 'allowlist': {}, 'blocklist': {}, 'use_schema': True, 'disable_discovery': True, 'disable_sending': False, 'evofw_flag': None, 'enforce_blocklist': True, 'enforce_allowlist': False, 'max_zones': 12, 'packet_log': 'packet.log', 'reduce_processing': 0, 'debug_mode': 0, 'execute_cmd': None, 'poll_devices': [], 'probe_devices': []}
Traceback (most recent call last):
  File "client.py", line 173, in <module>
    cli()
  File "/usr/local/lib/python3.8/site-packages/click/core.py", line 829, in __call__
    return self.main(*args, **kwargs)
  File "/usr/local/lib/python3.8/site-packages/click/core.py", line 782, in main
    rv = self.invoke(ctx)
  File "/usr/local/lib/python3.8/site-packages/click/core.py", line 1259, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/local/lib/python3.8/site-packages/click/core.py", line 1066, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/local/lib/python3.8/site-packages/click/core.py", line 610, in invoke
    return callback(*args, **kwargs)
  File "/usr/local/lib/python3.8/site-packages/click/decorators.py", line 33, in new_func
    return f(get_current_context().obj, *args, **kwargs)
  File "client.py", line 85, in monitor
    debug_wrapper(**obj, **kwargs)
  File "client.py", line 121, in debug_wrapper
    asyncio.run(main(serial_port, **config))
  File "/usr/local/lib/python3.8/asyncio/runners.py", line 43, in run
    return loop.run_until_complete(main)
  File "/usr/local/lib/python3.8/asyncio/base_events.py", line 616, in run_until_complete
    return future.result()
  File "client.py", line 136, in main
    gwy = Gateway(serial_port, loop=loop, **config)
  File "/config/evohome_rf/evohome_rf/__init__.py", line 131, in __init__
    load_schema(self, self._schema) if self.config["use_schema"] else {}
  File "/config/evohome_rf/evohome_rf/schema.py", line 232, in load_schema
    schema = SYSTEM_SCHEMA(schema)
  File "/usr/local/lib/python3.8/site-packages/voluptuous/schema_builder.py", line 272, in __call__
    return self._compiled([], data)
  File "/usr/local/lib/python3.8/site-packages/voluptuous/schema_builder.py", line 594, in validate_dict
    return base_validate(path, iteritems(data), out)
  File "/usr/local/lib/python3.8/site-packages/voluptuous/schema_builder.py", line 432, in validate_mapping
    raise er.MultipleInvalid(errors)
voluptuous.error.MultipleInvalid: required key not provided @ data['controller']

Any idea what could be wrong?

Use this firmware, using Arduino IDE - the specifics are above.

which version of evohome_rf you using? Use the latest master branch.

I believe this is not the case (IIRC from when I last spoke to the dev). As you can imagine, I have done a lot of back-to-back restarts, and I’ve never had an issue.

@nicoske My apologies - try the latest commit of the master branch now

Thank you @zxdavb !
It now start correctly in monitor mode. I’ll flash the nanoCUL with evoFW3 this weekend.

Sounds good. Setting up a Pi with HA isn’t a big deal for me. Give me a precise check list of what I should do to have a running setup to help you. I just have to mention that the HM80 isn’t in my house, it’s in a friend’s house. Furthermore, the current lockdown in France isn’t helping much. If I succeed in fulfilling your checklist, I will recontact you. :slight_smile:

There has been no recent release because I have been changing the internal architecture of evohome_rf - I have realised there is a difference between the controller (a device much like a TRV, or a BDR91), and a system (the thing that can be in Away, Eco mode).

This has been very painful (and I still have to refactor evohome_rf), but was the right thing to do - otherwise support for non-evohome systems would have been problematic.evohome_rf is/will be used by many more platforms than just evohome/HA.

There have been a large number of other changes (mostly bug fixes, several were significant), but no real enhancements other than recognizing when data is ‘stale’ - i.e. a zone temp from 8h ago is of no relevance. Additionally, I am sorry that:

there is going to be a breaking change.

Zones currently have an entity_id based upon their name (zone_name). This will be changing to something based upon their unique ID (controller_id, zone_idx):

  • they always have the same unique_id from creation to destruction, although their name can be changed at any time
  • evohome zones can be created without waiting for their name to be discovered (which is not sufficiently reliable) before they can be instantiated in HA
  • there will be no collision of entity_id with the official evohome integration.

Note that entity’s unique_id will not change

Someone reported a issue caused by this bug - zone disappearing, or similar.

So, what was:

climate.bedroom

will become (note two underscores):

climate.01_123456_02

If you need to, you can change the entity_id of your devices via the Lovelace UI (easy).

Or you can edit the entity registry direct to cope with this change - the file is called core.entity_registry, and contains entries like:

            {
                "entity_id": "climate.bedroom",
                "config_entry_id": null,
                "device_id": null,
                "area_id": null,
                "unique_id": "01:145038_04",
                "platform": "evohome_cc",
                "name": null,
                "icon": null,
                "disabled_by": null,
                "capabilities": {
                    "hvac_modes": ["heat", "off"],
                    "min_temp": 5.0,
                    "max_temp": 35.0
                },
                "supported_features": 1,
                "device_class": null,
                "unit_of_measurement": null,
                "original_name": "Bedroom",
                "original_icon": null
            },

When the time comes, I believe all you have to do is change the entity_id here - and also in any other places it is referenced (Lovelace, automation, etc.).

So I was able to flash the NanoCUL with latest evofw3 firmware.
I ran evohome_rf in monitor mode to capture some data.
13:164061 is the BDR91A ID right ?

I’ve added this basic configuration to home-assistant:

evohome_cc:
  scan_interval: 60
  serial_port: /dev/ttyUSB0
  packet_log: packet.log
  schema:
    controller: 13:164061

I got this following error:

2020-11-01 18:19:08 WARNING (MainThread) [custom_components.evohome_cc] evohome_cc v0.4.3, using evohome_rf v0.4.3 - versions match (this is good)
2020-11-01 18:19:08 DEBUG (MainThread) [custom_components.evohome_cc] Store = {}, Config =  OrderedDict([('scan_interval', datetime.timedelta(seconds=60)), ('serial_port', '/dev/ttyUSB0'), ('packet_log', 'packet.log'), ('schema', OrderedDict([('controller', '13:164061')])), ('max_zones', 12)])
2020-11-01 18:19:08 WARNING (MainThread) [custom_components.evohome_cc.evohome_rf] Starting evohome_rf, **config = {'scan_interval': datetime.timedelta(seconds=60), 'packet_log': 'packet.log', 'schema': OrderedDict([('controller', '13:164061')]), 'max_zones': 12, 'blocklist': {}}
2020-11-01 18:19:08 ERROR (MainThread) [homeassistant.setup] Error during setup of component evohome_cc
  File "/config/custom_components/evohome_cc/__init__.py", line 118, in async_setup
    client = evohome_rf.Gateway(serial_port, loop=hass.loop, **kwargs)
  File "/config/custom_components/evohome_cc/evohome_rf/__init__.py", line 131, in __init__
  File "/config/custom_components/evohome_cc/evohome_rf/schema.py", line 235, in load_schema

Not sure I’m doing this right :slight_smile:

Correct.

You’ve failed to include the complete trace-dump, which isn’t optimal.

Your controller is 12:207170 - it is a CM927 or similar? Also, is it battery-powered, or mains powered? Let me know.

Try changing your configuration.yaml to:

evohome_cc:
  scan_interval: 60
  serial_port: /dev/ttyUSB0
  packet_log: packet.log

It will then pick up your controller, and the relay as orphans - you will get some sensors.

If that doesn’t work - try:

evohome_cc:
  scan_interval: 60
  serial_port: /dev/ttyUSB0
  packet_log: packet.log
  schema:
    controller: 01:123456

Literally 01:123456 - it will not find this controller, but at least it is a valid ID, so evohome_cc should start. Don’t use 12:207170 - this is not (yet) supported.

@zxdavb Some news about the HM80 integration, maybe you haven’t seen it :slight_smile:

The controller is indeed a CM927 which is battery powered.
I modified the configuration and removed the controller entry as you proposed.
What do you mean by the complete trace-dump ? Shall I keep it running for a longer period?
I’ll keep you posted. Thanks!!

Hi,

Packet.log updated

I don’t see much data in homeassistant.log

2020-11-02 12:21:19 WARNING (MainThread) [homeassistant.loader] You are using a custom integration for evohome_cc which has not been tested by Home Assistant. This component mig
ht cause stability problems, be sure to disable it if you experience issues with Home Assistant.
2020-11-02 12:21:20 WARNING (MainThread) [custom_components.evohome_cc] evohome_cc v0.4.3, using evohome_rf v0.4.3 - versions match (this is good)
2020-11-02 12:21:21 DEBUG (MainThread) [custom_components.evohome_cc] Store = {}, Config =  OrderedDict([('scan_interval', datetime.timedelta(seconds=60)), ('serial_port', '/dev
/ttyUSB0'), ('packet_log', '/config/packet.log'), ('max_zones', 12)])
2020-11-02 12:21:21 WARNING (MainThread) [custom_components.evohome_cc.evohome_rf] Starting evohome_rf, **config = {'scan_interval': datetime.timedelta(seconds=60), 'packet_log'
: '/config/packet.log', 'max_zones': 12, 'blocklist': {}}
2020-11-02 12:22:21 DEBUG (MainThread) [custom_components.evohome_cc] Schema = None
2020-11-02 12:23:21 DEBUG (MainThread) [custom_components.evohome_cc] Schema = None
2020-11-02 12:24:21 DEBUG (MainThread) [custom_components.evohome_cc] Schema = None

I see a new line for Schema = None every 60 seconds
I do not see any sensors for now in HA

Thx!

What is in the packet log?

The current code is geared up for evohome systems only… I will be pushing your change soon that will suit your system much better.

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.

Thx!

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

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

You will need to use the bleeding_edge branch of github.com/zxdavb/evohome_rf.

And you may want to test:

python client.py 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 client.py 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):

client.py: Starting evohome_rf...
23:47:46.149 Discovery scripts specified, so disabling probes
client.py: Finished evohome_rf, results:
01:145038 (CTL)
client.py: Finished evohome_rf.

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

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

Here’s the requested packet.log issued by the first command (commit e35e879d0d7485dbb2ab99e994c5eefa92353cf8): https://pastebin.com/4U3QkhQa
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: