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

phdelodder · September 29, 2022, 5:12am

In my system(Belgium based) I can only see the appliance_control from OTB, we also use the heating system for hotwater but we can’t see any of sensors or even manage the temperature.

Thanks for explaining! Could add that to the wiki perhaps?

iMiMx · September 29, 2022, 6:24am

most systems have a appliance_control relay (+/- a DHW relay)

Oh - I think I misunderstood the wiki then, will have to re-read, I thought this was OTB only - I don’t seem to have any appliance_control set/learnt and nothing ‘forced’ by the config:

schema:
  system:
    appliance_control: null
  orphans: []
  stored_hotwater:
    sensor: '07:014869'
    hotwater_valve: '13:215029'
    heating_valve: '13:246213'
  underfloor_heating: {}

… just a ‘regular’ BDR relay and DHW system.

EDIT: So the wiki shows the config snip of:

ramses_cc:
  01:111111:
    system:
      appliance_control: 10:123446  # an OTB

If I/we don’t have OTB, should we specifying something for appliance_control? Or not? Or should it be learnt/discovered into the schema automatically? I’m afraid that part is not clear to me.

Current config:

ramses_cc:
  restore_cache: true
  scan_interval: 60
  serial_port: 
    port_name: /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0
    baudrate: 57600
  packet_log: 
    file_name: /config/packet.log
    rotate_backups: 3
  ramses_rf:
    enforce_known_list: true
    max_zones: 8
  01:050858:
    zones:
      "07": {sensor: 01:050858}  # The Controller is the sensor for Hallway   
  known_list:
    01:050858:                 # Controller
....
....

Spaco · September 29, 2022, 7:26am

I have the same thing, just a plain BDR (13:259021) driving the boiler and I get

schema: 
system:
  appliance_control: null
orphans: []

Also no orphans, even though there should be 3. All devices are in known_list.

ramses_cc:
#  restore_cache: false
  scan_interval: 60
  serial_port: /dev/ttyACM0
  packet_log: /home/homeassistant/.homeassistant/packet.log
  ramses_rf:
    enable_eavesdrop: false
    enforce_known_list: true
  orphans_heat: [13:032522, 30:173916, 34:046925]
  01:201047:
    zones:
      "00":
        sensor: 01:201047

iMiMx · September 29, 2022, 7:50am

So maybe mine isn’t ‘most systems’ - as I do have the heating relay and hotwater relay… so maybe I fit into the ‘others may instead’ category

relay_demands:
  FA: 0
  F9: 0

Kars · September 29, 2022, 10:19am

I tested the following services on 0.21.3:

remote.send_command → Works
remote.learn_command → Doesn’t work, stack trace. I used this YAML:

service: remote.learn_command
data:
  command: away
  timeout: 60
target:
  entity_id: remote.29_xxxxxx

The error log:

