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

Share your Projects!
2994

Hi David,
I have several sensors who are always unavailable. In fact these were never available. Thatbis why in previous posts i suspected these where not relayed by my ems-ot converter. Does a log help in this case?

2995

Hi all,

I recently purchased a device to monitor the evohome RF traffic. All good, installed with evofw3 and (I think so) configured with ramses-cc and ramses-rf, latest versions from github. I now see a lot of traffic between devices of evohome which is good.

However, there are several sensors, in particular those related to opentherm, that are unavailable and cannot be read.

I was looking at the packet log and what I can notice if my understanding is good of the code is that my 18: device (which is the USB RF stick) is asking the OTH bridge 10: device for information but the OTH device never responds. Similarly, I see these type of requests being made to the controller. Obviously it never responds back.

Only when the controller asks the OTH for information, the OTH responds and with limited data as it’s clearly based on what is requested.

I can imagine that the OTH is linked to the controller so my question would be: is this intended behaviour? If so, what would be the reason for the 18: device to ask for information if there will never be a response back?

Example of comm between controller and OTH:
2022-10-15T10:15:41.434772 079 RQ — 01:256364 10:056759 --:------ 3EF0 001 00
2022-10-15T10:15:41.460491 076 RP — 10:056759 01:256364 --:------ 3EF0 009 000010020000032600

and then when the usb device 18: asks for information:
2022-10-15T00:51:41.529359 000 RQ — 18:141092 10:056759 --:------ 3EF0 001 00
of course with no RP.

2996

Regardless of my following comments, this is common & rather expected.

  • ramses_rf knows what sensors the OTB might/maybe support (e.g. CV pressure/DHW flow rate), and what it must support (e.g. boiler temp)
  • it doesn’t know which of the maybes are supported until it asks - if they aren’t supported you’ll see that metric deprecated in the HA even log
  • however, the sensor entity still exists in HA (and is now unavailable) - you’ll be expected to disable it

However, from what you describe the gateway can listen OK, but not transmit correctly, or maybe it is a simple issue with weak reception (my instinct is to doubt this - but I would be more sure if I saw a packet log).

The above does not guarantee the packet was Tx successfully, only that it is valid.

In summary, this appears to be an issue with the gateway, perhaps you didn’t use the correct board type when you loaded evofw3? You didn’t say where you got the device from. If it’s an SSM-D, it would benefit from tuning.

2997

Hi David - thanks for your response.

I understand now re the sensors.

I think the only part that isn’t that clear is the bi-directional communication which to me doesn’t seem to be working (unless it shouldn’t).

To provide some background information:

I can see traffic in and from the controller to all it’s devices (with minor exceptions for UFH and a BDR zone valve - but this is a separate conversation). As per previously, I can see message requests from the nanoCUL to all the other devices but they never respond. I plugged the nanoCUL into my laptop and ran serial monitor, sent the commands myself - same behavior - no response. Now I’m not sure if a response should be received …

Extract from the latest log:
2022-10-15T15:48:48.525120 000 RQ — 18:141092 10:056759 --:------ 3220 005 0000000000
2022-10-15T15:48:49.757290 000 RQ — 18:141092 01:256364 --:------ 12B0 001 00
2022-10-15T15:48:50.395977 000 RQ — 18:141092 01:256364 --:------ 000C 002 000D
2022-10-15T15:48:51.306001 000 RQ — 18:141092 01:256364 --:------ 12B0 001 01
2022-10-15T15:48:52.430969 000 RQ — 18:141092 10:056759 --:------ 3220 005 0000050000

2022-10-15T15:48:52.947189 079 RQ — 01:256364 10:056759 --:------ 3EF0 001 00
2022-10-15T15:48:52.969646 077 RP — 10:056759 01:256364 --:------ 3EF0 009 000010000000020A64

