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

DanRP · February 25, 2021, 10:13pm

Got it, hopefully the link I just shared works.

zxdavb · February 26, 2021, 9:39pm

@DanRP I have tweaked the code for the OpenTherm Gateway - When I release the next version of evohome_cc, I would like another packet log - the idea is to expose some OT data to HA.

DanRP · February 26, 2021, 10:02pm

No problem, more than happy to help and to continue doing so.

zxdavb · February 26, 2021, 10:58pm

@sOckhamSter

I hope you don’t mind me posting this here…

(everyone needs to know I’m using a version of the library that hasn’t been released yet)

Note the RQ, followed by a corresponding RP - note the error message between the two, which belongs to the RP

08:09:35.186 || HGI:004656 | CTL:073765 | RQ | zone_devices     | 0704     || {'zone_idx': '07', 'device_class': 'sensor'}
08:09:35.202 045 RP --- 01:073765 18:004656 --:------ 000C 006 07040010E939 < Inconsistent state: Device 04:059705 (TRV) is claimed by multiple parent zones: old=01:073765_00 (RAD), new=01:073765_07 (RAD) (try restarting the client library)
08:09:35.202 || CTL:073765 | HGI:004656 | RP | zone_devices     | 07040... || {'zone_idx': '07', 'device_class': 'sensor', 'devices': ['04:059705']}

…and…

08:09:35.559 || HGI:004656 | CTL:073765 | RQ | zone_devices     | 0708     || {'zone_idx': '07', 'device_class': 'rad_actuators'}
08:09:35.580 045 RP --- 01:073765 18:004656 --:------ 000C 012 07080010749E07080010E939 < Inconsistent state: Device 04:029854 (TRV) is claimed by multiple parent zones: old=01:073765_00 (RAD), new=01:073765_07 (RAD) (try restarting the client library)
08:09:35.580 || CTL:073765 | HGI:004656 | RP | zone_devices     | 07080... || {'zone_idx': '07', 'device_class': 'rad_actuators', 'devices': ['04:029854', '04:059705']}

zxdavb · February 26, 2021, 11:24pm

