Please could someone test release 0.50.0 (is currently a beta release) and report back if it appears to be OK:
Bugfixes in ramses_cc, but lots of changes, including bugfixes in ramses_rf.
Hi, I’ve upgraded this evening to Home Assistant Core 2024.12.0 and Ramses RF 0.50.0 and it appears to be ok.
That said, I still get the start up warning around my schema not being minimal, despite there being nothing in configuration.yaml for Ramses RF
Logger: custom_components.ramses_cc.broker
Source: custom_components/ramses_cc/broker.py:119
integration: RAMSES RF (documentation, issues)
First occurred: 21:00:53 (1 occurrences)
Last logged: 21:00:53The config schema is not minimal (consider minimising it)
I also have various other warnings:
> Logger: homeassistant.util.loop
> Source: util/loop.py:136
> First occurred: 21:00:53 (1 occurrences)
> Last logged: 21:00:53
>
> Detected blocking call to open with args ('/config/packet.log', 'a') inside the event loop by custom integration 'ramses_cc' at custom_components/ramses_cc/broker.py, line 146: await self.client.start(cached_packets=cached_packets()) (offender: /usr/local/lib/python3.13/logging/__init__.py, line 1247: return open_func(self.baseFilename, self.mode,), please create a bug report at https://github.com/zxdavb/ramses_cc/issues For developers, please see https://developers.home-assistant.io/docs/asyncio_blocking_operations/#open Traceback (most recent call last): File "<frozen runpy>", line 198, in _run_module_as_main File "<frozen runpy>", line 88, in _run_code File "/usr/src/homeassistant/homeassistant/__main__.py", line 227, in <module> sys.exit(main()) File "/usr/src/homeassistant/homeassistant/__main__.py", line 213, in main exit_code = runner.run(runtime_conf) File "/usr/src/homeassistant/homeassistant/runner.py", line 154, in run return loop.run_until_complete(setup_and_run_hass(runtime_config)) File "/usr/local/lib/python3.13/asyncio/base_events.py", line 708, in run_until_complete self.run_forever() File "/usr/local/lib/python3.13/asyncio/base_events.py", line 679, in run_forever self._run_once() File "/usr/local/lib/python3.13/asyncio/base_events.py", line 2027, in _run_once handle._run() File "/usr/local/lib/python3.13/asyncio/events.py", line 89, in _run self._context.run(self._callback, *self._args) File "/usr/src/homeassistant/homeassistant/setup.py", line 165, in async_setup_component result = await _async_setup_component(hass, domain, config) File "/usr/src/homeassistant/homeassistant/setup.py", line 461, in _async_setup_component await asyncio.gather( File "/usr/src/homeassistant/homeassistant/setup.py", line 463, in <genexpr> create_eager_task( File "/usr/src/homeassistant/homeassistant/util/async_.py", line 45, in create_eager_task return Task(coro, loop=loop, name=name, eager_start=True) File "/usr/src/homeassistant/homeassistant/config_entries.py", line 788, in async_setup_locked await self.async_setup(hass, integration=integration) File "/usr/src/homeassistant/homeassistant/config_entries.py", line 551, in async_setup await self.__async_setup_with_context(hass, integration) File "/usr/src/homeassistant/homeassistant/config_entries.py", line 640, in __async_setup_with_context result = await component.async_setup_entry(hass, self) File "/config/custom_components/ramses_cc/__init__.py", line 94, 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())
then
Logger: ramses_tx.message
Source: runner.py:154
First occurred: 21:00:55 (8 occurrences)
Last logged: 21:00:55
W --- 18:069148 02:022960 --:------ 2309 001 03 < Payload doesn't match '^0[0-9A-F]{5}$': 03
W --- 18:069148 02:022960 --:------ 2309 001 04 < Payload doesn't match '^0[0-9A-F]{5}$': 04
W --- 18:069148 02:022960 --:------ 2309 001 05 < Payload doesn't match '^0[0-9A-F]{5}$': 05
W --- 18:069148 02:022960 --:------ 2309 001 06 < Payload doesn't match '^0[0-9A-F]{5}$': 06
W --- 18:069148 02:022960 --:------ 2309 001 07 < Payload doesn't match '^0[0-9A-F]{5}$': 07
then
Logger: ramses_rf.dispatcher
Source: runner.py:154
First occurred: 21:00:55 (8 occurrences)
Last logged: 21:00:57
I --- 02:022960 18:069148 --:------ 2309 003 030C80 < PacketInvalid( I --- 02:022960 18:069148 --:------ 2309 003 030C80 < Unexpected verb/code for src (UFC) to Tx)
I --- 02:022960 18:069148 --:------ 2309 003 040C80 < PacketInvalid( I --- 02:022960 18:069148 --:------ 2309 003 040C80 < Unexpected verb/code for src (UFC) to Tx)
I --- 02:022960 18:069148 --:------ 2309 003 050C80 < PacketInvalid( I --- 02:022960 18:069148 --:------ 2309 003 050C80 < Unexpected verb/code for src (UFC) to Tx)
I --- 02:022960 18:069148 --:------ 2309 003 060C80 < PacketInvalid( I --- 02:022960 18:069148 --:------ 2309 003 060C80 < Unexpected verb/code for src (UFC) to Tx)
I --- 02:022960 18:069148 --:------ 2309 003 070C80 < PacketInvalid( I --- 02:022960 18:069148 --:------ 2309 003 070C80 < Unexpected verb/code for src (UFC) to Tx)
then
Logger: homeassistant.helpers.frame
Source: helpers/frame.py:324
First occurred: 21:00:57 (2 occurrences)
Last logged: 21:00:57
Detected that custom integration 'ramses_cc' registers an entity service with a non entity service schema at custom_components/ramses_cc/climate.py, line 113: platform.async_register_entity_service(k, v, f"async_{k}"). This will stop working in Home Assistant 2025.9, please create a bug report at https://github.com/zxdavb/ramses_cc/issues
Detected that custom integration 'ramses_cc' registers an entity service with a non entity service schema at custom_components/ramses_cc/water_heater.py, line 59: platform.async_register_entity_service(k, v, f"async_{k}"). This will stop working in Home Assistant 2025.9, please create a bug report at https://github.com/zxdavb/ramses_cc/issues
and finally
Logger: homeassistant
Source: /usr/src/homeassistant/homeassistant/runner.py:112
First occurred: 21:00:54 (3 occurrences)
Last logged: 21:17:48
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:022960 (UFC): 1.0
I think most of these were there before but not sure if some were expected to be addressed in this release
Might be worth noting here that ramses_cc 0.42.0 fails to start up after upgrading to HA 2024.12.0, this has already been reported - HA 2024.12.0 fails initialisation of ramses_cc · Issue #216 · zxdavb/ramses_cc · GitHub and as noted on the discussion there, the problem can be resolved by updating to ramses_cc 0.50.0
1 Like
I am marking 0.50.0 as a general release: please upgrade
1 Like
Support for UFH controllers is patchy.
If it is a show-stopper, consider taking this device id out of your block list.
Please add the above as an issue to github.com/ramses_cc/issues
Please add the above as an issue to github.com/ramses_cc/issues
what is this device? a dongle, an RFG100, or something else?
version 0.50.0 does not use configuration.yaml, except for import - look at your config entry.
No TRVs, lockshields only (one key difference is that with heat pumps, the delta T is usually 2-3 'C, not 20 ’ C).
1 Like
Created issues 217 and 218 thank you. Please let me know if further details are required.
I thought this is my HGI
18:069148: { class: HGI, alias: “evofw3” }
Is it actually my USB dongle and marked incorrectly?
I’ve included the configuration in the tickets I raised
evofw3 atmega32u4 - /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00, s/n: n/a - SparkFun - 1B4F:9206
gateway configuration
disable_discovery: false
disable_qos: false
disable_sending: false
enable_eavesdrop: false
System schema:
“01:108199”: {}
Known devices:
“01:108199”: {}
“02:022960”: {}
“04:024890”: {}
“04:049506”: {}
“04:112432”: {}
“04:123648”: {}
“04:123650”: {}
“04:123652”: {}
“04:123654”: {}
“04:125369”: {}
“04:246790”: {}
“07:030355”: {}
“13:142019”: {}
“13:181949”: {}
“18:069148”:
alias: evofw3
class: HGI
“34:007977”: {}
“34:009973”: {}
I would love to do work on that… As I have one, and would really like to monitor it more. (and add other bits and peaces with respect to my ventilation unit)
The thing is that the code base is rather large and unsure how to proceed…
Interesting. So youre heating all rooms to the same temperature with little differences here and there?
As far as I understand, its atleast better to still use HR92 (with BDR91T) and have some kind of regulations with remote thermostats (faked or T87RF)?
How were your LSVs set when you were still using evohome?
Atm, Im thoroughly looking at the graphs to “unlock how the algorithm works” and how the LSVs should be set. I cant find anywhere how the radiators should be balanced so I believe they shouldnt be at all, because HR92 should be doing the balancing needed.
Exactly atm, Im lowering LSV daily each time the same amount of one huge radiator, that is mostly responsible of heating 1/4 of the house, because others are set so low (I could “balance” this regulation by upping the setpoints on those, but atm I refuse) so clearly it kinda shows it is struggling but not over struggling or critical. Because it is always a little overshooting and undershooting, I strongly believe that sooner or later changing of LSV will show some difference on some graph at some point.
IOW, Im trying “to tame beast” by “proving” if LSV has any effect at all.
EDIT:
On a side note: on this huge radiator I also have strategically placed for accuracy of reading 8x DS18B20 on flow and 8x DS18B20 on return and in HA I made “maximums” for each of flow and return, and then on top of these max also delta T. I cant for the life of me figure out how one should look at delta T reading, because on a cold radiator, flow always shoots up, so the delta T can be as high as 25C. Then after few minutes, when flow starts to go down, the return is already climbing and it takes again the same amount of minutes when both are in 2-3-4C delta T range. After that it just wobles up or down a little.
So at what point should one take the delta T reading seriously: when the flow reaches its peak for the first time or at any point after that when everything is “stabilized”?
EDIT2:
Its interesting to see a genius like you ditch evohome so Im curious if “ease of use” of LSVs was the main culprit that weighted the scale against imperfections and troubles of using evohome.
@zxdavb Does 0.50.0 include a fix for ramses_cc.get_zone_schedule service failing (#183) ?
Currently on 0.42.0 and it fails (timeouts) with that version
No - I get the same error unfortunately
Logger: homeassistant.components.websocket_api.http.connection
Source: custom_components/ramses_cc/climate.py:468
integration: Home Assistant WebSocket API (documentation, issues)
First occurred: 16:19:04 (1 occurrences)
Last logged: 16:19:04
[546805544800] Error handling message: Unknown error (unknown_error) Donald from 192.168.1.72 (Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.1.1 Safari/605.1.15)
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/websocket_api/decorators.py", line 28, in _handle_async_response
await func(hass, connection, msg)
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 816, in handle_execute_script
script_result = await script_obj.async_run(
^^^^^^^^^^^^^^^^^^^^^^^^^^^
msg.get("variables"), context=context
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
)
^
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 1801, in async_run
return await asyncio.shield(create_eager_task(run.async_run()))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 464, in async_run
await self._async_step(log_exceptions=False)
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 528, in _async_step
self._handle_exception(
~~~~~~~~~~~~~~~~~~~~~~^
ex, continue_on_error, self._log_exceptions or log_exceptions
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
)
^
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 558, in _handle_exception
raise exception
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 526, in _async_step
await getattr(self, handler)()
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 764, in _async_call_service_step
response_data = await self._async_run_long_action(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...<9 lines>...
)
^
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 727, in _async_run_long_action
return await long_task
^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/core.py", line 2802, in async_call
response_data = await coro
^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/core.py", line 2845, in _execute_service
return await target(service_call)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 1007, in entity_service_call
single_response = await _handle_entity_call(
^^^^^^^^^^^^^^^^^^^^^^^^^^
hass, entity, func, data, call.context
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
)
^
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 1079, in _handle_entity_call
result = await task
^^^^^^^^^^
File "/config/custom_components/ramses_cc/climate.py", line 468, in async_get_zone_schedule
await self._device.get_schedule()
File "/usr/local/lib/python3.13/site-packages/ramses_rf/system/zones.py", line 167, in get_schedule
await self._schedule.get_schedule(force_io=force_io)
File "/usr/local/lib/python3.13/site-packages/ramses_rf/system/schedule.py", line 254, in get_schedule
await asyncio.wait_for(
self._get_schedule(force_io=force_io), timeout=timeout
)
File "/usr/local/lib/python3.13/asyncio/tasks.py", line 507, in wait_for
return await fut
^^^^^^^^^
File "/usr/local/lib/python3.13/site-packages/ramses_rf/system/schedule.py", line 296, in _get_schedule
fragment = await get_fragment(frag_num)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.13/site-packages/ramses_rf/system/schedule.py", line 274, in get_fragment
pkt: Packet = await self._gwy.async_send_cmd(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
cmd, wait_for_reply=True, priority=Priority.HIGH
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
)
^
File "/usr/local/lib/python3.13/site-packages/ramses_rf/gateway.py", line 626, in async_send_cmd
return await super().async_send_cmd(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...<7 lines>...
) # may: raise ProtocolError/ProtocolSendFailed
^
File "/usr/local/lib/python3.13/site-packages/ramses_tx/gateway.py", line 326, in async_send_cmd
return await self._protocol.send_cmd(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...<5 lines>...
) # may: raise ProtocolError/ProtocolSendFailed
^
File "/usr/local/lib/python3.13/site-packages/ramses_tx/protocol.py", line 711, in send_cmd
pkt = await super().send_cmd( # may: raise ProtocolError/ProtocolSendFailed
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...<5 lines>...
)
^
File "/usr/local/lib/python3.13/site-packages/ramses_tx/protocol.py", line 481, in send_cmd
return await super().send_cmd(cmd, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.13/site-packages/ramses_tx/protocol.py", line 225, in send_cmd
return await self._send_cmd(
^^^^^^^^^^^^^^^^^^^^^
...<5 lines>...
)
^
File "/usr/local/lib/python3.13/site-packages/ramses_tx/protocol.py", line 660, in _send_cmd
return await self._context.send_cmd(send_cmd, cmd, priority, qos)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.13/site-packages/ramses_tx/protocol_fsm.py", line 333, in send_cmd
await asyncio.wait_for(fut, timeout=timeout)
File "/usr/local/lib/python3.13/asyncio/tasks.py", line 507, in wait_for
return await fut
^^^^^^^^^
ramses_tx.exceptions.ProtocolSendFailed: <ProtocolContext state=WantRply echo=0404|RQ|01:108199|0501, tx_count=4/4>: Exceeded maximum retries
This post may be helpful for some who are struggling to create custom commands for remotes:
No, no fix: I had a quick look, and I have no idea why/how it broke.
Are you using MQTT?