I have recently been round the houses with Resideo support for an issue with my HCE80 UFH controller. The controller stops working and starts flashing orange. Resideo blamed my use of OpenTherm alongside the Evohome controller. This seemed unlikely given it has worked fine for several years.
As the problem became more frequent (I can “fix” it by power cycling the UFH controller), I decided to power off the Pi I use with this integration. And the problem stopped happening. And has now stopped for several weeks where it was happening multiple times per day.
I think the higher incidence coincided with a version update of this integration.
I did try to set an old option:
disable_sending: true
but I suspect this is no longer actually valid.
I would like to try the integration again but in completely passive mode i.e. only listening not sending anything. Is this possible?
(My previous discussion on this same topic with the previous developer is in this thread.)
I am fairly convinced that this integration interacts with my HCE80 in such a way as to make it very unhappy. The pattern is too consistent to believe otherwise.
I would really like to pull the OpenTherm information into HA. If there are any suggestions on any alternative approaches for doing this, they would be very gratefully received.
I use a dedicated Pi system for the RAMSES integration. It is running the following (although I now have it turned off):
Installation method Home Assistant OS
Core 2025.8.3
Supervisor 2025.11.1
Operating System 16.1
Frontend 20250811.1
RAMSES RF Version 0.51.5
The issue with interfering with the UFH controller goes back several years.
My preference would be to just have the integration passively listen as I have no interest in controlling anything.
There are recurring entries in the log like this:
2025-09-12 04:23:58.898 ERROR (MainThread) [homeassistant] Error doing job: Exception in callback UfhController._handle_msg() (None)
Traceback (most recent call last):
File “/usr/local/lib/python3.13/asyncio/events.py”, line 89, in _run
self._context.run(self._callback, *self._args)
~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/local/lib/python3.13/site-packages/ramses_rf/device/heat.py”, line 430, in _handle_msg
super()._handle_msg(msg)
~~~~~~~~~~~~~~~~~~~^^^^^
File “/usr/local/lib/python3.13/site-packages/ramses_rf/device/base.py”, line 449, in _handle_msg
self._make_tcs_controller(msg=msg)
~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^
File “/usr/local/lib/python3.13/site-packages/ramses_rf/device/base.py”, line 459, in _make_tcs_controller
raise TypeError(f"Invalid device type to be a controller: {self}")
TypeError: Invalid device type to be a controller: 02:020364 (UFC): 0.0
02:020364 is the HCE80 UFH controller whilst the Evohome controller is 01:164379
I’ve been looking at the problems caused by the RAMSES-III devices.
In terms of the messages in the radio environment there are a couple of issues fro the existing ramses-esp (and evofw3) code.
There are messages with significantly longer payload than seen before exceeding the buffer lengths in both FW versions. I have a fix in ramses-esp for this but the memory restrictions in the Arduino devices will probably make this too difficult for evofw3.
Having captured the longer radio frame the overall message format looks the same i.e.
<type><addresses><opcode><len><payload><checksum>
The problem is that the current checksum calculation (addition module 256) always fails for RF-3 messages. I’ve investigated the possibility that they’ve switched to a CRC for these messages but can’t find a match.
There’s a distinct possibility that at least part of the payload in RF-3 messages are encrypted. The bind sequence between RF-3 aware devices uses a new message (1FC8 instead of 1FC9) that appears to include a 64 byte value. This message uses the original checksum.
So, if I can solve the checksum problem then ramses-esp can capture the messages for ramses_rf/cc
Is there anybody who has crypto and or error checking experience who can help?
I have been following along with this as I am researching how to add my Honeywell Hometronic system in to Home Assistant.
Reading through the Evohome R3 install manual, page 9 of the manual has a space to write down the MAC address and CRC of the Evohome R3 Controller, the CRC appears to be four characters in length, so it is likely to be 16bits.
Hope this is of assistance.
That crc is what I suspected also and resideo assistance asks you every time for the MAC ID and CRC of the system when they need to identify your system
Update ramses_cc to 0.52.3. The error you show was fixed in between these releases. Leave the SQL option Off.
You can copy sensors (read only) from the integration/All items to youw own Dashboard in HA, and forget about all the other items.
I saw on internet that there are ways to make your own dongle and that you could buy form a party in England (https://indalo-tech.onlineweb.shop/).
BUT: are there any other dongles that you all advice?
Ola, you do not need to set anything at schema, the integration is pretty good at detecting it. Just enumerate all your devices at known devices as you did and set that acept packets only from known devices to on. If you want to see the detected schema look at the hgi device properties. It should show all the schema in there, with each device asigned to a zone.
I just saw the errors you posted. What trv you have, what bdr and what controller? How old is your system?
The one from indalo-tech is the most reliable and most powerfull so far. It is based on esp and it can function plugged in any part of your house where you have a usb (just for power) because it uses mqtt, so it’s not dependant on tge HA usb.
Looks like that 18:000… is a error that came from noise in the rf. If I was you I would retain the real device list in a file (the ones you have now in the allow list), I would completly delete the ramses device and uninstall the integration from HA and from HACS, delete from haos /homeassistant/.storage/ramses* file using the advanced ssh and terminal console or any ssh client that has access to the filesystem (this is the most reliable way I found to get rid of phantom devices), restart HA. After all this mambo jumbo reinstall the ramses from HACS latest version, start normal configuration of the integration and at this point, during the config steps, fill in the allow list and mark the only accept packets from known devices. This should get rid of all phantoms and have a consistent clean config. But again, this is what I found that worked best for me.
On my system that file is:
➜ .storage ls -la | grep rams
-rw-r--r-- 1 root root 4041 Nov 8 23:41 ramses_cc
➜ .storage pwd
/homeassistant/.storage
This is basically the cache file of the ramses_cc and if you do not get rid of that you will still end up with bogus devices .
uuhhm, never used SSH at all
I have installed Home Assistant OS ( Hassio in the recent past)
I fully understand your point and agree to delete cache Ramses
I need to understand better how I can perform this tasks as my first time, GRRRRRRR
Hi,
I have a lot of “virtual assistant”
I take my time, I do like understand what i’m doing
by the way:
perform it ( i discovered a couple of new things for the future ok)
Installation clean done
but ouch again, there is a row regarding USB uuhhhmmm:
the new one show up ( disappear after untick Enable newly added entities):
Logger: homeassistant.helpers.frame
Source: helpers/frame.py:350
First occurred: 2:33:16 PM (1 occurrence)
Last logged: 2:33:16 PM
Detected that custom integration 'ramses_cc' calls `device_registry.async_get_or_create` referencing a non existing `via_device` ('ramses_cc', '01:226881_00'), with device info: {'identifiers': {('ramses_cc', '04:150349')}, 'manufacturer': None, 'model': <DevType.TRV: 'TRV'>, 'name': 'TRV 04:150349', 'serial_number': '04:150349', 'via_device': ('ramses_cc', '01:226881_00')} at custom_components/ramses_cc/broker.py, line 633: device_registry.async_get_or_create(. This will stop working in Home Assistant 2025.12.0, please create a bug report at https://github.com/ramses-rf/ramses_cc/issues
try to investigate, in DevTools check the HGI status,
device class = problem :
, I think so but …
: