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

I have all latest updates, assume I can just wait for the voluptuous fix?

I am getting the following error:

> Logger: homeassistant.config_entries
> Source: config_entries.py:604
> First occurred: 18:16:49 (1 occurrences)
> Last logged: 18:16:49
> 
> Error setting up entry RAMSES RF for ramses_cc
> Traceback (most recent call last):
>   File "/usr/src/homeassistant/homeassistant/config_entries.py", line 604, in async_setup
>     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())
>   File "/usr/local/lib/python3.12/site-packages/ramses_rf/gateway.py", line 184, 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 358, 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 399, in load_tcs
>     ctl = _get_device(gwy, ctl_id)
>           ^^^^^^^^^^^^^^^^^^^^^^^^
>   File "/usr/local/lib/python3.12/site-packages/ramses_rf/schemas.py", line 343, in _get_device
>     return gwy.get_device(dev_id, **kwargs)
>            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   File "/usr/local/lib/python3.12/site-packages/ramses_rf/gateway.py", line 400, in get_device
>     traits: dict[str, Any] = SCH_TRAITS(self._include.get(device_id, {}))
>                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   File "/usr/local/lib/python3.12/site-packages/voluptuous/validators.py", line 259, in __call__
>     return self._exec((Schema(val) for val in self.validators), v)
>            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   File "/usr/local/lib/python3.12/site-packages/voluptuous/validators.py", line 315, in _exec
>     raise error if self.msg is None else AnyInvalid(self.msg, path=path)
>   File "/usr/local/lib/python3.12/site-packages/voluptuous/validators.py", line 307, in _exec
>     return func(v)
>            ^^^^^^^
>   File "/usr/local/lib/python3.12/site-packages/voluptuous/schema_builder.py", line 205, in __call__
>     return self._compiled([], data)
>            ^^^^^^^^^^^^^^^^^^^^^^^^
>   File "/usr/local/lib/python3.12/site-packages/voluptuous/validators.py", line 256, in _run
>     return self._exec(self._compiled, value, path)
>            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   File "/usr/local/lib/python3.12/site-packages/voluptuous/validators.py", line 315, in _exec
>     raise error if self.msg is None else AnyInvalid(self.msg, path=path)
>   File "/usr/local/lib/python3.12/site-packages/voluptuous/validators.py", line 309, in _exec
>     return func(path, v)
>            ^^^^^^^^^^^^^
>   File "/usr/local/lib/python3.12/site-packages/voluptuous/schema_builder.py", line 779, in validate_callable
>     return schema(data)
>            ^^^^^^^^^^^^
>   File "/usr/local/lib/python3.12/site-packages/voluptuous/schema_builder.py", line 205, in __call__
>     return self._compiled([], data)
>            ^^^^^^^^^^^^^^^^^^^^^^^^
>   File "/usr/local/lib/python3.12/site-packages/voluptuous/schema_builder.py", line 549, in validate_dict
>     return base_validate(path, data.items(), out)
>            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   File "/usr/local/lib/python3.12/site-packages/voluptuous/schema_builder.py", line 382, in validate_mapping
>     raise er.MultipleInvalid(errors)
> voluptuous.error.MultipleInvalid: not a valid value @ data['controller']

This looks like the same cause (bug in voluptuous).

For the previous issue, I created a work around - I’ll have to do one here as well, since I don’t expect a fix to voluptuous at all soon.

Can you please post your schema?

Many thanks. Heres details:

System schema

01:081083":
>   system:
>     appliance_control: null

Known devices


"01:081083":
  controller: null
"07:025191":
  dhw_sensor: null
"13:173107":
  electrical_relay: null
"04:027656":
  radiator_valve: null
"34:150655":
  thermostat: null
"13:001489":
  electrical_relay: null
"34:027677":
  thermostat: null
"13:055679":
  electrical_relay: null
"34:150571":
  thermostat: null
"13:001522":
  electrical_relay: null
"04:023780":
  radiator_valve: null
"04:027356":
  radiator_valve: null
"04:027722":
  radiator_valve: null
"04:023774":
  radiator_valve: null
"04:027650":
  radiator_valve: null
"04:027714":
  radiator_valve: null
"04:027720":
  radiator_valve: null
"04:027648":
  radiator_valve: null
"04:027358":
  radiator_valve: null
"04:027646":
  radiator_valve: null
"04:027718":
  radiator_valve: null
"04:027716":
  radiator_valve: null
"04:027360":
  radiator_valve: null
