I should start by saying that _sensor & _actuators are calculated differently from the other two.
Importantly, devices includes actuators & sensors too.
Without your latest packet log, I cannot be sure, but - this appears to show that 04:003434 is configured as a sensor for zone 04 (the Bedroom zone), but not as an actuator.
I’m sure its working as an actuator - it’s just not doing it optimally. For example, the zone’s heat demand will not be correctly calculated by the controller because it will not listen to that actuator (and same for evohome_cc).
Other issues may present themselves - I wont know for sure without checking the packet log.
To fix this, simply re-bind it to the zone as an actuator - if you don’t know which one of the two is which, just re-bind both - that wont break anything - you’ll have to restart HA with restore_state: false
Please do send me a packet log - it must include a restart of HA.
I’m trying to get a stable setup.
At first I thought that it had to do with bad reception of the evofw3 stick, so I extended it so it now is next to the controller.
The TVR are now logging data in evohome_cc (except the unit in the attic/zolder, but that is possible due to 2 concrete floors )
But I’m still seeing strange things in H.A. (what trigger me in the first place).
With standard thermostat entities they sometimes gray out (like slaapkamer)
While the simple thermostat card stays oke (int = evohome-online entities, the others are evohome_cc)
For example, when does the zone go unavailable (and for how long) - it is relatively easy for you to see (HA will tell you) - it is painful fro me to scan a HA log without such hints.
Also, send the evohome_cc: from your configuration.yaml, not from the sensor (binary_sensor.18_005567_config).
Please - if you want help - don’t make me do all the drudge work.
Nonetheless, we have this: Sending now deprecated for 01:223036:
Your log file goes from 00:00:00 to 18:55:09 - that approx 68100 seconds. Your cycle time is 120.5 seconds, so you should be getting 68100 / 120.5 = 565 of these:
I --- 01:223036 --:------ 01:223036 2309 030 0006400104B00204B00304B00404B00505DC0604B00704B00805DC0904B0
You only have 511 in your packet log - a loss of nearly 10% (actually, it’s maybe more like 7% because of something else).
In summary - your system is a little too unreliable at the Hardware/RF layer - you woudl expect things to become unavailable at times.
Can I ask: did you have this in your configuration file:
TRV binding was a success, repeated it multiple times - both individually and both at once. They both ‘work’ …not sure if this is a code bug, or some other oddity. Ran out of time to play for logs etc, the Australian gets annoyed when I mess with the heating at this time of year.
… and, yup, I set restore_state: false
… do device IDs change when rebinding? :-/ Edit: Nope.
… tried deleting and recreating the zone, re-binding both TRVs and the DT92E, still the same. Most odd.
I’m not sure I had a choice - I just deleted the zone, then added another one and it recreated (presumably) on the first free contiguous zone number.
Attached below packet log is from midnight, i.e today, so should contain the before-deleting-the-zone, with only 1 actuator listed on zone 0, then a few attempts at rebinding and ending up with ‘null’
Hopefully I might get some time to play again tomorrow. From an evohome point of view, the TRVs are operating, the DT92E is the sensor, all seems ok from that point of view.