Analyzing evohome RF protocol - actuator / relay demand

[zxdavb]

Using evohome_rf (https://github.com/zxdavb/evohome_rf) can give deep insights into the behavior of your system. I though I would show an example here.

Using a HGI80, or evofw3 running on a nanoCUL, you can eavesdrop RF traffic, and see packets such as (with added timestamps):

16:43:35.979 045  I --- 01:145038 --:------ 01:145038 1F09 003 FF073F
16:43:36.003 045  I --- 01:145038 --:------ 01:145038 2309 021 00079E01079E02079E03079E04079E05079E06079E
16:43:36.022 045  I --- 01:145038 --:------ 01:145038 30C9 021 0008250108790208540307B20407ED050801060854

...translated, this is (payloads truncated for readability):

16:43:35.979 || CTL:123456 |            |  I | system_sync      | FF073F   || {'remaining_seconds': 185.5, '_next_sync': '16:46:41'}
16:43:36.003 || CTL:123456 |            |  I | setpoint         | 00079... || [{'zone_idx': '00', 'setpoint': 19.5}, {'zone_idx': '01', 'setpoin...
16:43:36.022 || CTL:123456 |            |  I | temperature      | 00082... || [{'zone_idx': '00', 'temperature': 20.85}, {'zone_idx': '01', 'tem...

Here, we see that the controller announces the setpoint and current temperature of all the zones every 185.5 seconds.

You can send a request (RQ) to the controller (and other devices) and get a response (RP):

16:48:27.636 || HGI:000730 | CTL:123456 | RQ | zone_name        | 0000     || {'zone_idx': '00'}
16:48:27.665 || CTL:123456 | HGI:000730 | RP | zone_name        | 00004... || {'zone_idx': '00', 'name': 'Main room'}

So, let look at how the TPI cycle works. Firstly, there's the (currently) configured cycle rate, and the minimum on time:

16:57:12.210 || HGI:000730 | CTL:123456 | RQ | tpi_params       | FC       || {'domain_id': 'FC'}
16:57:12.229 || CTL:123456 | HGI:000730 | RP | tpi_params       | FC300... || {'domain_id': 'FC', 'cycle_rate': 12.0, 'minimum_on_time': 3.0, 'm...

The controller will tell me which device is the heater relay (e.g. combi boiler, communal HW):

16:57:12.420 || HGI:000730 | CTL:123456 | RQ | zone_devices     | 000F     || {'domain_id': 'FC', 'device_class': 'heating_control'}
16:57:12.436 || CTL:123456 | HGI:000730 | RP | zone_devices     | 000F0... || {'domain_id': 'FC', 'device_class': 'heating_control', 'devices': ['13:888888']}

...in this case, it's a BDR91A called 13:888888.

I can then ask the relay what's happening there:

17:03:35.144 || HGI:000730 | BDR:888888 | RQ | rf_bind          | 00       || {}
17:03:35.162 || BDR:888888 | HGI:000730 | RP | rf_bind          | 003EF... || [{'00': '3EF0'}, {'00': '3B00'}]

... it sends 0x3B00 (tpi_sync) and 0x3EF0 (actuator_enabled) packets to the controller.

I can ask it what the actuator_cycle is:

17:03:36.262 || HGI:000730 | BDR:888888 | RQ | actuator_cycle   | 00       || {}
17:03:36.277 || BDR:888888 | HGI:000730 | RP | actuator_cycle   | 00000... || {'actuator_enabled': True, 'actuator_countdown': 13, 'cycle_countd...

[zxdavb]

Here's the heater relay at end of a TPI cycle (I have removed the RQ, which I am sending every 15 secs):

07:03:42.508 | BDR:888888 |            |  I | actuator_sync    | {'sync_tpi': True}
07:03:42.609 | BDR:888888 | HGI:000730 | RP | actuator_cycle   | {'actuator_enabled': True, 'actuator_countdown': 1, 'cycle_countdown': 1}

... the cycle hasn't offically finished (2nd msg, 1 second to go), but the heater relay has spontaneously sent the actuator_sync (1st msg) - it does this at the end of the TPI cycle (which is cycle_countdown seconds in the future).

Next, the start of the TPI cycle, marked by the actuator_sync from the controller:

07:03:45.830 | BDR:111111 |            |  I | actuator_state   | {'actuator_enabled': False}
07:03:45.850 | CTL:123456 |            |  I | actuator_sync    | {'domain_id': 'FC', 'sync_tpi': True}
07:03:46.205 | BDR:111119 |            |  I | actuator_state   | {'actuator_enabled': False}
07:03:46.830 | BDR:111111 |            |  I | actuator_state   | {'actuator_enabled': False}

...the timings aren't clear, but I always saw the heater relay well before the controller, with all other relays sending an actuator_enabled at the same time as (more generally 'after') the controller's actuator_sync.

Next thing is the start of a cycle by the heater relay:

07:03:56.452 | BDR:888888 | HGI:000730 | RP | actuator_cycle   | {'actuator_enabled': False, 'actuator_countdown': 287, 'cycle_countdown': 587}

...you can see it is false for 300 of the 600 secs (i.e. half) of the 10 min cycle, and, 5 min later: (edited)

07:08:56.496 | BDR:888888 | HGI:000730 | RP | actuator_cycle   | {'actuator_enabled': True, 'actuator_countdown': 287, 'cycle_countdown': 287}

...you can see it has now switched to active for the remaining portion of the cycle.

So, whilst all this is going on, before the start of the above cycle:

07:01:45.994 | TRV:654321 | CTL:123456 |  I | heat_demand      | {'parent_idx': '06', 'heat_demand': 0.3}
07:02:48.942 | CTL:123456 |            |  I | relay_demand     | {'domain_id': 'FC', 'relay_demand': 0.07}
07:02:49.842 | CTL:123456 |            |  I | heat_demand      | {'domain_id': 'FC', 'heat_demand': 0.07}

...and during the above cycle:

07:05:07.434 | TRV:654322 | CTL:123456 |  I | heat_demand      | {'parent_idx': '04', 'heat_demand': 0.35}
07:05:08.163 | CTL:123456 |            |  I | relay_demand     | {'domain_id': 'FC', 'relay_demand': 0.03}
07:05:08.175 | CTL:123456 |            |  I | heat_demand      | {'domain_id': 'FC', 'heat_demand': 0.03}

...in both cases, the falling heat_demand from a zone has caused the system's overall heat_demand to drop. The relay demand decreases in line with that.

If the demand is only 7% at the start of the cycle, why did it stay on for 50% of the 10 min cycle?:

20:25:27.744 | CTL:123456 |            |  I | tpi_params       | {'domain_id': 'FC', 'cycle_rate': 6.0, 'minimum_on_time': 5.0, 'minimum_off_time': 0.0, 'proportional_band_width': None}

This says: 6 cycles per hour (so 10 min each), minimum on time 5 mins (NB: 6.5 mins would be OK - it's not only 0, 5 or 10).

[zxdavb]

This is a specific example that exceeds the minimum duty cycle.

With a cycle rate of 3 per hour (so 1,200 seconds per cycle):

20:13:44.331 || BDR:888888 | HGI:000730 | RP | relay_demand     | 0026     || {'relay_demand': 0.19}
20:13:44.376 || BDR:888888 | HGI:000730 | RP | actuator_cycle   | 0004B... || {'actuator_enabled': False, 'actuator_countdown': 972, 'cycle_countdown': 1200}

... a demand of 19% results in a actuator_countdown of 972/1200 = 0.81, or 81% disabled (False) -> 19% enabled

20:49:47.236 || BDR:888888 | HGI:000730 | RP | actuator_cycle   | 0000E... || {'actuator_enabled': False, 'actuator_countdown': 9, 'cycle_countdown': 237}
20:50:02.229 || BDR:888888 | HGI:000730 | RP | actuator_cycle   | 0000D... || {'actuator_enabled': True, 'actuator_countdown': 222, 'cycle_countdown': 222}

... and between 237 and 222 it switches from False to True, as expected for a relay_demand of 19% (19% of 1200 is 228).

Here, I changed the setpoint on Zone 4 via the controller:

21:23:25.185 || CTL:123456 |            |  I | setpoint         | 0408CA   || [{'zone_idx': '04', 'setpoint': 22.5}]
21:23:35.083 || BDR:888888 | HGI:000730 | RP | relay_demand     | 0000     || {'relay_demand': 0.0}
21:23:35.125 || BDR:888888 | HGI:000730 | RP | actuator_cycle   | 00026... || {'actuator_enabled': False, 'actuator_countdown': 611, 'cycle_countdown': 611}
21:24:44.228 || CTL:123456 |            |  I | system_sync      | FF073F   || {'remaining_seconds': 185.5, '_next_sync': '21:27:49'}
21:24:44.274 || CTL:123456 |            |  I | setpoint         | 00083... || [{'zone_idx': '00', 'setpoint': 21.0}, {'zone_idx': '01', 'setpoint': 21.0}, {'zone_idx': '02', 'setpoint': 21.0}, {'zone_idx': '03', 'setpoint': 21.0}, {'zone_idx': '04', 'setpoint': 22.5}, {'zone_idx': '05', 'setpoint': 21.0}, {'zone_idx': '06', 'setpoint': 21.0}]
21:24:44.275 || CTL:123456 |            |  I | temperature      | 00098... || [{'zone_idx': '00', 'temperature': 24.44}, {'zone_idx': '01', 'temperature': 21.45}, {'zone_idx': '02', 'temperature': 22.21}, {'zone_idx': '03', 'temperature': 19.91}, {'zone_idx': '04', 'temperature': 20.64}, {'zone_idx': '05', 'temperature': 21.25}, {'zone_idx': '06', 'temperature': 21.65}]

Not much happened, whihc we might expect in the middle of a TPI cycle:

21:25:05.062 || BDR:888888 | HGI:000730 | RP | relay_demand     | 0000     || {'relay_demand': 0.0}
21:25:05.109 || BDR:888888 | HGI:000730 | RP | actuator_cycle   | 00020... || {'actuator_enabled': False, 'actuator_countdown': 521, 'cycle_countdown': 521}

However, the demand jumps a shortly after:

21:25:07.228 || CTL:123456 |            |  I | relay_demand     | F9C8     || {'domain_id': 'F9', 'relay_demand': 1.0}
21:25:07.738 || BDR:123123 |            |  I | actuator_state   | 00C8FF   || {'actuator_enabled': True}
21:25:08.243 || CTL:123456 |            |  I | relay_demand     | FCC8     || {'domain_id': 'FC', 'relay_demand': 1.0}
21:25:08.244 || CTL:123456 |            |  I | heat_demand      | FCC8     || {'domain_id': 'FC', 'heat_demand': 1.0}
21:25:08.658 || BDR:888888 |            |  I | actuator_state   | 00C8FF   || {'actuator_enabled': True}

And there we go - the actuator state can go from off to on in the middle of an actuator_cycle:

21:25:20.066 || BDR:888888 | HGI:000730 | RP | relay_demand     | 00C8     || {'relay_demand': 1.0}
21:25:20.112 || BDR:888888 | HGI:000730 | RP | actuator_cycle   | 0001F... || {'actuator_enabled': True, 'actuator_countdown': 506, 'cycle_countdown': 506}