2022-10-15T15:48:53.660755 000 RQ — 18:141092 01:256364 --:------ 0005 002 0008
2022-10-15T15:48:54.303284 000 RQ — 18:141092 01:256364 --:------ 12B0 001 02
2022-10-15T15:48:55.211523 000 RQ — 18:141092 01:256364 --:------ 12B0 001 03
2022-10-15T15:48:56.337429 000 RQ — 18:141092 10:056759 --:------ 3220 005 0080730000
2022-10-15T15:48:57.566484 000 RQ — 18:141092 01:256364 --:------ 12B0 001 00
2022-10-15T15:48:58.209043 000 RQ — 18:141092 01:256364 --:------ 0005 002 0009
2022-10-15T15:48:59.117390 000 RQ — 18:141092 01:256364 --:------ 12B0 001 01
2022-10-15T15:49:00.031034 000 RQ — 18:141092 10:056759 --:------ 2401 001 00
2022-10-15T15:49:00.941240 000 RQ — 18:141092 01:256364 --:------ 12B0 001 04
2022-10-15T15:49:01.907017 000 RQ — 18:141092 01:256364 --:------ 0005 002 000A
2022-10-15T15:49:02.817176 000 RQ — 18:141092 01:256364 --:------ 12B0 001 02
2022-10-15T15:49:03.728092 000 RQ — 18:141092 10:056759 --:------ 10A0 001 00

— parsed

15:48:48.525 || HGI:141092 | OTB:056759 | RQ | opentherm_msg | 00 || {‘msg_id’: 0, ‘msg_type’: ‘Read-Data’, ‘msg_name’: ‘status_flags’, ‘description’: ‘Status’}
15:48:49.757 || HGI:141092 | CTL:256364 | RQ | window_state | 00 || {}
15:48:50.395 || HGI:141092 | CTL:256364 | RQ | zone_devices | 000D || {‘zone_type’: ‘0D’, ‘domain_id’: ‘FA’, ‘device_role’: ‘dhw_sensor’}
15:48:51.306 || HGI:141092 | CTL:256364 | RQ | window_state | 01 || {}
15:48:52.430 || HGI:141092 | OTB:056759 | RQ | opentherm_msg | 05 || {‘msg_id’: 5, ‘msg_type’: ‘Read-Data’, ‘msg_name’: ‘fault_flags’, ‘description’: ‘Fault flags & OEM fault code’}

15:48:52.947 || CTL:256364 | OTB:056759 | RQ | actuator_state | || {}
15:48:52.969 || OTB:056759 | CTL:256364 | RP | actuator_state | || {‘modulation_level’: 0.0, ‘_flags_2’: ‘10’, ‘_flags_3’: [0, 0, 0, 0, 0, 0, 0, 0], ‘ch_active’: False, ‘dhw_active’: False, ‘flame_active’: False, ‘_unknown_4’: ‘00’, ‘_unknown_5’: ‘00’, ‘_flags_6’: [0, 0, 0, 0, 0, 0, 1, 0], ‘ch_enabled’: False, ‘ch_setpoint’: 10, ‘max_rel_modulation’: 1.0}

15:48:53.660 || HGI:141092 | CTL:256364 | RQ | system_zones | 0008 || {‘zone_type’: ‘08’, ‘zone_class’: ‘rad_actuator’}
15:48:54.303 || HGI:141092 | CTL:256364 | RQ | window_state | 02 || {}
15:48:55.211 || HGI:141092 | CTL:256364 | RQ | window_state | 03 || {}
15:48:56.337 || HGI:141092 | OTB:056759 | RQ | opentherm_msg | 73 || {‘msg_id’: 115, ‘msg_type’: ‘Read-Data’, ‘msg_name’: ‘OEMDiagnosticCode’, ‘description’: ‘OEM diagnostic code’}
15:48:57.566 || HGI:141092 | CTL:256364 | RQ | window_state | 00 || {}
15:48:58.209 || HGI:141092 | CTL:256364 | RQ | system_zones | 0009 || {‘zone_type’: ‘09’, ‘zone_class’: ‘ufh_actuator’}
15:48:59.117 || HGI:141092 | CTL:256364 | RQ | window_state | 01 || {}
15:49:00.031 || HGI:141092 | OTB:056759 | RQ | message_2401 | || {}
15:49:00.941 || HGI:141092 | CTL:256364 | RQ | window_state | 04 || {}
15:49:01.907 || HGI:141092 | CTL:256364 | RQ | system_zones | 000A || {‘zone_type’: ‘0A’, ‘zone_class’: ‘val_actuator’}
15:49:02.817 || HGI:141092 | CTL:256364 | RQ | window_state | 02 || {}
15:49:03.728 || HGI:141092 | OTB:056759 | RQ | dhw_params | || {}

