0.50.1 working fine here too - needed to install it to get things working again after one of the 2025.3 HA core releases (forget which), after previously doing the manual file install for the DHW issue.
While I’m here (and only having belatedly caught up) - thank you so very, very much for all your work on ramses_xx. And the hardware. Although I’ve only done 10% of what I planned to (don’t we all…) it’s really, really helped me to the point of “what would I do without it? Probably bin the Evohome and do something else”.
Just hoping someone else with the time, skill and a whole lab house to test it on can step up (I suppose the last hope is a bit of a stretch. A prod environment with very understaning users, then). The 40-years-younger me might have fitted the bill…
Looking for some troubleshooting support:
Had all of this working about a 1.5 years ago with an SSM-D2 , had some issues and stopped using this integration. It turned out that my SSM-D2 has some HW issues so I ordered a new RAMSES_ESP.
Plugged it in my HASS setup and after changing USB it immediately started working, even with the old settings. Unfortunately not all devices returned (EvoHome setup) so I started to play around with the settings, new antenna etc.
You guessed it; Can’t get anything to work anymore.
I know only get below in my log file (no new entries):
2025-03-09T15:34:52.161918 000 I --- 18:178128 63:262142 --:------ 7FFF 015 001001957B5486F376302E35302E30
2025-03-09T15:34:52.167577 ... I --- 18:178128 63:262142 --:------ 7FFF 015 001001957B0C8F6C76302E35302E30 # 7FFF| I|18:178128
2025-03-09T15:34:52.280391 000 I --- 18:178128 63:262142 --:------ 7FFF 015 001001957B5486F376302E35302E30
And I only get 1 device:
while before I would get a relative normal log like below:
2025-03-08T12:18:25.063483 000 I --- 18:178128 63:262142 --:------ 7FFF 015 00100195757A4F4F76302E35302E30
2025-03-08T12:18:25.133665 ... RP --- 01:202227 18:178128 --:------ 000C 006 000800108936 # 000C|RP|01:202227|0008 (0008)
2025-03-08T12:18:25.135662 ... RP --- 01:202227 18:178128 --:------ 000C 012 01080010AF5101080010AF4D # 000C|RP|01:202227|0108 (0108)
2025-03-08T12:18:25.136867 ... RP --- 01:202227 18:178128 --:------ 000C 006 02080010AF4B # 000C|RP|01:202227|0208 (0208)
2025-03-08T12:18:25.140855 ... RP --- 01:202227 18:178128 --:------ 000C 006 030800109679 # 000C|RP|01:202227|0308 (0308)
2025-03-08T12:18:25.142252 ... RP --- 01:202227 18:178128 --:------ 000C 006 04080010967B # 000C|RP|01:202227|0408 (0408)
2025-03-08T12:18:25.150388 ... RP --- 01:202227 18:178128 --:------ 000C 006 050800109677 # 000C|RP|01:202227|0508 (0508)
2025-03-08T12:18:25.151716 ... RP --- 01:202227 18:178128 --:------ 000C 006 070800108932 # 000C|RP|01:202227|0708 (0708)
2025-03-08T12:18:25.153375 ... RP --- 01:202227 18:178128 --:------ 000C 006 080800108938 # 000C|RP|01:202227|0808 (0808)
Looking at the documentation I see quite a lot has changed and there is a now a config flow.
I have:
- Removed the integration fully and re-installed it (Using 0.50.1 pre release)
- Tried different antennas (although I had it working with the stock one but was missing one node)
- Deleted ramses.cc manually , rebooted (just hass but also whole system)
Few questions:
- is there still a need to have ANYTHING in the configuration.yaml eg USB setup or is ALL done via the integrations configuration flow?
- My Evohome identified as “01:202227” in the past. I can’t see any references to that anymore in the log (the log only has the 3 entries above). Does this change when you start over or is this the same also after a new start?
- What is the best order of troubleshooting this and how do I know/can I check it’s not the hardware?
- Why is it not receiving more data like it was? My Evohome itself is fully functional
BTW, one trick is to remove the config entry (via the UI) & restart HA - then it has to re-import from configuration.yaml to create another entry…
If needed, simply make any changes to configuration.yaml, delete the imported config entry & reboot again.
Thank you, it worked!
Congrats to everyone supporting this project!
Could someone post a screenshot from the “System schema and known devices” in a Evohome setup?
I’ve got just the controller identified, which is I think the advice in the documentation;
"01:076914": {}
Nothing more required, unless your system is more complicated.
It’s listening to 65 devices from several controllers all around my house so want to limit all the chatter better. The documentation on how to do that in the new config flow are not that complete I feel
Like I said, the documentation states:
As a minimum, for CH/DHW systems, you should list the controller like so:
ramses_cc:
01:145038: {}
ramses_rf is very good at discovering Heat schemas, and it is acceptable to allow it to construct the remainder via discovery.
So unless you have multiple controllers, this should be all you require.
Hi again,
For an Evohome heating system, I currently use the following known device list:
"01:043387": {}
"02:033552": {}
"02:033535": {}
"02:033545": {}
"13:118891": {}
"18:100040":
class: HGI
"34:029902": {}
"34:029904": {}
"34:029906": {}
"34:029908": {}
"34:029910": {}
"34:029912": {}
"34:029914": {}
"34:029916": {}
"34:029918": {}
"34:029920": {}
"34:030020": {}
For the 3 02:xxxxxx devices shown as UFC, I get the following error:
Invalid device type to be a controller: 02:033545 (UFC): 0.24
I tried removing them from the known list, but that causes Head demand info to become unavailable on the 34:xxxxxx UFH devices.
The system is composed of 3 HCC80 controlled via round thermostats talking to a BDR91 relay.
Any idea how to fix these errors?
Thanks!
okay , it is good but where can we see that auto discovered schema? also I do not see a checkmark where I allow or disallow it to build the schema in the haos integration.
When you open the integration’s Gateway Status binary sensor, under Attributes, is anything visible? Schema is not built for HVAC-only systems, so I only see Schema: {}. Known list is there too.
Because I discovered that there was a Evohome HR92 for some reason connected to the wrong zone. I triend through Evohome everything to remove the HR92 from the zone but was not succefull. Therefore I deleted the zone en Evohome and added the correct HR92 to the zone.
But now in Home Assistant there is still a ramses RF zone with that name and also with the incorrect HR92 added.
How do I fix this? It seems there is no remove or delete option and restarting the integration, restarting HA and refreshing the cache does not solve it.
Hi all,
I had to replace an evohome radiator controller hr92 and the new trv has been discovered by Ramses but it’s not linked to the zone correctly. I tried clearing the cache but get unknown error. The corresponding log entry seems to be…
"Logger: aiohttp.server
Source: /usr/local/lib/python3.13/site-packages/aiohttp/web_protocol.py:481
First occurred: 22:18:50 (2 occurrences)
Last logged: 22:41:23
Error handling request from 127.0.0.1
Traceback (most recent call last):
File "/usr/local/lib/python3.13/site-packages/aiohttp/web_protocol.py", line 510, in _handle_request
resp = await request_handler(request)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.13/site-packages/aiohttp/web_app.py", line 569, in _handle
return await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.13/site-packages/aiohttp/web_middlewares.py", line 117, in impl
return await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/http/security_filter.py", line 92, in security_filter_middleware
return await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/http/forwarded.py", line 77, in forwarded_middleware
return await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/http/request_context.py", line 26, in request_context_middleware
return await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/http/ban.py", line 86, in ban_middleware
return await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/http/auth.py", line 242, in auth_middleware
return await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/http/headers.py", line 41, in headers_middleware
response = await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/http.py", line 73, in handle
result = await handler(request, **request.match_info)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/http/decorators.py", line 83, in with_admin
return await func(self, request, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/config/config_entries.py", line 284, in post
return await super().post(request, flow_id)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/http/data_validator.py", line 74, in wrapper
return await method(view, request, data, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/data_entry_flow.py", line 121, in post
result = await self._flow_mgr.async_configure(flow_id, data)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 336, in async_configure
result = await self._async_configure(flow_id, user_input)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 383, in _async_configure
result = await self._async_handle_step(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
flow, cur_step["step_id"], user_input
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
)
^
File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 487, in _async_handle_step
result: _FlowResultT = await getattr(flow, method)(user_input)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/ramses_cc/config_flow.py", line 543, in async_step_clear_cache
store: Store = self.hass.helpers.storage.Store(STORAGE_VERSION, STORAGE_KEY)
^^^^^^^^^^^^^^^^^
AttributeError: 'HomeAssistant' object has no attribute 'helpers'
To add to the above, I’m also unable to enforce the known list, the integration won’t start if I set this to true. I’ve also tried deleting the UI version of ramses_cc and setting it up from configuration.yaml and run into the same issues.
It’s like something’s managed to get itself stuck, is there anything else I should try?
Cheers
Spence
Hi Spence, the ‘clear cache’ problem will be fixed in the next ramses_cc release.
Egbert
Great, I managed to mash it around using the configuration.yaml and I’ve got rid of everything except the device. I could probably attempt to delete from the HA database but I think I’ll leave it alone for now. There’s obviously something else going on here.
A new ramses_cc/ramses_rf release 0.51.0 is out.
The update will show up in Home Assistant HACS if you already have the Ramses RF custom integration installed.
More sensors will show up in HA, and the configuration flow brought up to date.
Thanks for all user supplied logs and error reports. And a big thanks to David for all his time and effort spent on this over the years.
Hi Egbert
Thanks for taking this on and also thanks to David for all his prior work.
I’ve just tried 0.51.0 on my Evohome system and calls to set_dhw_mode and set_zone_mode are failing with ramses_tx.exceptions.CommandInvalid: Invalid args: For mode=02, until and duration must both be None
So, for example:
action: ramses_cc.set_zone_mode
data:
mode: permanent_override
setpoint: 5
target:
entity_id: climate.01_216136_05
fails with:
ramses_tx.exceptions.CommandInvalid: Invalid args: For mode=02, until and duration must both be None
I’ve reverted to 0.50.1 for now as my scripts use those calls extensively.
I’ll raise an issue with the full error log output.
Hi, first, thank you Egbert for picking up the integration, I was afraid that it would die a sad and silent death.
Previously my fan (CVE) would only report speeds in 3 types, speed 1,low, speed 2, auto and speed 3, high. I use those reported modes on a few automations, but since this new version it reports all kinds of values for fan_info
Is there any translation for this “new” 2 digit codes? Because as it stands, my automations fail and panic. I use the fan_info to check if the fan received the command to speed up or slow down.