Using evohome_rf (https://github.com/zxdavb/evohome_rf), you can eavesdrop RF traffic, and - by sending crafted RQ packets, get deep insights into your system.
This is about performing a site-survery using a HGI80, or evofw3 (https://github.com/ghoti57/evofw3) running on a nanoCUL.
I know of no way to 'discover' the controller (if you can't just get its address from the controller UI), but it will send a sync packet every 3 minutes or so:
Code:
01:09:36.167 || CTL:777777 | | I | system_sync | FF073F || {'remaining_seconds': 185.5, '_next_sync': '01:12:41'}
Once you've got the address of a controller, you can ask it the address of the heater control (FC) relay & it's configuration:
Code:
01:21:54.873 || HGI:999999 | CTL:777777 | RQ | zone_devices | 000F || {'domain_id': 'FC', 'device_class': 'heating_control'}
01:21:54.899 || CTL:777777 | HGI:999999 | RP | zone_devices | 000F0... || {'domain_id': 'FC', 'device_class': 'heating_control', 'devices': ['13:111111']}
01:21:54.931 || HGI:999999 | CTL:777777 | RQ | tpi_params | FC || {'domain_id': 'FC'}
01:21:54.958 || CTL:777777 | HGI:999999 | RP | tpi_params | FC241... || {'domain_id': 'FC', 'cycle_rate': 9.0, 'minimum_on_time': 5.0, 'minimum_off_time': 0.0, 'proportional_band_width': None}
...here, it's a BDR91A (TPI doesn't apply to OpenTherm Bridges, which have addresses started with 10: ).
What about the configuration of the stored hotwater (FA), if any (from now, I will remove the `RQ` packets for readability):
Code:
01:21:56.321 || CTL:777777 | HGI:999999 | RP | zone_devices | 000D0... || {'domain_id': 'FA', 'device_class': 'hotwater_sensor', 'devices': ['07:123456']}
01:21:56.379 || CTL:777777 | HGI:999999 | RP | zone_devices | 000E0... || {'domain_id': 'FA', 'device_class': 'hotwater_valve', 'devices': ['13:222222']}
01:21:56.436 || CTL:777777 | HGI:999999 | RP | zone_devices | 010E0... || {'domain_id': 'F9', 'device_class': 'heating_valve', 'devices': ['13:333333']}
And the configuration and status of the stored hotwater:
Code:
01:21:56.494661 || CTL:777777 | HGI:999999 | RP | dhw_params | 00138... || {'setpoint': 50.0, 'overrun': 0, 'differential': 10.0}
01:21:56.599318 || CTL:777777 | HGI:999999 | RP | dhw_mode | 00000... || {'active': False, 'dhw_mode': 'follow_schedule', 'until': None}
01:21:56.742529 || CTL:777777 | HGI:999999 | RP | dhw_temp | 000931 || {'temperature': 23.53}
You can also ask the controller how many zones are configured:
Code:
01:13:11.068 || HGI:999999 | CTL:777777 | RQ | system_zones | 0000 || {'zone_type': 'configured_zones'}
01:13:11.084 || CTL:777777 | HGI:999999 | RP | system_zones | 00007... || {'zone_mask': [1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0], 'zone_type': 'configured_zones'}
...this says there are 8 zones.
I wonder how many zones of each type there are:
Code:
01:14:58.205 || CTL:777777 | HGI:999999 | RP | system_zones | 00087... || {'zone_mask': [1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0], 'zone_type': 'radiator_valve'}
01:14:58.253 || CTL:777777 | HGI:999999 | RP | system_zones | 00090... || {'zone_mask': [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], 'zone_type': 'underfloor_heating'}
01:14:58.301 || CTL:777777 | HGI:999999 | RP | system_zones | 000A0... || {'zone_mask': [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], 'zone_type': 'zone_valve'}
01:14:58.348 || CTL:777777 | HGI:999999 | RP | system_zones | 000B0... || {'zone_mask': [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], 'zone_type': 'mixing_valve'}
01:14:58.396 || CTL:777777 | HGI:999999 | RP | system_zones | 00110... || {'zone_mask': [0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0], 'zone_type': 'electric_heat'}
... the last packet tells me that the 8th zone is an electric heat type.
You can get the sensor, the actuators, and the configuration & status of a zone:
Code:
01:33:45.242896 || CTL:777777 | HGI:999999 | RP | zone_devices | 01000... || {'zone_idx': '01', 'device_class': 'zone_actuators', 'devices': ['04:123456', '04:123457']}
01:33:45.301588 || CTL:777777 | HGI:999999 | RP | zone_devices | 01040... || {'zone_idx': '01', 'device_class': 'sensor', 'devices': ['34:123456']}
01:33:45.370201 || CTL:777777 | HGI:999999 | RP | zone_name | 01004... || {'zone_idx': '01', 'name': 'Lounge'}
01:33:45.428955 || CTL:777777 | HGI:999999 | RP | zone_params | 01100... || {'zone_idx': '01', 'min_temp': 5.0, 'max_temp': 35.0, 'local_override': True, 'openwindow_function': True, 'multiroom_mode': False}
01:33:45.486836 || CTL:777777 | HGI:999999 | RP | zone_mode | 0105D... || {'zone_idx': '01', 'mode': 'follow_schedule', 'setpoint': 15.0}
01:33:46.776924 || CTL:777777 | HGI:999999 | RP | temperature | 01086A || {'zone_idx': '01', 'temperature': 21.54}
You can puzzle UFH controllers too, for example:
Code:
13:56:13.072 || UFC:333333 | HGI:999999 | RP | device_info | 00000... || {'description': 'HCE80 V3.10 061117', 'firmware': None, 'manufactured': '2017-11-06'}
13:56:14.336 || UFC:333333 | HGI:999999 | RP | zone_devices | 00090... || {'ufh_idx': '00', 'zone_id': '01', 'device_class': 'ufh_actuators', 'devices': ['01:333333']}
13:56:14.558 || UFC:333333 | HGI:999999 | RP | zone_devices | 01090... || {'ufh_idx': '01', 'zone_id': '05', 'device_class': 'ufh_actuators', 'devices': ['01:333333']}
13:56:14.692 || UFC:333333 | HGI:999999 | RP | zone_devices | 01090... || {'ufh_idx': '02', 'zone_id': '03', 'device_class': 'ufh_actuators', 'devices': ['01:333333']}
13:56:18.756 || UFC:333333 | HGI:999999 | RP | zone_devices | 04097... || {'ufh_idx': '03', 'zone_id': None, 'device_class': 'ufh_actuators', 'devices': []}
...
... above, you get the mappings between an UFH curcuit (loop) and the corresponding evohome zone.
This is useful, as the UFH controller will send heat demand for each UFH circuit.
Code:
19:33:32.089 || UFC:333333 | | I | heat_demand | FC8C || {'domain_id': 'FC', 'heat_demand': 0.7}
19:35:54.717 || UFC:333333 | | I | heat_demand | 008C0... || [{'ufh_idx': '00', 'heat_demand': 0.7}, {'ufh_idx': '01', 'heat_demand': 0.0}, {'ufh_idx': '02', 'heat_demand': 0.64}]
... it seems the overall sent demand from the UFH controller to the evohome controller is the highest of all demands - but the controller can use the second packet if it wishes..
You can pull the controller's fault logs, and zone schedules too.