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

What is more likely is that this is a corrupt packet.

This suggest a hardware problem, which would explain all his issues.

Thanks for responses. The only change was an update to latest version, all was previously working so seems a slightly strange coincidence that hardware would fail unless the new version is a little fussier.
Indeed 01:000730 did not appear in known devices - I have now added it to my config, as per my below, however the log error is identical.
I do have a Honeywell opentherm connector on my boiler not located near the nanocul which never previously connected, could it be this got connected?
I am happy to change the nanocul (which is quite old) to latest whichever one you recommend.
Appreciate any help or advice, thanks.

ramses_cc:
  serial_port: /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0
#  baudrate: 115200
  packet_log:
    file_name: packet.log
    rotate_backups: 7
  ramses_rf:
    enforce_known_list: true
  known_list:
    18:196881:  #gateway_interface
    #18:196881: {class: HGI}
    01:081083:  #main TCS
    01:000730:
    04:023774:  #Hall Actuator
    04:023780:  #Studies Sensor  class': 'radiator_valve
    04:027356:  #Studies Actuator and 80 above
    04:027648:  #Lounge class: radiator_valve and sensor
    04:027358:  #Lounge Sensor
    04:027360:  #Niamh SEnsor & Actuator  class': 'radiator_valve
    04:027646:  #Ellie SEnsor & Actuator class': 'radiator_valve
    04:027650:  #Hall Actuator
    04:027656:  #TV Lounge sensor and actator  class': 'radiator_valve 
    04:027714:  #Hall Actuator
    04:027716:  #Master Bed SEnsor & Actuator  class': 'radiator_valve
    04:027718:  #Craig SEnsor & Actuator class': 'radiator_valve
    04:027720:  #Hall Actuator
    04:027722:  #Hall Landing Sensor and actuator class': 'radiator_valve
    07:025191:  #Stored Hot Water Sensor
    13:001489:  #Kitchen Diner Actuator
    13:001522:  #Ensuite Actuator
    13:055679:  #Grnd Bed Actuator
    13:173107:  #Hot water Valve
    13:224329:  #games room Actuator
    34:027677:  #Grnd Bed Sensor  class': 'zone_valve
    34:063533:  #games Room sensor class': 'zone_valve'
    34:150571:  #EnSuite Sensor  class': 'zone_valve
    34:150655:  #Kitchen Diner SEnsor  class': 'zone_valve


#    seperate program    
#   logger:
#     logs:
#       custom_components.ramses_cc: info  # show ramses_cc/ramses_rf state
#       ramses_rf.dispatcher: info         # show packet payloads

Why have you added this to your known_list? Can you point to the corresponding physical device in your house?

I wasn’t clear: my suggestion was that is was a device id from a corrupted packet. The device doesn’t exist.

The ‘Opentherm connector’ has a device_id starting with 10:. If you look in your packet log, you should see lots of packets to/from this device.

I am afraid that all evidence I have is that you have a (virtual?) hardware problem.

Have you tried tuning it? What are your RSSI values?

Is there a method available now, or being worked on, that doesn’t require the stick to be plugged in to the actual HA machine? I don’t mean ser2net.

My physical box is about to die and I want to move HA back to my VM platform.

I am sure I saw mention of something either available or being worked on, but at over 4300 posts in this thread, finding it has been impossible!

MQTT is coming soon, see here.

I have one, and it works well. You can put them wherever it has USB power, and can reach Wi-Fi.

When he’s ready, he’ll sell them here.

RuntimeError: no running event loop means the task is being created in the wrong thread. Please make sure any calls to self._loop.create_task(coro) are running in the event loop thread as creating the task from the wrong thread is not thread-safe and may crash Home Assistant.

I’ll need to put some time aside to review all this, afterall it was working before upgrade and as has been suggested it may be a problem associated to being on a VM (Proxmox). I added the 01:000730 as suggested above by Kars and no I dont believe it is a physical device. I have no idea about tuning the RSSI values so will have to go back to the drawing board on all this. Thanks