"34:063533":
  thermostat: null
"13:224329":
  electrical_relay: null
"13:003271":
  electrical_relay: null
"34:150657":
  thermostat: null
"18:203270":
  gateway_interface: null

Is it safe to update to hacs 2.0.0 for this integration?
Using 0.41.23

works for me using 0.42.0
lots of depreciated function warnings are fixed…

1 Like

Your known_list is misconfigured.

This is what it your known_list should look like:

"01:081083":
  class: controller
"04:023774":
  class: radiator_valve
"04:023780":
  class: radiator_valve
"04:027356":
...

If people post me yaml, I’d be grateful if it was formatted correctly.

Many thanks for the response.
I actually didnt create this, i’m pretty sure it was auto-populated, perhaps that wasnt the correct process. I did try to follow the Wiki.
Should I edit it with the Serial Port details at top (which is actually also in the configuration) and the formatting with “known list” at top as you have in example?

This is what it looks like from the auto-population.

David, any news on removing this error from ramses_rf? How can I disable it in the meantime?

I got everything back in working order again after removing and installing the integration again.
Can someone tell me what kind of devices HVC and THM are?

Apologies, For those interested the icon for preformatted message blocks moved to the settings cog. I wanted to respond ASAP. I have now fixed formatting.

OK, looks like a bug - I’ll have a look at it.

I was just referring to the known_list - leave the rest as it is.

I have just realised that this could be misunderstood - I am sorry (I often type very quickly without thinking).

What I meant is that please post YAML using the triple-quotes, like this:

rather than this:

The above quotes have been edited to demonstrate my point.

Also, please avoid posting screen grabs, unless it is useful - I cannot copy and post off them.

Just type:

  • three back-quotes, a carriage return,
  • then post your text, then another carriage return, and
  • three more back quotes and a final carriage return

This will preserve (leading) spaces, and (e.g.) double quotes won’t be converted:

Like this:

```yaml
ramses_cc:
  serial_port: /dev/null

"01:081083":
  system:
    appliance_control: null
```

So you get:

ramses_cc:
  serial_port: /dev/null

"01:081083":
  system:
    appliance_control: null

Instead of:

ramses_cc:
serial_port: /dev/null

“01:081083”:
system:
appliance_control: null

Sorry the wiki is woeful, and this integration has a complicated configuration:

  • HVC: the system believes the device is from the HVAC domain (rather than the heat domain - aka CH/DHW, aka evohome)
  • THM - thermostat

Carried out a Home Assistant upgrade and RAMSES_RF upgrade today and I’m seeing these two errors.

Is there anything I need to worry about just now?

Detected blocking call to iglob with args (‘/dev/rfcomm*’,) inside the event loop by custom integration ‘ramses_cc’ at custom_components/ramses_cc/broker.py, line 175: return Gateway( (offender: /usr/local/lib/python3.12/glob.py, line 28: return list(iglob(pathname, root_dir=root_dir, dir_fd=dir_fd, recursive=recursive,)

Detected that custom integration ‘ramses_cc’ calls async_forward_entry_setup for integration, ramses_cc with title: RAMSES RF and entry_id: 01J5BCMDB4J6HKZV43FC9F9AFK, which is deprecated and will stop working in Home Assistant 2025.6, await async_forward_entry_setups instead at custom_components/ramses_cc/broker.py, line 217: self._platform_setup_tasks[platform] = self.hass.async_create_task

These are the versions I’m on.

HA Core 24.8.3, supervisor 2024.08.0, OS 13.1

RAMSES RF 0.41.23

Cheers

Mike

These two are warnings, not errors.

Please try 0.42.0 (is a beta version) - I believe one of these has been fixed.

HA is (quite rightly) becoming ever more strict about blocking calls (usu. I/O) in the main thread.

These warnings can be ignored for now - I will address them in due course.

This will need a code change to reduce logspam.

ok, so you’ll add it to the list of tasks - you probably have nothing better to do anyhow. Hahaha. Much appreciated David!

Thanks! I believe that these items are the separate temperature sensors (HCF82) I use for certain rooms. The THM is another Honeywell Round thermostat that I use as a temperature sensor. A complete thermostat was cheaper than a temperature sensor alone…

I got no idea where that came from. Mine looks like this:

Did you start with a configuration.yaml and convert that to a config flow entry?

To be clear: class: HGI and class: HUM are the same as class: humidity_sensor, etc.

The point is: it is class: XXX, not XXX: null.