Liking the new display detail on the schema.
Has shown up an interesting potential zone config error (although it is working fine). This zone should have two actuators.
'04':
_name: Bedroom
heating_type: radiator_valve
sensor: '04:003434'
devices:
- '04:003434'
- '04:003202'
_sensor: '04:003434'
_actuators:
- '04:003202'
'05':I should start by saying that _sensor & _actuators are calculated differently from the other two.
Importantly,
devicesincludes 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.
It is definitely working as an actuator. I’m not too worried about this, but do you want to see the packet log?
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.
This is what happens:
06:02:54.309 || TRV:003286 | CTL:185426 | I | heat_demand | 03 || {'zone_idx': '03', 'heat_demand': 0.0}
06:03:15.516 || TRV:003286 | CTL:185426 | I | heat_demand | 03 || {'zone_idx': '03', 'heat_demand': 1.0}
06:03:15.914 || CTL:185426 | | I | relay_demand | F9 || {'domain_id': 'F9', 'relay_demand': 1.0}
The heat demand for an actuator in a zone changes, and it results is an increased/decreased call for heat.
In your case, the demand from the incorrectly configured controller will be ignored.
11:04:32.986 || TRV:003434 | CTL:185426 | I | heat_demand | 04 || {'zone_idx': '04', 'heat_demand': 0.43}
11:04:34.305 || TRV:003202 | CTL:185426 | I | heat_demand | 04 || {'zone_idx': '04', 'heat_demand': 0.42}
However, you’re lucky in that they only ever appear to be 1-2% apart!
Hi,
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)
I’m now generating a set of files (packet.log & homeassistant.log & config & schemas and a log of sniffer which is more central in the house).
Any suggestions of what to check?
Is your stick tunable? If so, try to tune it.
Running 0.16.11 some climate zones go into undefined after a while. Eg climate.febe.
binary_sensor.18_005567_config:
schema:
controller: '01:223036'
system:
heating_control: '10:040239'
config:
enforce_known_list: true
known_list:
- '01:223036': {}
- '10:040239': {}
- '04:231770': {}
- '04:231772': {}
- '04:231774': {}
- '04:231776': {}
- '04:050559': {}
- '04:155445': {}
- '04:155403': {}
- '04:081849': {}
- '04:155443': {}
- '04:155407': {}
- '04:155551': {}
- '04:155533': {}
- '04:155537': {}
block_list:
other_list: 12:138834, 13:189944
_is_evofw3: null
friendly_name: 18:005567 (config)
Sorry - not sure - someone else can help?
Please see: this post
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:
2021-11-22 11:51:29 WARNING (MainThread) [ramses_rf.entities] RQ --- 18:000730 01:223036 --:------ 0418 003 000000 < Sending now deprecated for 01:223036 (evohome) (consider adjusting device_id filters)
2021-11-22 11:59:15 WARNING (MainThread) [ramses_rf.entities] RQ --- 18:000730 01:223036 --:------ 0006 001 00 < Sending now deprecated for 01:223036 (evohome) (consider adjusting device_id filters)
2021-11-22 11:59:21 WARNING (MainThread) [ramses_rf.entities] RQ --- 18:000730 01:223036 --:------ 2E04 001 FF < Sending now deprecated for 01:223036 (evohome) (consider adjusting device_id filters)
2021-11-22 11:59:29 WARNING (MainThread) [ramses_rf.entities] RQ --- 18:000730 01:223036 --:------ 0418 003 000000 < Sending now deprecated for 01:223036 (evohome) (consider adjusting device_id filters)
… and that will cause big issues!
In your HA log file - there are about 3,600 RPs from the controller to the HGI… 116 (over 3%) of them are of this form:
WARNING ... [ramses_rf.protocol.transport] ... QoS: IS_EXPIRED (giving up)
This doesn’t count re-transmits, only timeouts. If you want to see re-transmits, add this to your logging configuation:
ramses_rf.protocol.transport: debug
Last I heard, you were running two HGI80s at the same time, and one of them was in a VM - is that still the case?
Thanks @iMiMx
So for future reference and others:
): !FBased on: https://github.com/ghoti57/evofw3/wiki/EVOFW3-Autotune
Again thank you for the article iMiMx
So, here is another way of looking at it…
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:
ramses_rf.protocol.message: infoIs this something that is related to the placement of the HGI80?
For the logging:
custom_components.evohome_cc: warn
ramses_rf.message: info
I’m going to add ramses_rf.protocol.message: info
For the future, I’ll add a timestamp as well as the configuration of evohome
Is it recommended to autotune your nanocul device (i have the one from ebay with an antenna)
Did you try rebinding these? I was seeing the same, only 1 actuator listed but both devices listed.
Tried rebinding both TRVs to the zone, then ended up with … no TRVS listed
'00':
_name: Living Room
heating_type: radiator_valve
sensor: '22:245508'
devices:
- '22:245508'
_sensor: '22:245508'
_actuators: null
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 would have to see the packet log…
For various reasons, I don’t run a zone “00” here - I wonder if that has something to do with it…
Yes. I unbound the TRVs, deleted the zones, and recreated them. Schema now looks ok. (And I do have a zone 0.)
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.