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

Not sure if the 2 second delay is necessary, but decided to include to avoid sending too many quick RF messages.

alias: Update room temperature sensors
description: ''
trigger:
  - platform: time_pattern
    minutes: /4
condition: []
action:
  - service: evohome_cc.set_zone_temp
    data:
      entity_id: climate.kitchen
      temperature: '{{ states.sensor.ble_temperature_kitchen.state | float }}'
  - delay:
      hours: 0
      minutes: 0
      seconds: 2
      milliseconds: 0
  - delay:
      hours: 0
      minutes: 0
      seconds: 2
      milliseconds: 0
  - service: evohome_cc.set_zone_temp
    data:
      entity_id: climate.snug
      temperature: '{{ states.sensor.ble_temperature_snug.state | float }}'
  - delay:
      hours: 0
      minutes: 0
      seconds: 2
      milliseconds: 0
  - service: evohome_cc.set_zone_temp
    data:
      entity_id: climate.bed1
      temperature: '{{ states.sensor.ble_temperature_bed1.state | float }}'
  - delay:
      hours: 0
      minutes: 0
      seconds: 2
      milliseconds: 0
  - service: evohome_cc.set_zone_temp
    data:
      entity_id: climate.bed2
      temperature: '{{ states.sensor.ble_temperature_bed2.state | float }}'
  - delay:
      hours: 0
      minutes: 0
      seconds: 2
      milliseconds: 0
  - service: evohome_cc.set_zone_temp
    data:
      entity_id: climate.bed3
      temperature: '{{ states.sensor.ble_temperature_bed3.state | float }}'
  - delay:
      hours: 0
      minutes: 0
      seconds: 2
      milliseconds: 0
  - service: evohome_cc.set_zone_temp
    data:
      entity_id: climate.study
      temperature: '{{ states.sensor.ble_temperature_study.state | float }}'
  - delay:
      hours: 0
      minutes: 0
      seconds: 2
      milliseconds: 0
  - service: evohome_cc.set_zone_temp
    data:
      entity_id: climate.ironing_room
      temperature: '{{ states.sensor.ble_temperature_ironing_room.state | float }}'
  - delay:
      hours: 0
      minutes: 0
      seconds: 2
      milliseconds: 0
  - service: evohome_cc.set_zone_temp
    data:
      entity_id: climate.ensuite_1
      temperature: '{{ states.sensor.ble_temperature_en_suite_1.state | float }}'
  - delay:
      hours: 0
      minutes: 0
      seconds: 2
      milliseconds: 0
  - service: evohome_cc.set_zone_temp
    data:
      entity_id: climate.ensuite_2
      temperature: '{{ states.sensor.ble_temperature_en_suite_2.state | float }}'
  - delay:
      hours: 0
      minutes: 0
      seconds: 2
      milliseconds: 0
  - service: evohome_cc.set_zone_temp
    data:
      entity_id: climate.ensuite_3
      temperature: '{{ states.sensor.ble_temperature_en_suite_3.state | float }}'
mode: single

Thank you, i’am going to try to make it this week, I think I will do it with node-red for my office and bathroom because the hr92s are not on ideal positions.

@DanRP I am not 100% sure what you’re trying to acheive, but it sounds like you’re trying to get the controller to be fooled into beleiving that a current temperature coming from something other than a (real) TRV is actually coming from that TRV?

Not possible.

No worries, having re-read your earlier response it now makes sense.

Can’t you just trigger on when the xiaomi changes temperature? You’d have to have a single automation for each xiaomi sensor (or maybe not), with a trigger on state.

If you are going to do it every few miniutes, make it slightly less that your system_sync interval (mine is 185.5 seconds)?

ramses_rf can handle 12x evohome_cc.set_zone_temp in a row, no worries.

I had it like that initially, but I got a comms fault on the controller from one of my zones which I thought may have come from the temperature not being updated frequently enough?

What is system_sync, not come across that?

Oke, i have it working with node-red with this flow:

First i have a trigger when the temp changes:

Then it put the temperature in a value payload:

