Hi HA-Enthousiast and Hsluis.
Good to hear that this approach works. I haven’t gotten around to testing it. However, I will have to set up an sntp server internally first. I have my gadgets on an internal IOT wifi ssid, that don’t get internet access. So an external sntp server is no option.
@David, Isn’t there an other way to get the time for Ramses_ESP?
I changed the wiki page to make the instructions work on both the HGI80 as well as the diy devices. Note the HGI80 will never accept a command if you specify a device ID. You need to send the 730 device id and let HGI80 replace it with its own device id.
The WiFi controller has no need to respond to 0404 commands because it has no way of being bound to an internet gateway that used to use that message to get and put schedules for the older non WiFi controllers. Infact, I was the one that deciphered the original 0404 message and discovered that the WiFi controller initially still responded to it. My guess is that Resideo are probably running out of memory space on the device and so removing redundant functionality from it. They have done this with many messages over the last few firmware updates
Have you tried a Capital C in your device ID string. Your hand crafted string has a lower case c in the first instance.
I note that almost no-one here is sending bytes directly to the USB device, they are asking ramses_rf to do it for them (via ramses_cc/HA).
NOTE: Although that is true of the USB dongle (i.e. its firmware), it is not the case for ramses_rf.
During startup, the code will make effort to determine the device ID of the dongle. So, if you subsequently ask for this command to be Tx:
I --- 18:136212 --:------ 18:136212 1FC9 012 0B00084A14140B1FC94A1414
… ramses_rf will translate it to:
I --- 18:000730 --:------ 18:136212 1FC9 012 0B00084A14140B1FC94A1414
before sending it to the USB device.
It is not preferred, but should be OK if you send the latter command, and - IIRC - also:
I --- 18:000730 --:------ 18:000730 1FC9 012 0B00084A14140B1FC94A1414
Finally, do not use 18:730 instead of 18:000730 - this is not supported.
See: Serial Interface · IndaloTech/ramses_esp Wiki · GitHub
In my mind, the ramses_esp device should ship with a default SNTP config - I did ask Pete about this - IIRC, he had made a conscious decision to not have it so.
I presume this remains the case for the latest firmware version?
If so, the solution would be for ramses_rf (or, probably better, ramses_cc) to (send the commands to the dongle to) configure a SNTP server, should it notice that one is not not configured.
Some new errors have appeared since the upgrade to the latest HA core 2025.1
Logger: homeassistant.config_entries
Source: config_entries.py:640
First occurred: 10:27:41 (1 occurrences)
Last logged: 10:27:41
Error setting up entry RAMSES RF for ramses_cc
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/loader.py", line 1272, in _load_platform
cache[full_name] = self._import_platform(platform_name)
~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/loader.py", line 1304, in _import_platform
return importlib.import_module(f"{self.pkg_path}.{platform_name}")
~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/util/loop.py", line 200, in protected_loop_func
return func(*args, **kwargs)
File "/usr/local/lib/python3.13/importlib/__init__.py", line 88, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "<frozen importlib._bootstrap>", line 1387, in _gcd_import
File "<frozen importlib._bootstrap>", line 1360, in _find_and_load
File "<frozen importlib._bootstrap>", line 1331, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 935, in _load_unlocked
File "<frozen importlib._bootstrap_external>", line 1026, in exec_module
File "<frozen importlib._bootstrap>", line 488, in _call_with_frames_removed
File "/config/custom_components/ramses_cc/water_heater.py", line 229, in <module>
class RamsesWaterHeaterEntityDescription(
...<6 lines>...
ramses_rf_class: type[DhwZone]
TypeError: metaclass conflict: the metaclass of a derived class must be a (non-strict) subclass of the metaclasses of all its bases
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
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 107, in async_setup_entry
await broker.async_start()
File "/config/custom_components/ramses_cc/broker.py", line 152, in async_start
await self.async_update()
File "/config/custom_components/ramses_cc/broker.py", line 326, in async_update
await async_add_entities(Platform.WATER_HEATER, new_dhws)
File "/config/custom_components/ramses_cc/broker.py", line 283, in async_add_entities
await self._async_setup_platform(platform)
File "/config/custom_components/ramses_cc/broker.py", line 222, in _async_setup_platform
await self._platform_setup_tasks[platform]
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 2278, in async_forward_entry_setups
await integration.async_get_platforms(platforms)
File "/usr/src/homeassistant/homeassistant/loader.py", line 1185, in async_get_platforms
import_future.result()
~~~~~~~~~~~~~~~~~~~~^^
File "/usr/src/homeassistant/homeassistant/loader.py", line 1173, in async_get_platforms
platforms.update(self._load_platforms(platform_names))
~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/loader.py", line 1098, in _load_platforms
platform_name: self._load_platform(platform_name)
~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/loader.py", line 1292, in _load_platform
raise ImportError(
f"Exception importing {self.pkg_path}.{platform_name}"
) from err
ImportError: Exception importing custom_components.ramses_cc.water_heater
Same here, after the upgrade my Hotwater entity has disapeared and also service calls such as ramses_cc.set_dhw_mode
Could someone try the latest master and report back?
I manually copied water_heater.py from gitlab to my instance of home assistant, restarted and all appears good now thank you.
Yup, I did the same and all good. There are some other warnings that I have not seen before.
Logger: homeassistant.helpers.frame
Source: helpers/frame.py:324
First occurred: 15:11:46 (3 occurrences)
Last logged: 15:11:47
Detected that custom integration 'ramses_cc' calls `device_registry.async_get_or_create` referencing a non existing `via_device` ('ramses_cc', '01:078710_HW'), with device info: {'identifiers': {('ramses_cc', '07:017494')}, 'manufacturer': None, 'model': <DevType.DHW: 'DHW'>, 'name': 'DHW 07:017494', 'serial_number': '07:017494', 'via_device': ('ramses_cc', '01:078710_HW')} at custom_components/ramses_cc/broker.py, line 269: 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/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/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
Logger: homeassistant.util.loop
Source: util/loop.py:136
First occurred: 15:11:46 (1 occurrences)
Last logged: 15:11:46
Detected blocking call to open with args ('/config/evohome/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 707, in run_until_complete self.run_forever() File "/usr/local/lib/python3.13/asyncio/base_events.py", line 678, in run_forever self._run_once() File "/usr/local/lib/python3.13/asyncio/base_events.py", line 2033, 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/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())
Did the same and all back for normal now, Thanks
Same errors/warnings in my logs
I have been able to configure Ramses with an evofw module, and I am seeing nice visualizations in Home Assistant. Thanks @Kars
Question 1:
One of the zones shows Head demand: Unavailable. What does this mean, and how can I remedy this?
Question 2:
I have installed a HCC100 recently. Is there any chance that information from this system will show up in HA?
Thanks in advance.
UFH controller support is sadly lacking - it requires some refactoring of the core code, and I never got around to it (I even bought a HCC80 for that reason - now gone).
I will contemplate PRs… but, TBH - it would be a bit of work. Not a good first project for anyone.
IS UFH support lacking or sometimes not fully functional? I have 2 HCE80’s, one with 2 zones, one with 4 zones. The former reports heat demand on both zones, the latter only heat demand for 1 out of 4 zones.
Hi, Im trying to use helper as my input values for duration (and eventually setpoint). Is this possible? I’ve tried below, returning an error say input_number is not defined.
If I try just with direct input_number (i.e. not convert to float) I get the following error:
Error: expected float for dictionary value @ data['duration']['hours']
Any pointers or suggestions on next steps? I suspect it’s a very obvious mistake I’m making…
action: ramses_cc.set_zone_mode
metadata: {}
data:
mode: temporary_override
duration:
hours: ‘{{ input_number.durationhours | float }}’
minutes: 0
seconds: 0
entity_id: climate.box_room
setpoint: 21
enabled: true
I think your data section is indented too far - it should be at the same level as metadata:{}
action: ramses_cc.set_zone_mode
metadata: {}
data:
mode: temporary_override
duration:
hours: ‘{{ input_number.durationhours | float }}’
minutes: 0
seconds: 0
entity_id: climate.box_room
setpoint: 21
enabled: trueGuys, a quick question from a complete newbie who is trying to figure out how to configure ramses_cc in combination with ramses_esp unit. I have data flowing into the ramses integration, ie devices and entities are visible and (some are) populated with data. However, in my house I have two Evohome controllers controlling separate heating systems. The discovery process seem to more or less correctly discover one controller and its related zones, though its not complete correct. The other controller and a whole bunch of TRV devices were orphaned.
I tried resetting the caches and restarting HA. The discovery process improved the schema for the first controller - but still with two inaccuracies. However, the second controller has disappeared from the schema in .storage along with some other devices, although they still appear in the Ramses device list.
So, two questions: does ramses support (the discovery of) two evohome controllers plus associated devices. And, how do I correct mis-discovered device configurations?
Further, I’ve not yet figure out how to associated a device_id with a physical device. Any hints?
Thanks in advance, Robert.