2998

I had today the same with Some zones, after a restart of ha they came available again.

2999

I am sorry, I wasn’t clear: The bi-directional communication should work.

ramses_rf will ask (RQ) some questions:
a) it expects to always get a valid answer for (these are the majority, fro example, all those sent to a controller)
b) it knows it may or may not get a valid answer for (e.g. depending upon your specific HW)
c) it knows it will not get a response at all

… it tracks b) & c) & stops asking those questions if so.

Your system appears to be full of a) - this is a problem with the USB dongle, somewhere.

Please be aware - the packet may not be transmitted at all (which is why you’re getting no responses), or it is, but you’re not receiving the responses.

  • you can test which by asking the controller to change something via the web UI

The socat utility is not officially supported, but should work.

For troubleshooting, it will help you to know that all RQ pkts sent to a controller should be getting a corresponding RP.

Please post a copy of your configuration.

3000

Thanks. Now I understand.

Looking at the packet logs I posted - some requests are sent to the controller and I don’t get any response back. I searched through the logs and none of the requests to the controller received responses so clearly something is wrong.

As for the configuration - this is what I currently have (the name element does not get through) - apologies but I can only send screenshot now as I don’t have my laptop with me. I hope they will get uploaded and attached to my reply.

image
image1289×2221 259 KB

image
image1290×2209 264 KB

image
image1290×2142 287 KB

3001

In the wiki, it says:

The general rule with schemas is to always have the minimum schema that works.

When you get the dongle transmitting, it is likely that your schema can be restricted to appliance_control:

01:256364:
  system:
    appliance_control: 10:056759
known_list:
  ...
3002

@trailro

Maybe this will help: Hardware Platforms ¡ ghoti57/evofw3 Wiki (github.com)

3003

Thanks. Just to confirm - are you suggesting I try removing the configuration and leaving just the main system (without the appliance control) to see if it can communicate both ways?

Would this not be the same with just plugging the device in the pc and serial (so no ramses included) and issuing commands with no response?

My conclusion so far would be that the device is not working unless I am interpreting this wrong?

3004

The dongle is not working properly. It is not transmitting.

If it was functioning properly, you wouldn’t need the schema you have, you would (almost certainly) be able to get away with the schema I suggested.

When you get it working, use the schema I provided.

3005

Hi all and thanks adagin David for this excelent project!

Is there any way I can distinguish a temp override which was actioned by change at the TRV rather than from Home Assistant? I’d like to beable to reset an overide a the TRV after a delay but avoid this if (say) an automation does it.

3006

Could you do this by setting a variable in HA if an automation sets an override, and then testing against this before clearing?

3007

Afternoon - so a bit of an update.

Did a lot of testing and trial & error. I am currently in the current state:
1/ Flashed evofw3 branch calibrate on to the device
2/ Seems that I can now talk to most devices (for example OTH responds to almost all commands every single time).
3/ Unfortunately, the only device I can’t communicate to is the Controller - it responds only to occasional requests. It does respond to all other devices but my device.
4/ As a consequence, by schema is never populated now using the minimum configuration suggested.

Some examples:

working:
2022-10-16T15:07:49.674339 000 RQ — 18:141092 10:056759 --:------ 3200 001 00
2022-10-16T15:07:49.696398 077 RP — 10:056759 18:141092 --:------ 3200 003 000CA8

working:
2022-10-16T15:06:34.207367 000 RQ — 18:141092 13:249574 --:------ 3EF1 001 00
2022-10-16T15:06:34.222543 094 RP — 13:249574 18:141092 --:------ 3EF1 007 0004AF04AF00FF

working - and this is strange:
2022-10-16T13:10:54.840625 000 RQ — 18:141092 01:256364 --:------ 000C 002 0104
2022-10-16T13:10:54.857500 069 RP — 01:256364 18:141092 --:------ 000C 006 010400116B20

not working or never getting a response back:
2022-10-16T13:58:19.016661 000 RQ — 18:141092 01:256364 --:------ 1100 001 FC
2022-10-16T13:58:19.246415 000 RQ — 18:141092 01:256364 --:------ 2349 002 0900
2022-10-16T13:58:20.842374 000 RQ — 18:141092 01:256364 --:------ 000C 002 0009

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?)