And last i set with ecohome_cc.set_zone_temp with the payload value the temperature:

One question how is the temperature rounded? i send 18.8 and evohome report 18.5.
I would expect it’s rounded to 19 but it isn’t, i notised this before so it has nothing to do with the fake sensor.

I should add that it will usually behave in a way that the controller will put up with - there are contrived edge cases where this is not true.

This is something that the controller is doing. The displayed temp is rounded up/down to the nearest 0.5. IIRC, it rounds towards the setpoint.

1 Like

See: 1F09: System Synchronization ¡ zxdavb/ramses_protocol Wiki ¡ GitHub

@dariusz I am guessing you have a HB85.

Could you capture a packet log where you re-bind it to your controller for me?

I was wondering if it is, like in Domoticz, possible to have/create the sensors below:

Relative modulation level
CH Water Pressure
Boiler Water Temperature
Return Water Temperature

I assume you’ve a OpenTherm Bridge?

All these should be readily available, with only a little effort:

    @property
    def opentherm_status(self) -> dict:
        return {
            "boiler_temp": self.boiler_water_temp,
            "ch_pressure": self.ch_water_pressure,
            "dhw_flow_rate": self.dhw_flow_rate,
            "dhw_temp": self.dhw_temp,
            "rel_modulation_level": self.rel_modulation_level,
            "return_cv_temp": self.return_cv_temp,
        }

    @property
    def status(self) -> dict:
        return {
            **super().status,
            self.BOILER_SETPOINT: self.boiler_setpoint,
            self.MODULATION_LEVEL: self.modulation_level,
            self.OPENTHERM_STATUS: self.opentherm_status,
        }

All I require is someone to help me test this feature.

Is there a branch where I can test this?

Nice, I would like to test this, I have a Remeha system with OpenTherm.
How can I test this feature?

So, just pushed 0.9.3 - all (significant) known bugs should have been addressed.

Please let me know if I am wrong.

Also includes a new feature to disable use of ZoneMode.ADVANCED for those systems that do not support it - thanks @sOckhamSter!
advanced_override config option by sOckhamSter ¡ Pull Request #32 ¡ zxdavb/evohome_cc (github.com)

3 Likes

@zxdavb Just pulled the latest update, no issues found yet.

With this version i have 2 new entity id’s starting with 00.
If you open them controller id, domain id and zone are empty.
What can this be?

TL;DR: I suspect you’re not using an allow_list?

Or: Why don’t you tell me the device IDs, and also provide a copy of your schema?

I’am using an alow list, this is my config:

evohome_cc:
  scan_interval: 300
  serial_port: /dev/ttyUSB1
  packet_log: /home/homeassistant/packet.log
  advanced_override: true
  config:
    max_zones: 6
  schema:
    controller: 01:155341
  allow_list:
    - 01:155341
    - 04:008512
    - 04:070150
    - 04:070154
    - 04:070160
    - 04:073460
    - 04:108167
    - 04:108169
    - 04:108171
    - 04:108173
    - 13:189740
    - 03:256005 #fake sensor office

only id 03:256005 i added a few days ago, this is a fake sensor, i added it to the allow list because it had an exclamation point that didn’t go away (the battery of the fake sensor has an exclamation but because it’s a fake sensor i think it’s normal)

this are the 2 new id’s:
00:110277
00:256005
both have 4 entitties as a HR92. only temp has no exclamation point.

i have to look into the schema, don’t know where to find it yet.

Edit:
if i look in my packet log i think it has something to do with the fake sensore because i see that id in the line:

pi@hassbian:/home/homeassistant $ cat packet.log | grep 00:110277
2021-05-11T02:24:06.205578 000  I --- 00:110277 --:------ 03:256005 30C9 003 0007DA
pi@hassbian:/home/homeassistant $ cat packet.log | grep 00:256005
2021-05-10T23:44:06.166978 000  I --- 00:256005 --:------ 03:256005 30C9 003 000802

Edit 2:
in the wiki i find that i can find the schema with this command:

cat home-assistant.log | grep Schema

but in my homeassistant.log there is no schema mentioned.