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

zxdavb · September 29, 2022, 8:51pm

I am continuously making changes to the master branch - not all of them are mentioned in changelogs.

If you install 0.21.x - the Candidate release, you can have a go, YMMV.

prescott · September 29, 2022, 8:57pm

You are a genius, you bet I will. Thanks !

EDIT:
2nd controller in config still has “unavailable” schema entity in HA.

My config:

ramses_cc:
  serial_port: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0
  ramses_rf:
    # disable_discovery: true
    disable_sending: true
    # enable_eavesdrop: true
  scan_interval: 60
  restore_cache: false
  01:xxxxxx:
    zones:
      "00": {sensor: 01:xxxxxx}
  01:yyyyyy:
    zones:
      "01": {sensor: 01:yyyyyy}
  known_list:
    01:xxxxxx:
    01:yyyyyy:

EDIT2:
I meant/forgot to write 2nd controller’s “unavailable” schema entity

Also I tried to comment with no effect after:

  # ramses_rf:
    # disable_sending: true

EDIT3:
In log I still get this error:

Best practice is exactly one gateway (HGI) in the known_list: []

EDIT4:
I managed to fix HGI log error (by adding 18:076321). Now it added lots more errors and still no two schemas.
Will work on this more tommorow and report back with everything and those errors.

EDIT5:
I cant stop, but this is my last edit for today, before my brain melts…

In “18:076321 status” entity, I see:

both controllers
BDR91 (i believe)
all actuators and sensors from both controllers (i believe, need to check 1 by 1 = tommorow!)

But 2nd schema still “unavailable”. Does it need to be available? All I want is to see heat demands from all zones and in my mind I will kiss your *** (will also check tommorow if I already see those)

EDIT6:
OK, really this is now last.

In 18: status:

Under schema, only 1 controller
Under known_list, 2 controllers (both are actually in configs known_list
Under known_list, I counted 1 electrical_relay + all actuators + all t87rf sensors (but none are actually in known_list)

So I believe:

It is parsing bdr91+t87rf+hr92, eventhough they are not in actual configs known_list
It is not parsing 2nd controller, eventhough it is in actual configs known_list+ramses_cc

phdelodder · September 30, 2022, 5:21am

When looking at the climate entity, the hvac_action is trigger by the heat_demand (ramses_cc/climate_heat.py at 4000f5b86477a3a5c2fad809a19a5f126c39b5c5 · zxdavb/ramses_cc · GitHub), on what heat_demand does it base it self or could that heat_demand be added to the climate entity?

climate.woonkamer when hvac_action is heating:

hvac_modes: auto, heat
min_temp: 5
max_temp: 35
target_temp_step: 0.1
preset_modes: none, temporary, permanent
current_temperature: 20.1
temperature: 20
hvac_action: heating
preset_mode: none
zone_idx: 00
heating_type: radiator_valve
mode: 
mode: follow_schedule
setpoint: 20

config: 
min_temp: 5
max_temp: 35
local_override: false
openwindow_function: false
multiroom_mode: false

schema: 
_name: Woonkamer
class: radiator_valve
sensor: '01:223036'
actuators:
  - '04:231772'
  - '04:231774'
  - '04:231776'

params: 
config:
  min_temp: 5
  max_temp: 35
  local_override: false
  openwindow_function: false
  multiroom_mode: false
mode:
  mode: follow_schedule
  setpoint: 20
name: Woonkamer

icon: mdi:radiator
friendly_name: Woonkamer
supported_features: 17

Spaco · September 30, 2022, 5:41am

There should be a heat demand sensor per zone, something like sensor.01_201047_03_heat_demand

phdelodder · September 30, 2022, 5:48am

Thanks, learned something new! Fixed my dashboard.

Kars · September 30, 2022, 6:40am

Testing using 0.21.4, the command no longer gives an error, but I would expect an extra entry in the commands list of the remote after the call is finished. I didn’t see that, there’s nothing in the logs either.

I also tried the new ramses_cc.learn_command service. Several things I noticed:

The description of the timeout parameter is wrong (it mentions CO2 level).
The timeout parameter should be marked as mandatory, the service fails if you don’t set the check box.
It doesn’t seem to pass the command parameter to the underlying call, when I call the service using this yaml I get an error:

service: ramses_cc.learn_command
data:
  entity_id: remote.29_163515
  command: away
  timeout: 120

The error is:

websocket_api script: Error executing script. Unexpected error for call_service at pos 1: must be exactly one command to learn
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/entity_platform.py", line 769, 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 214, in svc_learn_command
    await self.async_learn_command(*args, **kwargs)
  File "/config/custom_components/ramses_cc/remote.py", line 140, in async_learn_command
    raise TypeError("must be exactly one command to learn")
TypeError: must be exactly one command to learn

kardiologia · September 30, 2022, 6:48am

Thank you very much for your response. I have another problem. In a zone I am getting heat demand 101%, which generates an error in the log file: Coding error: ValueError(Invalid result: 1.01 (0xCA) is > 1). My homeassistant configuration uses ssm-d2 as gateway interface. I have parallel a hgi80 interface using another rpi and Domoticz, which also displays 101% heat demand. I don’t understand, why this coding error occurs. Could you not floor heat demand > 1 to 1 without throwing an error message?

Lloyd · September 30, 2022, 7:26am

Thanks - fixed in 0.21.5

neeu2 · September 30, 2022, 9:00am

Tested the following on 0.21.5

RAMSES RF: Set the Configuration of a DHW - Only change the setpoint, Overrun and Differantial ivalues are not changed

RAMSES RF: Reset the Configuration of a DHW - reset the HW temprature back to default value (50), but overrun and differtial are not reset

Changing the DHW setpoint via Store HW entity via GUI now works

TheMystery · September 30, 2022, 9:38am

Did you re-release version v0.20.22i? i don’t see the j version and on github the i version is from 15 hours ago.
I redownloaded the i version but still no appliance_control after reboot and 10 min uptime.

Spaco · September 30, 2022, 9:40am

on 0.21.5 and the BDR appliance_control is there now. did you do a restore_schema/state false?

TheMystery · September 30, 2022, 9:44am

upgrade now to 0.21.5 and appliance control is back.

evoboff · September 30, 2022, 6:54pm

Is there a way I can associate my UFH ‘circuits’ with my ‘zones’ via configuration? Extract of schema below:

system: 
  appliance_control: '10:124973' 
  orphans: [] 
  stored_hotwater: {} 
  underfloor_heating: '02:001786': 
    circuits: '00': zone_idx: '02' '01': zone_idx: '04' 
  zones: 
    '00': _name: Living Room class: radiator_valve sensor: '01:081046' actuators: - '04:254312' 
    '02': _name: Kitchen class: underfloor_heating sensor: '34:175809' actuators: [] 
    '03': _name: Master Bed class: radiator_valve sensor: '22:210057' actuators: - '04:254288' 
    '04': _name: Diner class: underfloor_heating sensor: '34:176169' actuators: []

zxdavb · September 30, 2022, 8:20pm

@prescott (and some others)

For the master branch, I have just released 0.21.5.

This is a fragment of the schema I was using:

ramses_cc:

  01:145038:
    system:
      appliance_control: 10:048122

  01:136410:
    system:
      appliance_control: 13:273335
    stored_hotwater: {sensor: 07:123456}

As an aside: I spend a lot on hardware (you’ll see I have two controllers)…

If anyone has OTB, and would like to see the quality of the OpenTherm support improve, I am buying a new EMS gateway - if anyone would like to contribute to the cost, please PM me for a PayPal think. Thanks

zxdavb · September 30, 2022, 8:36pm

Unfortunately, UFH support is suspect.

What are you hoping to achieve, besides a complete schema? (see: XY problem)

Currently the only benefit of full support that I can think of, would be to get (accurate) heat demand per UFH circuit (and thus per zone): a very useful feature that’s currently missing.

If anyone has an unwanted UFH controller that would like to loan/donate to me, then I’d be happy to receive it (it is the only piece of CH/DHW kit I don’t have). Even on ebay, used, they’re just too expensive.

Anyone with UFH can support the effort by supplying packet logs and configuration files.

I would need 24-48h packet logs with heat demand (i.e. the UFH is on/active)

As an aside, the actuator device ID for an UFH circuit would be of the form: 02:001786_01, where the suffix is the circuit ID, for example:

  zones: 
    '00': sensor: '01:081046' actuators: ['04:254312'] 
    '02': sensor: '34:175809' actuators: ['02:001786_00'] 
    '03': sensor: '22:210057' actuators: ['04:254288'] 
    '04': sensor: '34:176169' actuators: ['02:001786_01']

IIRC, the above doesn’t work.

zxdavb · September 30, 2022, 8:44pm

I don’t think anyone would want to be using this feature - it will break a lot of stuff.

The known list

The known list is not a whitelist unless you have enforce_known_list: true. Enforcing is strongly recommended, once you have a complete known list.

Neither does it cause devices to be instantiated (created) - it merely tells ramses_rf what to do with the device when it is instantiated for whatever reason (like being in the schema somewhere).

Lloyd · October 1, 2022, 6:38pm

I’m looking for some advice. I’m having a new boiler fitted this week, which will include an OTB. What is the best way to migrate from a system without an OTB to one with?

zxdavb · October 1, 2022, 8:10pm

@Lloyd Your question could be more specific… As it is, I am not sure I can provide a useful answer.

You disconnect the BDR (BDR91A/T), you add the OTB (R8810A/20A), and you bind it to / re-configure the evohome controller - it is remarkably straight-forward.

In your case, you’re replacing the boiler, so just bind the OTB on top of the BDR at the controller.

From the schema’s point of view - you add the OTB as per many examples above this post.

Anything tricky is likely an idiosyncrasy of the boiler.

prescott · October 2, 2022, 2:14am

@zxdavb sorry for not reporting earlier, I did not have the time…

I upgraded to newest master and I finally see 2x available schemas !!

Im using enforce_known_list and all IDs added from status entity (though most of the times randomly status entity is unavailable with no changes to config).

There are still lots of errors in log and few other things (missing actuators for a zone in schema). I will do a comprehensive report on whats working and whats not later today or tommorow.

Lloyd · October 2, 2022, 9:18am

Apologies, should have been clearer. My questions were around changes to ramses_cc config.

I presume I can get the OTB id from packet.log, but do I have to set enforce_known_list to false for it to appear in the log?

And after adding the OTB as the controller, and adding it to the known_list, do I need to set restore_cache to false, or will it add to the cache?