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:
- open a terminal to the serial port
- send to get current frequentie: !F
- start autotune: !FT
- check state of autotune (if it says tuning it is still running
): !F - done and not happy? Reset: !FR
- done and happy?: !FS
Based on: https://github.com/ghoti57/evofw3/wiki/EVOFW3-Autotune
Again thank you for the article iMiMx
1 Like
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.
I’ve just rebooted (17:51), and intially I had a DHW temperature value (from sensor.07_046786_temperature). When I next looked, probably around 18:10, the sensor was unavailable, and the last change was recorded at 18:06. If I look in the packet.log, filtered for what I think are the packets from the DHW sensor reporting temperature, I see the following. So it looks like temperature readings were being received.
2021-11-23T17:51:23.846399 ... I --- 07:046786 --:------ 07:046786 1060 003 00FF01 # 1060| I|07:046786
2021-11-23T17:51:23.881375 ... I --- 07:046786 --:------ 07:046786 1260 003 0016FF # 1260| I|07:046786
2021-11-23T18:02:44.326070 062 I --- 07:046786 --:------ 07:046786 1260 003 001684
2021-11-23T18:06:29.353990 062 I --- 07:046786 --:------ 07:046786 1260 003 00161C
2021-11-23T18:11:29.391768 069 I --- 07:046786 --:------ 07:046786 1260 003 0015A5
2021-11-23T18:14:44.415609 061 I --- 07:046786 --:------ 07:046786 1260 003 00153D
2021-11-23T18:20:29.458360 061 I --- 07:046786 --:------ 07:046786 1260 003 0014D5
Are you interested in seeing the packet and HA logs for this? I have these log settings:
logs:
homeassistant.core: debug
ramses_rf.message: info
ramses_rf.protocol.message: info
evohome_rf.packet_log: infoSo, the relevant packet should be 6, 12, 18, 24 bytes long… Every TRV will add another 6 bytes.
For your system - the only time I’ve ever seen it before now - it goes from 6 to 11 bytes when you add the second TRV!
But now I’ve looked - there are (only) 3 systems doing this (I’ve got logs from many, many systems):
1970-01-01T01:00:00.000000 053 RP --- 01:051477 18:013109 --:------ 000C 011 02000028909F00001186E7
2021-11-18T11:41:06.666720 057 RP --- 01:069616 18:205592 --:------ 000C 011 010800121B540800121B52
2021-11-18T11:41:06.738780 049 RP --- 01:050858 18:141846 --:------ 000C 011 00000010D92A000010D8DA
So at one TRV, this packet would be valid, but add a second TRV and its payload becomes invalid.
@iMiMx Is there any chance you could capture the creation of a zone with 3 TRVs, so I can see exactly what’s going on? Specifically, restart HA after creating such a zone, and have restore_state: false.
Probably not reproducible in the true sense (I don’t know when it will have a value, and then become unavailable), but it is unavailable more often than it is. And whenever I look, the packets are being received. Graph for last 48 hrs:
No, I think we can work with that. Is it the same for something that would send pkts more often, like a relay?
I certainly think I am missing relay packets. If you look at the plot below, the pink line is a crude temperature sensor on the boiler bypass (ignore the sharp drops where there is a data point lost and the filtering does not quite work). There should be a correlation between it, and the green heating relay line, but as you can see, there are periods when the green peaks are missing. What I can’t tell you at the moment is if the relay sensor goes unavailable, or whether it just does not record the changes. I’ll try and keep an eye on it tomorrow.
Missing packets for that long should result in unavailable…
@Lloyd Please run version 0.16.13 0.16.14 - it has some DHW sensor-specific tricks.
Please report any changes you notice, and keep an eye on your logs via the HA web UI.