2022-09-29 10:01:53.407 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection] [140698938164416] Error handling message: Unknown error (unknown_error)
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/websocket_api/decorators.py", line 27, in _handle_async_response
await func(hass, connection, msg)
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 646, in handle_execute_script
await script_obj.async_run(msg.get("variables"), context=context)
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 1513, in async_run
await asyncio.shield(run.async_run())
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 405, in async_run
await self._async_step(log_exceptions=False)
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 449, in _async_step
self._handle_exception(
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 472, in _handle_exception
raise exception
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 447, in _async_step
await getattr(self, handler)()
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 680, in _async_call_service_step
await service_task
File "/usr/src/homeassistant/homeassistant/core.py", line 1738, in async_call
task.result()
File "/usr/src/homeassistant/homeassistant/core.py", line 1775, in _execute_service
await cast(Callable[[ServiceCall], Awaitable[None]], handler.job.target)(
File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 204, in handle_service
await service.entity_service_call(
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 676, in entity_service_call
future.result() # pop exception if have
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 931, in async_request_call
await coro
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 713, in _handle_entity_call
await result
File "/config/custom_components/ramses_cc/remote.py", line 143, in async_learn_command
with self._broker._sem:
AttributeError: 'RamsesCoordinator' object has no attribute '_sem'

zxdavb · September 29, 2022, 10:24am

There is no ‘maybe’ - yours is definitely a ‘type 2’ system (for want of a better name).

Note: Such systems can be discovered - that is: you don’t need to specify this in your configuration schema.

These systems can also be discovered:

schema:
  system:
    appliance_control: '13:246213'
  stored_hotwater:
    sensor: '07:014869'
...

However, OTBs cannot be discovered, and have to be in your configured schema:

schema:
  system:
    appliance_control: '10:246213'
  stored_hotwater:
    sensor: '07:014869'
...

If a device is in the merged schema (the configured schema is merged into the cached schema), then it is initiated (created) when HA is started - this includes any of the orphans.

NOTE: Devices in the known_list are not instantiated open startup of HA - the known list just tells ramses_rf what to do if teh device is instantiated.

Kars · September 29, 2022, 10:27am

I also tested ramses_cc.fake_device, using this YAML:

service: ramses_cc.fake_device
data:
  device_id: "29:123456"
  create_device: true
  start_binding: true

Which gave the following error:

Unexpected error for call_service at pos 1: The device is not fakable: 29:123456
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 447, in _async_step
    await getattr(self, handler)()
  File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 680, in _async_call_service_step
    await service_task
  File "/usr/src/homeassistant/homeassistant/core.py", line 1738, in async_call
    task.result()
  File "/usr/src/homeassistant/homeassistant/core.py", line 1775, in _execute_service
    await cast(Callable[[ServiceCall], Awaitable[None]], handler.job.target)(
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 799, in check_permissions
    return await service_handler(call)
  File "/config/custom_components/ramses_cc/__init__.py", line 106, in svc_fake_device
    broker.client.fake_device(**call.data)
  File "/usr/local/lib/python3.10/site-packages/ramses_rf/gateway.py", line 731, in fake_device
    raise TypeError(f"The device is not fakable: {device_id}")
TypeError: The device is not fakable: 29:123456

Note that I did not list this device id anywhere in my config, I would expect that to work given the documentation of the create_device-parameter, but perhaps I’m mistaken there.

zxdavb · September 29, 2022, 10:30am

That is a silly regression - I have fixed it & will push a fix later today.

zxdavb · September 29, 2022, 10:42am

My instinct is that you shouldn’t need to do this.

Thsi shoudl only happen if:

you have an OTB
you have a ‘type 2’ system, like:

system:
  appliance_control: null
stored_hotwater:
  heating_valve: '13:24621

Others have reported a similar issue - please send me a known_list & packet log from a restart of HA.

If you have already sent me the above - sorry - I get a lot of such sent to me & I have overwhelmed last week - I can look at it today.

neeu2 · September 29, 2022, 11:15am

Some test results using 0.21.3

RAMSES RF: Set the Mode of a TCS - works when only Mode is selected
If days selected, does not work
Duration, Ticking does not provide option to add any value. Also does not add duration to yaml
RAMSES RF: Set the Mode of a Zone - Sets the zone to 35c, GUI does not provide option to set the temp. When I add setpoint: value to yaml, works as expected
RAMSES RF: Reset the Mode of a Zone - works
RAMSES RF: Set the Configuration of a Zone - works
RAMSES RF: Reset the Configuration of a Zone - works
RAMSES RF: Set the Configuration of a DHW - Only change the setpoint, Overrun and differantial is not changed
RAMSES RF: Reset the Configuration of a DHW - reset the HW temprature back to default value, but overrun and differtial are not reset
RAMSES RF: Set the Mode of a DHW - DHW setting to on works, Override duration, although says minutes, its actioned as seconds (3600 overrides for 1 hour)
Note: Existing auomations will need to be updated with the DHW entity ID
RAMSES RF: Get the Weekly schedule of a Zone - works and schedule availble in States
RAMSES RF: Get the Weekly schedule of a DHW - works and schedule availble in States

Please let me know if any require further clarifications

Spaco · September 29, 2022, 11:54am

No worries, sent you a restart log and config last week. No rush.

Also noticed that zone schedule attributes are ~~all null~~ on the latest version. scratch that, calling the service populates the attr.

zxdavb · September 29, 2022, 11:56am

Thanks a lot!

This breaking change is because I have removed the assumption that there is only one evohome controller per HA instance.

I have added it to the release notes.

zxdavb · September 29, 2022, 11:57am

They will be null if:

you haven’t requested the schedule manually, or
you did, but you restarted HA, and haven’t a state cache

Kars · September 29, 2022, 1:20pm

@zxdavb Did you also see this report from me about fake_device?

neeu2 · September 29, 2022, 3:22pm

Found another minor bug on the StoredHW entity.
Prior to the upgrade to 0.21.3, I was able to use it to change the Set temp of the HW as well as changing Operation mode of the DHW (added to entities card and when clicked on it, as shown below)
Now if I try to change the temp, get the error shown, Changing opetation still works

phdelodder · September 29, 2022, 4:31pm

For 9 of my 10 zones all the current_temperature are set to NULL

Currently using version 0.20.22f

zxdavb · September 29, 2022, 6:28pm

Two updates coming:

Stable Release (stable branch), v0.21.4 (using ramses_rf v0.21.0):

fixed not discovering appliance_control
added convenient service calls for remotes
bugfix regression for learn_command service call
fixed some various reported service call bugs

Candidate Release (master branch), v0.20.22j (using ramses_rf v.0.20.37):

fixed not discovering appliance_control

evoboff · September 29, 2022, 6:40pm

Can this be utilised? I have two controllers in my setup: 1 ‘active’ which controls my opentherm bridge and 1 ‘passive’ which just manages zones but without the ability to call for heat.

zxdavb · September 29, 2022, 6:44pm

You can try adding both schemas to the configuration, and see how you get on:

ramses_cc:
  ...
  01:1111111:
    system: {appliance_control: 10:111111}
    ...
  01:222222:
    ...
  known_list:
      01:111111:
      01:222222: 
      10:111111:

It should handle multiple controllers… but there may be a few bugs to iron out.

zxdavb · September 29, 2022, 6:57pm

There doesn’t appear to be an issue with the code:

2022-09-29T18:07:05.151974 046  I --- 04:155403 --:------ 04:155403 30C9 003 000682
2022-09-29T18:07:12.358187 062  I --- 01:223036 --:------ 01:223036 30C9 030 0007A70106C402072A0306EB04066D0506A90606980706820806EA09065F

2022-09-29T18:09:12.855285 059  I --- 01:223036 --:------ 01:223036 30C9 030 0007A70106C402072A0306EB04066D0506A90606980706820806EA09065F

2022-09-29T18:11:37.980396 058  I --- 01:223036 --:------ 01:223036 30C9 030 0007B0017FFF027FFF037FFF047FFF057FFF067FFF077FFF087FFF097FFF

2022-09-29T18:13:13.893370 056  I --- 04:231772 --:------ 04:231772 30C9 003 0006EC
2022-09-29T18:13:38.479046 059  I --- 01:223036 --:------ 01:223036 30C9 030 0007B0017FFF027FFF037FFF047FFF057FFF067FFF077FFF087FFF097FFF
...

You’ll see that at 2022-09-29T18:09:12.855285, everything was fine, then at 2022-09-29T18:11:37.980396, all the zone temps were null (7FFF).

This is despite the zone sensor for zone 07 (04:155403) doing a perfectly good announcement at 2022-09-29T18:07:05.151974.

I wonder if the controller is in a cupboard?

The reason why zone 00 is not affected is because it is using the controller at the zone sensor.