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

Share your Projects!
3008

Just finished testing the idea that @zxdavb outlined to persuade the HCE80 to switch the MT4 motors to open the valve of an ufh circuit (I have the NC-version):

This would also switch on the circulation pump of the ufh distributor in my case, since it is connected to the auxiliary relay contact of the MT4.

@bishop: based on the packet log @zxdavb provided and my own logs, I get the impression that the communication between evohome and the HCE80 works slightly different than you have described here:

In my understanding (when all devices have been bound to evohome, in my case):

  • Evohome (CTL) receives/sets a setpoint higher than the current sensor temperature
  • Evohome ‘broadcasts’ the setpoint, which is picked up by the HCE80 (is that right? no receiver listed in the packet log).
  • The HCE80 determines the heat_demand for the UFH circuit and sends this back to evohome, which in turn calls for heat to the boiler through the OTB.

The procedure that I followed to implement the idea of @zxdavb:

  • put evohome in ‘heat-off’-mode. (command: “W 01:123465 2E04 01FFFFFFFFFFFF00”)
  • request the current setpoint of the zone from the HCE80 (command, f.e. zone 5: “RQ 02:123456 2309 04”).
  • write the same setpoint back to the HCE80 to trigger it to send a code 22C9-packet with the current ‘temp_low’ (the setpoint) and ‘temp_high’ values (command, e.g. current setpoint is 16.5 degrees: “W 02:123456 2309 040672”)
  • write the ‘temp_high’ value back to the HCE80 as the ‘setpoint’ for this zone. This will trigger a ‘heat_demand’ of 1.0 (100%) for that zone in the HCE80 and switch on the relay controlling the valve of the ufh circuits in question (the goal). This is not the normal way for evohome to communicate the setpoint (normally done via an ‘I’-packet as a broadcast), but will be picked-up by the HCE80 (command, e.g. for zone 5 to a setpoint of 26 degrees, which is also the current temp_high: “W 02:123456 2309 040A28”)
  • Set the evohome controller back to ‘auto’ mode when done (command: “W 01:123465 2E04 00FFFFFFFFFFFF00”

The result is that the HCE80 switches the motors controlling the valves of the designated circuits, without evohome responding to the heat_demand sent by the HCE80(!). It stays it this state until evohome sends the system_sync packet (code 1F09) and the subsequent setpoints (code 2309) and temperatures (code 3C09) for all zones. In response, the HCE80 takes over these setpoints and returns to the original state without any heat_demand.

The idea clearly works for the duration of one sync cycle, so it should to possible to make a script that waits for the next sync cycle and immediately overwrites the setpoints of the HCE80 again (for a desired number of times). I’ll try to make something based on the existing scripts in discovery.py from the ramses_rf repo.

If there are any ideas to improve the routine, let me know.

3009

Whatever your problem is, this isn’t the solution - use the latest release. Try to retune or consider raising an issue at the evofw3 repo.

094 is very high - suggesting poor reception (anything above 70 may be suspect), you can try sending:

RQ 01:256384 0016 00

… that will give you an idea of the quality of the signal received by the controller.

3010

Sorry I mislead you but nice that you managed to do this anyway. I will have to check the packets I get from my UFH once I restart the heating to see if mine behave the same way.

3011

@vunix: Good work!

We could implement this as a service call in HA.

I may be ‘safer’ (and simpler) to do a temporary change to away mode. The evohome UI only allows you to do this for a set number of days (until midnight of that day), but there is no reason why it couldn’t be for (say) 15 mins - this just isn’t exposed to HA (it is available in ramses_rf though) - as a start, have a look at set_system_mode() in command.py.

Then you don’t have to send it back, or worry that the controller missed the packet requesting it is set bac.

Notably: I’ve never sent a W|2309 to a UFC, but I suspect the idx (04, in the example above) is a circuit number, and not a zone_idx (when you speak to a controller, it’s a zone_idx)

Can you not get away with just having a target setpoint of 35C? It would be much simpler (only one packet to send) - I am sure the 22C9 is not needed.

The beauty is, nothing to do, just wait for the next 1F09… Only one packet for the controller, and one for each circuit you want pumping.

Only problem is these 1F09 sync cycles are every 2-5 mins (it varies, but is a constant per controller: mine is 185.5 seconds), and you want to have the above persist for at least 5 mins, so probably at least a couple of cycles - says: repeat sending the 2309 pkts every 30s for 5 mins.

3012

A UFH circuit is much like a TRV - is is an actuator.

3013

Question: I have a somewhat convoluted setup for the USB radio. This occasionally leads to USB errors and the radio hanging. I can catch the error and reset the stick using usbreset, but then need to reload ramses_cc for the integration to pickup the freshly reset stick and start the packet sequence again. Is there a way to reload the integration without having to restart HA completely?

I have automation to trigger on the following log entry, just don’t want to restart the whole thing:

File "/srv/homeassistant/lib/python3.10/site-packages/serial/serialposix.py", line 595, in read
serial.serialutil.SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?)
3014

