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

You simply have to wait for battery-power devices to announce their state - this is most apparent, when you start with restore_state: false. Some of these are only announced once every 24h, and if you miss that one…

For a controller, or a relay (BDR/OTB), you can just ask.

Short answer: a zone’s heat demand is (simply) a linear transform of largest pin valve position of the TRVs in that zone.

Kudos to others (@dbmandrake) for determining that transform (the below is simplified):

def _transform(valve_pos: float) -> float:
    if valve_pos <= 30:
        return 0
    t0, t1, t2 = (0, 30, 70) if valve_pos <= 70 else (30, 70, 100)
    return round((valve_pos - t1) * t1 / (t2 - t1) + t0)

This assumes you have no optimizations enabled in the controller - these are still a WIP.

Any learning is done inside the TRV, not in the zone.

1 Like

Anyone with HVAC/MVHR, 0.17.4 is offering much improved support for you… good things are coming…

However, you now must do this:

evohome_cc:
  known_list:
    - 30:111111: {class: CO2}  # CO2 sensor
    - 30:222222: {class: FAN}  # ventilation unit
    - 30:333333: {class: HUM}  # humidity/temp sensor
    - 30:444444: {class: SWI}  # switch (2-way, or 4-way)

Unlike Honeywell CH/DHW devices, HVAC/MVHR device IDs can start with any two-digit number, such as: 18, 20, 29, 30, 32, 37, 57, and so on.

Supported brands of HVAC/MVHR include Itho, Nuaire, Orcon, Sensair, … I’m sure there are many others.

@Cinamon @bishop I am now able to start adding support for these devices into evohome_cc - I’ll probably start with a Climate entity (ventilation unit) & go from there…

This has taken ages - a lot of refactoring…

Thank you all (and especially zxdavb) for the hard work put into this project. I’ve recently installed HASSos and added this custom component so still getting used to and finding out how everything works. I’m using a nanoCUL and am able to monitor the temperature settings and other states without a problem. I do have a couple of questions I hope someone is willing to help me with.

My setup is very basic at the moment with only 2 devices. I have a OpenTherm bridge (R8810) connected to a thermostat (T87RF) in the living room to change the temperature. I was wondering if it is possible, or if it is going to be possible in the future to also change the temperature as well. I think I read somewhere in this topic this was initially the plan but there was an issue? The reason I ask is I don’t have a RFG100 at the moment because I would like to reduce the amount of devices directly connected to the internet. I would be glad to help out if you need a tester.

A thing that seems a bit strange to me is when looking at the evohome_cc file the thermostat shows up as an orphan and doesn’t seem to pick up the zone. I’ve tried fixing it in my configuration.yaml file in different ways (it’s a bit messy now) but so far no luck. Not a big deal at the moment as I’m still able to monitor the sate and temperature settings but in the future I would like to add smart radiator valves and maybe add another thermostat.

Configuration.yaml
#Honeywell
evohome_cc:
  serial_port: /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0
  packet_log: packet.log
  logger:
  logs:
  advanced_features:
    send_packet: true
    message_events: true
  evohome_rf.packet_log: info
  schema:
    controller: 01:******
    system:
      heating_control: 10:******
  zones: 
    '00':
      _name: Living Room
      heating_type: radiator_valve
      sensor: '34:******'
      devices:
        - '34:******'
      _sensor: '34:******'
      _actuators: null      
  ramses_rf:
    enforce_known_list: true
  known_list:
    - '01:******': {"alias": "--controller--"}
    - '10:******': {"alias": "OT bridge R8810A"}
    - '34:******': {"alias": "T87RF2059 Thermostat"}
  restore_state: false
  restore_cache: false