In this case, I think zone 00 is configured wrong:

    "zones": {
        "00": {
            "heating_type": "radiator_valve",
            "sensor": "04:029854",
            "devices": [
                "04:059705",
                "04:029854"
            ]
        },

… 04:059705 shouldn’t be a child of this zone!

iMiMx · February 27, 2021, 8:23am

I have one zone, zone 00:

      "00":{
         "name":"Living Room",
         "mode":{
            "mode":"follow_schedule",
            "setpoint":18.0
         },
         "config":{
            "min_temp":5.0,
            "max_temp":35.0,
            "local_override":true,
            "openwindow_function":true,
            "multiroom_mode":false
         }
      },

Which has 2 TRVs:

   "04:055514":{
         "temperature":21.78,
         "setpoint":"None",
         "battery_state":"None",
         "enabled":false,
         "heat_demand":0.0,
         "window_state":"None"
      },
      "04:055594":{
         "temperature":22.31,
         "setpoint":"None",
         "battery_state":"None",
         "enabled":false,
         "heat_demand":0.0,
         "window_state":"None"
      },

And a wall-mounted thermostat (it hadn’t sniffed at this point after a restart, but it does usually/eventually)

      "22:245508":{
         "temperature":"None",
         "setpoint":"None",
         "battery_state":"None"
      },

I noticed that one of the TRVs appears as an ophan in the schema, but it does seem to be activated/controlled by the Evohome controller.

Initially I thought a binding problem, but if the controller manages to switch it on/off at the same time as the other in the zone, it would perhaps suggest not?

   "orphans":[
      "04:055514",
   ],

In the start-up, it only shows 594 TRV being attached to zone 00:

2021-02-27 07:57:55 INFO (MainThread) [custom_components.evohome_cc.climate] Found a Controller, id=01:050858
2021-02-27 07:57:55 INFO (MainThread) [custom_components.evohome_cc.climate] Found a Zone (radiator_valve), id=00, name=Living Room
2021-02-27 07:57:55 INFO (MainThread) [custom_components.evohome_cc.climate] Found a Zone (radiator_valve), id=01, name=Front Room
2021-02-27 07:57:55 INFO (MainThread) [custom_components.evohome_cc.climate] Found a Zone (radiator_valve), id=02, name=Utility
2021-02-27 07:57:55 INFO (MainThread) [custom_components.evohome_cc.climate] Found a Zone (radiator_valve), id=03, name=Guest Bed
2021-02-27 07:57:55 INFO (MainThread) [custom_components.evohome_cc.climate] Found a Zone (radiator_valve), id=04, name=Master Bed
2021-02-27 07:57:55 INFO (MainThread) [custom_components.evohome_cc.climate] Found a Zone (radiator_valve), id=05, name=Office 1
2021-02-27 07:57:55 INFO (MainThread) [custom_components.evohome_cc.climate] Found a Zone (radiator_valve), id=06, name=Office 2
2021-02-27 07:57:55 INFO (MainThread) [custom_components.evohome_cc.climate] Found a Zone (radiator_valve), id=07, name=Hallway
2021-02-27 07:57:55 INFO (MainThread) [custom_components.evohome_cc.water_heater] Found a Water Heater (stored DHW), id=HW, name=Stored HW
2021-02-27 07:57:55 INFO (MainThread) [custom_components.evohome_cc.sensor] Found a Sensor (heat demand), id=04:055594, zone=00
2021-02-27 07:57:55 INFO (MainThread) [custom_components.evohome_cc.sensor] Found a Sensor (heat demand), id=04:055596, zone=01
2021-02-27 07:57:55 INFO (MainThread) [custom_components.evohome_cc.sensor] Found a Sensor (heat demand), id=04:055510, zone=02
2021-02-27 07:57:55 INFO (MainThread) [custom_components.evohome_cc.sensor] Found a Sensor (heat demand), id=04:055480, zone=03
2021-02-27 07:57:55 INFO (MainThread) [custom_components.evohome_cc.sensor] Found a Sensor (heat demand), id=04:055506, zone=04
2021-02-27 07:57:55 INFO (MainThread) [custom_components.evohome_cc.sensor] Found a Sensor (heat demand), id=04:055486, zone=05
2021-02-27 07:57:55 INFO (MainThread) [custom_components.evohome_cc.sensor] Found a Sensor (heat demand), id=04:055482, zone=06
2021-02-27 07:57:55 INFO (MainThread) [custom_components.evohome_cc.sensor] Found a Sensor (heat demand), id=04:055600, zone=07
2021-02-27 07:57:55 INFO (MainThread) [custom_components.evohome_cc.sensor] Found a Sensor (heat demand), id=01:050858, zone=FF
2021-02-27 07:57:55 INFO (MainThread) [custom_components.evohome_cc.sensor] Found a Sensor (relay demand), id=13:215029, zone=FA
2021-02-27 07:57:55 INFO (MainThread) [custom_components.evohome_cc.sensor] Found a Sensor (relay demand), id=13:246213, zone=F9
2021-02-27 07:57:55 INFO (MainThread) [custom_components.evohome_cc.sensor] Found a Sensor (temp), id=07:014869, zone=FA
2021-02-27 07:57:55 INFO (MainThread) [custom_components.evohome_cc.sensor] Found a Sensor (temp), id=04:055594, zone=00
2021-02-27 07:57:55 INFO (MainThread) [custom_components.evohome_cc.sensor] Found a Sensor (temp), id=22:245508, zone=00
2021-02-27 07:57:55 INFO (MainThread) [custom_components.evohome_cc.sensor] Found a Sensor (temp), id=04:055596, zone=01
2021-02-27 07:57:55 INFO (MainThread) [custom_components.evohome_cc.sensor] Found a Sensor (temp), id=22:245512, zone=01
2021-02-27 07:57:55 INFO (MainThread) [custom_components.evohome_cc.sensor] Found a Sensor (temp), id=04:055510, zone=02
2021-02-27 07:57:55 INFO (MainThread) [custom_components.evohome_cc.sensor] Found a Sensor (temp), id=04:055480, zone=03
2021-02-27 07:57:55 INFO (MainThread) [custom_components.evohome_cc.sensor] Found a Sensor (temp), id=22:245517, zone=04
2021-02-27 07:57:55 INFO (MainThread) [custom_components.evohome_cc.sensor] Found a Sensor (temp), id=04:055506, zone=04
2021-02-27 07:57:55 INFO (MainThread) [custom_components.evohome_cc.sensor] Found a Sensor (temp), id=04:055486, zone=05
2021-02-27 07:57:55 INFO (MainThread) [custom_components.evohome_cc.sensor] Found a Sensor (temp), id=04:055482, zone=06
2021-02-27 07:57:55 INFO (MainThread) [custom_components.evohome_cc.sensor] Found a Sensor (temp), id=04:055600, zone=07
2021-02-27 07:57:55 INFO (MainThread) [custom_components.evohome_cc.binary_sensor] Found a Binary Sensor (actuator), id=13:215029, zone=None
2021-02-27 07:57:55 INFO (MainThread) [custom_components.evohome_cc.binary_sensor] Found a Binary Sensor (actuator), id=13:246213, zone=None
2021-02-27 07:57:55 INFO (MainThread) [custom_components.evohome_cc.binary_sensor] Found a Binary Sensor (battery), id=07:014869, zone=None
2021-02-27 07:57:55 INFO (MainThread) [custom_components.evohome_cc.binary_sensor] Found a Binary Sensor (battery), id=04:055594, zone=01:050858_01:050858_00 (RAD)
2021-02-27 07:57:55 INFO (MainThread) [custom_components.evohome_cc.binary_sensor] Found a Binary Sensor (battery), id=22:245508, zone=None
2021-02-27 07:57:55 INFO (MainThread) [custom_components.evohome_cc.binary_sensor] Found a Binary Sensor (battery), id=04:055596, zone=01:050858_01:050858_01 (RAD)
2021-02-27 07:57:55 INFO (MainThread) [custom_components.evohome_cc.binary_sensor] Found a Binary Sensor (battery), id=22:245512, zone=None
2021-02-27 07:57:55 INFO (MainThread) [custom_components.evohome_cc.binary_sensor] Found a Binary Sensor (battery), id=04:055510, zone=01:050858_01:050858_02 (RAD)
2021-02-27 07:57:55 INFO (MainThread) [custom_components.evohome_cc.binary_sensor] Found a Binary Sensor (battery), id=04:055480, zone=None

TRV 514 does show up (temperature, demand, etc) in HA, it just doesn’t seem to be attached to the zone in HA - and yet Evohome itself, seems to be able to control both TRVs as required for the Living Room zone?

When I add an override, via the Honeywell App, heat_demand for both TRVs is shown - so it wouldn’t seem to be an ‘orphan’ as far as the controller is concerned?

      "04:055514":{
         "temperature":20.9,
         "setpoint":"None",
         "battery_state":"None",
         "enabled":true,
         "heat_demand":1.0,
         "window_state":"None"
      },
      "04:055594":{
         "temperature":21.5,
         "setpoint":18.0,
         "battery_state":"None",
         "enabled":true,
         "heat_demand":1.0,
         "window_state":"None"
      },

zxdavb · February 27, 2021, 9:46am

I will answer your question, but ask you to make it a wiki entry?

Note: none of the RAMSES-II protocol is documented, so I could be wrong, but…

Discovery vs Eavesdropping

OK - there is a difference between:

discovery, where - when asked - the controller tells evohome_rf the ‘truth’ of your configuration, and
eavesdropping (where evohome_rf sniffs packets sent by any device to ‘learn’ how the system is configured (and will be ‘wrong’ is a device is badly configured’)

Discovery was ‘discovered’ by me - after I spent the best part of a year making eavesdropping work.

Discovery occurs on startup, and takes 1-3 minutes, after which it is complete. Eavesdropping is an ongoing process.

Both have issues, but: in short: discovery is the way forward, and I am thinking of limiting the role of eavesdropping (but, e.g. you cannot use eavesdropping on systems with a battery-powered controller like a Round Thermostat).

Another issue is that there are things worth knowing, that can only be determined via eavesdropping, e.g. the temperature sensor for a zone, it it is the evohome controller.

TL;DR: If you see something ‘eventually’, then that is eavesdropping and not discovery, and the information is likely to have come from a device other than the controller, the authorative source.

The sync_cycle

There are two pairs of data regularly being exchanged between the controller and the TRVs:

from controller: target zone setpoints (not necessarily scheduled setpoints, e.g. TemproraryOverride) and current zone temperature (which, ultimately, cames only from the zone’s temperature sensor device)
from TRV: its personal current temperature (IIRC), and its personal heat demand.

The first is sent periodically by the controller - precisely every 180.5 seconds in my case (different systems use a different value for this, usually every 2-4 minutes, look for a 1F09 packet) - because the TRVs have to turn on their hearing for it (they keep their antennas off otherwise, to save battery).

(it is because of the sync_cycle that a scan_interval of 10 seconds is not useful - please use 60 seconds)

Note: a TRV does not need to be in a zone from the controller’s point of view to choose to accept this data and process it as if it was in the zone.

The second is sent by the TRV only when it has something to say (i.e. the temperature when up), or every unit time otherwise (I forget: 4 hours?). The controller uses all of each zone’s heat demands (i.e. the heat demand of each TRV in a given zone) to calculate the overall heat demand for a zone.

Note: a controller will ignore this data if it is coming from a device that it doesn’t ‘trust’.

In your specific case, the net effect is that your zone’s heat demand may not be accurate. You may not notice this, because the error is likely to be small (i.e. one end of the room is just as warm as the other end).

If you want, force the error to be large and see what happens: stick one TRV outside and see it’s current temperature drop (you can’t see this in the evohome UI, but can in HA), and the heat demand rise (you may see this in the controller service UI) - then swap around and test with the other TRV.

iMiMx · February 27, 2021, 12:02pm

Will do.

My main concern, was that I should have been seeing both TRVs listed in the start up, after it queried via discovery the controller. So whilst I was seeing:

INFO (MainThread) [custom_components.evohome_cc.sensor] Found a Sensor (heat demand), id=04:055594, zone=00

I was wondering if should be seeing both TRVs listed against zone 00 on start-up:

INFO (MainThread) [custom_components.evohome_cc.sensor] Found a Sensor (heat demand), id=04:055594, zone=00
INFO (MainThread) [custom_components.evohome_cc.sensor] Found a Sensor (heat demand), id=04:055514, zone=00

And then something like:

[custom_components.evohome_cc.sensor] Found a Sensor (temp), id=04:055514, zone=00
[custom_components.evohome_cc.sensor] Found a Sensor (temp), id=04:055594, zone=00
[custom_components.evohome_cc.sensor] Found a Sensor (temp), id=22:245508, zone=00

But as you state:

Note : a TRV does not need to be in a zone from the controller’s point of view to choose to accept this data and process it as if it was in the zone.

I understand that this is not a problem and accounts for the ‘orphan’ with the controller still able to trigger it as required.

zxdavb · February 27, 2021, 3:15pm

I should have said - to obtain a system schema without using discovery can take several hours, or longer.

Also, there is a 3rd means to determine a system schema - manual definition via a schema in a config file.

I am not sure if I 100% will answer your question, but:

Found a Sensor (heat demand)

… is a function of a device, not of a zone.

To further confuse matters, the parentage of a device (e.g. what zone it is in) can be determined by a method other than the one used to find the device in the first place.

That is, a device can exist independent of a zone, or of a (evohome system/controller).

On that basis, I have changed the next version of the cod e- it will reveal all devices to HA, even if they are not obviously part of your evohome (or compatible) system. These may be your own ‘orphans’, or they may belong to a neighbor - you’ll want to consider using an allow_list (aka whitelist) if so.

iMiMx · February 27, 2021, 4:13pm

I need to perform some more testing with this, when I temporarily enabled it the orphan zone (04:055514) didn’t appear - even though it was specified - it was permanently unavailable.

I need to double-check I did not have typing mistakes etc, before reporting ‘officially’.

iMiMx · February 27, 2021, 5:07pm

Looks like it was - all ok with static allow_list.

skundrik · February 27, 2021, 10:01pm

@zxdavb David, I have PMd you a fix for 30C9 message on Hometronic as well as some logs.

I’m also unable to change any settings on the climate card. I can see the W messages being sent out but there is no reply. I don’t thing it’s HW since I do see RQ/RP messages in the log on startup (although there doesn’t seem to be a response for each request). I’m beginning to think there may be some difference in the protocol for Hometronic and it’s just not reacting to the messages.

zxdavb · February 27, 2021, 10:51pm

Likely. Simple trick is to do what you want via the normal means, whilst capturing a packet log - the answer will be in there.

Unfortunately, discovery is limited for Hometronics - you’ll have to rely upon eavesdropping.

zxdavb · February 27, 2021, 11:54pm

For those running Hometronics, could you tell me what you get from:

python client.py execute /dev/ttyUSB0 -x "RQ 01:xxxxxx 2E04 00" -o packet.log

and

python client.py execute /dev/ttyUSB0 -x "RQ 01:xxxxxx 2E04 FF" -o packet.log

where 01:xxxxxx is your controller ID.

skundrik · February 28, 2021, 12:28am

Here you go

2021-02-28T00:25:41.694444 # evofw3 0.6.8
2021-02-28T00:25:41.751409 000  I --- 18:138267 63:262142 --:------ 7FFF 027 00002E150334807F65766F686F6D655F72662076302E352E3130F7
2021-02-28T00:25:41.810385 000  I --- 18:138267 63:262142 --:------ 7FFF 027 00002E150334807F65766F686F6D655F72662076302E352E31307F
2021-02-28T00:25:41.816333 000 RQ --- 18:138267 01:020766 --:------ 2E04 001 FF
2021-02-28T00:25:41.849312 053 RP --- 01:020766 18:138267 --:------ 2E04 016 FFFFFFFFFFFFFF0000FFFFFFFFFFFF04
2021-02-28T00:25:41.849312 053 RP --- 01:020766 18:138267 --:------ 2E04 016 FFFFFFFFFFFFFF0000FFFFFFFFFFFF04
2021-02-28T00:25:43.589534 066  I --- 00:000606 --:------ 00:000606 30C9 003 00074B
2021-02-28T00:25:44.091534 037  I --- 04:024117 --:------ 04:024117 30C9 003 0007FC
2021-02-28T00:25:45.090215 074  I --- 04:017575 --:------ 04:017575 30C9 003 0007F5
2021-02-28T00:25:48.589939 056  I --- 00:000474 --:------ 01:020766 2309 003 0303E8
2021-02-28T00:25:48.601904 076  I --- 04:017575 --:------ 04:017575 1060 003 00FF01
2021-02-28T00:25:49.089463 074  I --- 00:000558 --:------ 00:000558 30C9 003 000713
2021-02-28T00:25:57.585510
2021-02-28T00:25:57.948462 # evofw3 0.6.8
2021-02-28T00:25:58.019685 000 RQ --- 18:138267 01:020766 --:------ 2E04 001 00
2021-02-28T00:25:58.019685 000 RQ --- 18:138267 01:020766 --:------ 2E04 001 00
2021-02-28T00:25:58.063371 053 RP --- 01:020766 18:138267 --:------ 2E04 016 FFFFFFFFFFFFFF0000FFFFFFFFFFFF04
2021-02-28T00:25:58.063371 053 RP --- 01:020766 18:138267 --:------ 2E04 016 FFFFFFFFFFFFFF0000FFFFFFFFFFFF04
2021-02-28T00:26:00.092549 079  I --- 00:000806 --:------ 01:020766 1060 003 0AFF01
2021-02-28T00:26:00.104430 081  I --- 00:000806 --:------ 00:000806 1060 003 00FF01
2021-02-28T00:26:01.088521 056  I --- 00:000474 --:------ 00:000474 30C9 003 0006C3

skundrik · February 28, 2021, 1:37am

@zxdavb David, is there a way to send a command like this using the client?

  W --- 04:024117 --:------ 01:020766 0001 005 0900000505

zxdavb · February 28, 2021, 1:49am

Yep… and we enter the world of impersonation.

NOTE: I am afraid you cannot do this with a HGI80.

I will release a new version of evohome_rf that can do this:

python client.py execute /dev/ttyUSB0 -x "W 04:024117 01:020766 0001 0900000505"

… or, in your specific case:

... -x "W 04:024117 --:------ 01:020766 0001 0900000505"

I am curious, why do you want to execute that particular command?

skundrik · February 28, 2021, 10:45am

Excellent question. I noticed that when I did a TRV cold restart it sent this message (0001 should be RF test according to wiki) so it gave me an idea to try and see if I can use this to test the RF link from my nanoCUL to the Hometronic. Hometronic has a service mode screen like this

I tried it with the current client which uses GW adress as a source but it didn’t seem to register and target seem to be in the second addr. field rater than third. So I want to try the exact message and see what happens. It might be a nice tool for diagnostics showing signal strength for those who seem to have issues with their nanoCULs.

zxdavb · February 28, 2021, 11:11am

I wrote that wiki.

evohome_rf already does a such a test - there was a bug, though, and under certain circumstances these packets were getting dropped - I have fixed it now, and it will be in 0.5.11. It is now called rf_check:

(venv) dbonnes@vm-builder ~/c/evohome (bleeding_edge)> python client.py monitor /dev/ttyUSB0 -x "RQ 01:145038 1F09 00"

client.py: Starting evohome_rf...
11:08:16.203 Not Using an device filter (an allow_list is recommended)
11:08:16.205 # evohome_rf 0.5.11
11:08:16.257 PktProtocolQos.send_data( I|63:262142|7FFF|01): boff=0, want= I|63:262142|7FFF|01, tout=2021-02-28 11:08:16.307808: RE-SENT (1/24)
11:08:16.310 PktProtocolQos.send_data( I|63:262142|7FFF|01): boff=0, want= I|63:262142|7FFF|01, tout=2021-02-28 11:08:16.360012: RE-SENT (2/24)
11:08:16.362 PktProtocolQos.send_data( I|63:262142|7FFF|01): boff=0, want= I|63:262142|7FFF|01, tout=2021-02-28 11:08:16.412377: RE-SENT (3/24)
11:08:16.416 PktProtocolQos.send_data( I|63:262142|7FFF|01): boff=0, want= I|63:262142|7FFF|01, tout=2021-02-28 11:08:16.466416: RE-SENT (4/24)
11:08:16.470 PktProtocolQos.send_data( I|63:262142|7FFF|01): boff=0, want= I|63:262142|7FFF|01, tout=2021-02-28 11:08:16.520287: RE-SENT (5/24)
11:08:16.481 # evofw3 0.6.7
11:08:16.524 PktProtocolQos.send_data( I|63:262142|7FFF|01): boff=0, want= I|63:262142|7FFF|01, tout=2021-02-28 11:08:16.574478: RE-SENT (6/24)
11:08:16.555 || HGI:140805 | NUL:262142 |  I | puzzle_packet    | 01763... || {'evohome_rf': 'v0.5.11'}
11:08:16.582 || HGI:140805 | CTL:145038 | RQ | system_sync      | 00       || {}
11:08:16.595 || CTL:145038 | HGI:140805 | RP | system_sync      | 0006EF   || {'remaining_seconds': 177.5, '_next_sync': '11:11:14'}
11:08:16.624 || HGI:140805 | CTL:145038 | RQ | rf_check         | 00       || {'zone_idx': '00'}
11:08:16.635 || CTL:145038 | HGI:140805 | RP | rf_check         | 0021     || {'zone_idx': '00', 'rf_strength': 5, 'rf_value': 33}
11:08:16.664 || HGI:140805 | CTL:145038 | RQ | device_info      | 00       || {}
11:08:16.701 || CTL:145038 | HGI:140805 | RP | device_info      | 00000... || {'description': 'Evo Color', 'date_1': '2013-08-01', 'date_2': '2020-08-11', '_unknown': '000002FF0163FFFFFFFF'}

You can see:

first the puzzle packet, which is re-transmitted until the gateway wakes up (the bug affected this, 2 re-tramsits instead of 24)
then the -x command RQ/1F09 (sync_cycle) and corresponding RP
then the first packet when ‘discovering’ a controller, RQ/0016 (rf_check) and teh correpsnding RP

zxdavb · February 28, 2021, 3:15pm

All,

If you are using a nanoCUL instead of a HGI80, you must now upgrade evofw3 to ~~v0.6.13~~ v0.6.14.

you must also use the associated board definition file in the Arduino tool, currently v1.06 (older versions will cause issues)
see: the ghoti57/evofw3 Wiki on github

The next version of evohome_rf will utilize features from this specific firmware to improve reliability by - inter alia - reducing the baud rate.

If you are board (see what I did there?), you can do it now, because a new version of evohome_cc will be released later today.