Rocksolid here on proxmox, as a VM. How have you mapped the USB device? This works for me:

As an aside, the original nanocul (software UART, Atmega 328p) has proved problematic for me in the past - many corrupted packets. The sticks with a hardware UART (Atmega 32u4 - SSM D2 and Busware) are significantly more stable. A decent external antenna may also help with RSSI and overall stability - I have other 868 MHz devices in the home so this really helps.

Actually mine was different as below:


Have changed to same as yours now I get a different error as below:

Logger: homeassistant.config_entries
Source: config_entries.py:575
First occurred: 12:17:23 (1 occurrences)
Last logged: 12:17:23

Error setting up entry RAMSES RF for ramses_cc
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/config_entries.py", line 575, in async_setup
    result = await component.async_setup_entry(hass, self)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/ramses_cc/__init__.py", line 89, in async_setup_entry
    await broker.async_setup()
  File "/config/custom_components/ramses_cc/broker.py", line 146, in async_setup
    await self.client.start(cached_packets=cached_packets())
  File "/usr/local/lib/python3.12/site-packages/ramses_rf/gateway.py", line 183, in start
    load_schema(self, known_list=self._include, **self._schema)  # create faked too
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/ramses_rf/schemas.py", line 353, in load_schema
    load_tcs(gwy, ctl_id, schema)  # type: ignore[arg-type]
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/ramses_rf/schemas.py", line 394, in load_tcs
    ctl = _get_device(gwy, ctl_id)
          ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/ramses_rf/schemas.py", line 336, in _get_device
    check_filter_lists(dev_id)
  File "/usr/local/lib/python3.12/site-packages/ramses_rf/schemas.py", line 332, in check_filter_lists
    raise LookupError(
LookupError: Can't create 01:000730: it is in the schema, but not in the known_list (check the lists and the schema)

I also see there is now a configuration menu. Do I need any entry in the “advanced serial port” entry?
Is the Scema from this configuration menu taken
from the config file?
The entry 01:000730 Is clearly the problem I guesss, is there a way to remove this perhaps?

Ok great is there a link for a proven current device perhaps?
Really appreciate help.

Have you tried using the ‘clear cache’ configuration options & reloading? This may remove the corrupted device from your schema.

For me, in a proxmox VM, both of these work. The busware one is a bit more fiddly as it uses a DFU bootloader, but perfectly capably of running evofw3

https://shop.busware.de/product_info.php/products_id/29

1 Like

Thank you so much for your advice. Its now working. I think maybe clearing the cache did the job. Really appreciate that. I will also get a more reliable stick.
It seems the new version is much more refined. I still have a few errors likely down to my original configuration file. I will go over the Wiki and try to tidy up. Again many thanks.

1 Like

Funnily enough I had the exact same error (including the 01:000730 device). Clearing cache resolved the issue. Using a nanocul with evofw3.

It isn’t odd at all… the underlying protocol is very error-prone, with poor error detection, and no correction.

It takes a single bit flip to change from 18:000730 (a very common address) to 01:000730…

This is one of the reasons why creating /enforcing a known_list is strongly recommended.

I also got the recommended indalo-tech device. It took all of one minute to swop out old and replace new, no idea if its any better but all working fine.
I added a suggested device from my error log and it deleted all of my known devices from the Ramses known devices list in the app itself, all still works fine but I need to review how to add these known devices back in from the Wiki instructions.

In short…

  • use the config_flow version of RAMSES RF with an empty known_list, and without enforcing a known_list
  • it will auto-detect the gateway ID (18:xxxxxx) and you can look for that entity, it will be called HGI 18:xxxxxx Gateway status
  • have a look at the attributes of that entity, it will have the suggested (minimal) schema, and the working know_list

Then add the schema and known_list to the system configuration.

Many thanks for advice.
So My now looks like this:
Hope i’ve correctly understood.