I have a EMS bus gateway that I’m willing to give away.

It is the older ESP8266 version, running the older firmware. I’m told it can be upgraded with a ESP32 chip relatively easily:

If you’re interested, PM me: all I ask is for someone to consider paying for postage.

3015

I’m trying to fake a sensor for an existing zone with an hr92, I have already 1 zone with a fake sensor for a fee years but don’t remember how i did it.

I’m in the zone and have tried the button temperature sensor and then Remote sensor, pressed then the call fake device service in ha, but that pairs nothing. Did the same with rf device button and no succes eighter. Is this good of do I have to delete the zone and and the hr92 and a fake temp sensor?

3016

Have you read here: Create new page · zxdavb/ramses_cc Wiki · GitHub

If the answer isn’t in there - let me know.

The other option is: there is a bug in the code, so perhaps:

  • let us know what version of ramses_cc you’re using
  • someone else could try faking a sensor (with that version) too - if two people report difficulty, then I’ll have a look
3017

Yes I read that, but the evohome part is not in it so maybe I do something wrong there.
I’m using 0.21.5 and this code:


service: ramses_cc.fake_device
data:
  device_id: "03:256006"

Edit: saw in the wiki that i need to add the new id firts to the know list, but still no luck.
But then I get this in the log: The device id does not exist: 03:256006

Deleting zone didn’t help, hopefully my schema is still good.

3018

Found in this topic the how to for facking, this is What I did, and that is not working with the new id what I’m using in the know list.

3019

Tried it with the known list disabled but stil not working and this fault in the log:
The device id does not exist: 03:256006

So i think i tried now everything, mabe someone else can try it?
but looks like a bug.

3020

Post the ramses_cc: section of your configuration.yaml

3021

Should it not be

data:
  device_id: "03:999999"
  create_device: true
3022

This is my configuration.yaml

ramses_cc:
  scan_interval: 60
  restore_cache:
    restore_schema: true
    restore_state:  true
  serial_port: /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0
  packet_log: 
    file_name: packet.log
    rotate_backups: 7
  ramses_rf:
    enforce_known_list: true
  01:155341: {}
#    system:
#      appliance_control: 13:189740
  known_list:
    01:155341:                # Controller
    04:008512:
    04:070150:
    04:070154:
    04:070160:
    04:073460:
    04:108167:
    04:108169:
    04:108171:
    04:108173:
    13:189740:                # BDR91 Ketel
    18:203293: {class: HGI}   # nanoCUL
    03:256005: {faked: true}  # BME680 Kantoor
#    03:256006:
3023

shall try it tommorrow
is start_binding also needed?
a few years ago both where not needed.

3024

Oke, i have it working now, first indeed you need te create the device with the code:

service: ramses_cc.fake_device
data:
  device_id: "03:256006"
  create_device: true

The you set your evohome in pairing mode for the remote sensor, and than you send the start pairing code:

service: ramses_cc.fake_device
data:
  device_id: "03:256006"
  start_binding: true

on the evohome screen you now see a succesfull pair message.

After that i changed my configuration.yaml know list with the new sensor

known_list:
    03:256006: {faked: true}

The did a reboot, but schema was not updated so i could not use the service ramses_cc.put_zone_temp, as stated in the wiki i then changed:

ramses_cc:
  restore_cache: false

After a reboot schema was still not updated, so changed:

ramses_cc:
  restore_cache: false
  restore_schema: false

After a reboot now the schema was good and i could use the service ramses_cc.put_zone_temp

1 Like
3025

I guess you were looking at the wiki, after the edits I made last night?

It is still a WIP - I wonder if you have identified a typo - I will check it.

Don’t forget to put this back:

ramses_cc:
  restore_cache: true

or:

ramses_cc:
  restore_cache: 
    restore_schema: true
    restore_state: true
3026

Yes, already done that.
But i had this in my config:

ramses_cc:
  restore_cache: 
    restore_schema: true
    restore_state: true

So i changed first state to false, i see now what is in the wiki is for both so that was my bad.

Indeed i did read the updated wiki, maybe the creating and binding is a good addition to it.

1 Like
3027

Actually, thinking about your experience, and the number of HA restarts needed, I am going to change a few things around to improve the UX.

Sensor faking is one of the highlights of ramses_cc - so we want it to be easy.