Thanks for all the hard work on getting this up and running.
Do you have an idea when dhw will be available, it’s the one thing I use more then anything else.
Are you using a nanoCUL by any chance?
dhw didn’t seem to appear for me, until I resolved the TX problem - once I did, it then appeared - presumably this must be queried, rather than sniffed.
@zxdavb must be being stupid as I couldn’t find how to send you a PM via this website. I’ve sent you a link for the HA logs, via your .me email.
I don’t get the Message option?
I have 3 zones that doesn’t have any devices, any idea how to get them to show up?
You can send me a log file?
Got it, hopefully the link I just shared works.
@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.
No problem, more than happy to help and to continue doing so.
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']}
1 Like
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!
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"
},
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.
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.
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.
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’.
Looks like it was - all ok with static allow_list.
@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.