evohome_cc:
{
    "version": 1,
    "minor_version": 1,
    "key": "evohome_cc",
    "data": {
        "client_state": {
            "schema": {
                "main_controller": "01:******",
                "01:******": {
                    "system": {
                        "heating_control": "10:******"
                    },
                    "orphans": [],
                    "stored_hotwater": {},
                    "underfloor_heating": {},
                    "zones": {}
                },
                "orphans": [
                    "34:******"
                ],
                "device_hints": {}

Please be clear - do you have a controller? Or are you using the Round Thermostat as a controller?

Do you have any other devices at all (such as TRVs)? My understanding is that the only other device you can have, when a T87RF is the controller, is a RFG100 gateway…

If you want smart TRVs, you’ll have to get an evohome controler, and use the T87RF as a zone thermostat, but then you can have two zones (using the controller as the 2nd zone thermostat)… …and the newer controllers don’t need a RFG100.

Assuming you don’t have an evohome controller, then your config isn’t fully supported by evohome_cc and - as it is battery-powered - the Round Thermostat won’t be listening for packets, so you’ll have no discovery…

ramses_rf could puzzle the RFG100 instead of the T87RF, this would require some work.

T87RF as a controller

For this scenario, please use the following config:

evohome_cc:
  serial_port: /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0
  packet_log: packet.log
  restore_state: true
  ramses_rf:
    enable_eavesdrop: true

… and see where that takes you.

Later, you could add an allow list:

evohome_cc:
  serial_port: /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0
  packet_log: packet.log
  restore_state: true
  ramses_rf:
    enable_eavesdrop: true
    enforce_known_list: true
  known_list:
    - 10:******
    - 34:******

TBH, I’m not exactly sure how such systems work - you could send a packet log.

Thank you for your quick response. I appreciate your help.

I don’t have a separate controller. I’m indeed using the battery powered Round Thermostat as the controller.

I currently have no other devices. So just the T87RF and R8810. All my TVR’s are currently dumb. Without adding an RFG100, would it theoretically be possible to set the global temperature of the whole house using ‘evohome_cc?’ I could add zigbee TVRs for setting room temperatures using another integration. In that case the zones in evohome are probably are irrelevant and Home Assistant could be suitable for me as an alternative for the evohome controller.

I’m not sure what you mean by that. But if it helps I would be happy to buy an RFG100 to test things and capture packets of that device.

I’ve changed the config to your suggestions and will send you the packet log in a PM.

No. Not really. You could (by getting HA to emulate an evohome controller), but the effort involved would be outrageous… It wouldn’t be much better with a RFG100, unless you were prepared to use the web API & even then you’d be limited in functionality, compared to having a controller…

I think you would be better served by buying the cheapest evohome controller you can get your hands on (you can use a Gen 1, if you don’t want internet access). Maybe something 2nd-hand with some HR91/92s bundled in (don’t get HR80s).

1 Like

Anything I can help with? I have the Nuaire kit.

I would actually be interested in completely replacing my room thermostat (old battery powered unit) with HA and just use the rf connection to the BDR91 to control my boiler. Do you think that would be feasible? I can write python, but I don’t want to dive in if you say it’s a stupid idea.

PS: I do have a number of zigbee TRVs, so that’s what I’d be using as demand generators.

1 Like

First thing, use the above class hints to get the sensors work OK again.

I’ve added the below about an hour ago.

      - 32:166025: {class: CO2} # Co2 Sensor
      - 30:079129: {class: FAN}
      - 32:168240: {class: HUM}
      - 32:172522: {class: SWI} #??

I now have
32:168240 (battery_low) unavailable at the minute
32:168240 (relative_humidity) Working
32:168240 (temperature) Working

30:079129 (boost_timer) Looks like it’s working
30:079129 (battery_low) unavailable
30:079129 (fan_rate) unavailable
30:079129 (relative_humidity) Working

Feasible: completely… just somewhat onerous to implement.

Either HA (automations & evohome_cc) or ramses_rf could emulate a evohome controller.

Emulating a single-zone controller, such as a DTS92(E), a T87RF, or a ST9200 would be a first step.

It depends upon your idea of a stupid idea. Certainly, would make a great project.

But ultimately, an outrageous amount of work for not much benefit.

So that would be my goal. I only have a room thermostat (similar to ST9200) and simple one-zone gas boiler attached.

:joy:

With my limited understanding of the options, the alternative would be to replace the BDR91 with a different kind of relay switch to toggle the boiler and drive that directly (without going through the honeywell RF solution). I would still need to build the thermostat (TRV sensors/demand → on/off) functionality.

How many switches do you have?

 I --- 32:172534 30:079129 --:------ 22F1 003 00020A

Just buy a T87RF/RFG100 kit, or a Gen3 evohome controller & use the official integration…

Or go for a competitor product.

I fixed a few bugs made apparent by your packet logs. I’ve added co2_level as a sensor. It will be in the next drop.

I have two switches.

After updating to 0.17.4, I would say unfortunately that it has not resolved the issue:

  zones:
    '00':
      _name: Living Room
      zone_type: radiator_valve
      zone_sensor: '22:245508'
      sensor_alt: '22:245508'
      devices:
        - '04:055514'
        - '22:245508'
      actuators:
        - '04:055514'
evohome_cc:
  restore_state: false
  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
  schema:
    controller: 01:050858
    # zones:
    #   '00':
    #     devices:
    #       - '04:055594'
    #       - '04:055514'    
  known_list:
    - 01:050858 # Controller
.....

Can i do something to test UFH?

Please send me an up-to-date packet log, with restore_state: false.

But I can you, this is the most recent packet log I have (from Nov):

10:00:41.307 || CTL:050858 | HGI:141846 | RP | zone_devices     | 0000 || {'zone_idx': '00', '_device_class': '00', 'device_class': 'zone_actuators', 'devices': ['04:055514']}
10:00:41.363 || CTL:050858 | HGI:141846 | RP | zone_devices     | 0004 || {'zone_idx': '00', '_device_class': '04', 'device_class': 'sensor', 'devices': ['22:245508']}
10:00:41.700 || CTL:050858 | HGI:141846 | RP | zone_devices     | 0008 || {'zone_idx': '00', '_device_class': '08', 'device_class': 'rad_actuators', 'devices': ['04:055514']}

It tells me that 04:055594 is not bound to that zone - you shoudl try rebinding it.

Can you do this:

python client.py monitor /dev/ttyUSB0 -X scan_full 02:017205 -o scan_full_02-017205.log

What are you hoping i might achieve with an UFH controller?