I am so sorry, everyone - this was an unintended change - at the moment, I don’t have time to work out if/how to change it back, or not…
You may want to go back to 0.16.x until then, or if you don’t mind losing historical data, just leave it as-is.
I cannot help you, without seeing your configuration.yaml - I suggest you look for unwanted whitespace.
I am not sure what you mean - please send me a packet log.
Has anyone had a bit_3_7 that is not Off (false)?, or a bit 6_6 that is not On (true)?
My best guess for 6_6 is that it is dhw_enabled
Solved it. My mistake, I swapped 2 digits all the time.
@zxdavb any thoughts on my zone_valve zone “Invalid verb/code” and QoS issues?
Not sure if it’s related but I noticed the schema has an empty actuators list for this zone, and the BDR that controls the zone valve is listed as an orphan. Is this expected for a zone_valve zone?
First, the crashing issue seems to be gone (version 16:30) it is running stable again.
Didn’t change anything…
My HA log is filled (every minute 5 times) with next warning :
2021-12-23 16:23:57 WARNING (MainThread) [ramses_rf.protocol.transport] PktProtocolQos.send_data(sent=3220|RQ|10:062498|00): boff=0, want=3220|RP|10:062498|00, tout=2021-12-23T16:23:57.168: QoS: IS_EXPIRED (giving up) (0/0)
2021-12-23 16:23:57 WARNING (MainThread) [ramses_rf.protocol.transport] PktProtocolQos.send_data(sent=3220|RQ|10:062498|01): boff=0, want=3220|RP|10:062498|01, tout=2021-12-23T16:23:57.272: QoS: IS_EXPIRED (giving up) (0/0)
2021-12-23 16:23:57 WARNING (MainThread) [ramses_rf.protocol.transport] PktProtocolQos.send_data(sent=3220|RQ|10:062498|12): boff=0, want=3220|RP|10:062498|12, tout=2021-12-23T16:23:57.375: QoS: IS_EXPIRED (giving up) (0/0)
2021-12-23 16:23:57 WARNING (MainThread) [ramses_rf.protocol.transport] PktProtocolQos.send_data(sent=3220|RQ|10:062498|19): boff=0, want=3220|RP|10:062498|19, tout=2021-12-23T16:23:57.479: QoS: IS_EXPIRED (giving up) (0/0)
2021-12-23 16:23:57 WARNING (MainThread) [ramses_rf.protocol.transport] PktProtocolQos.send_data(sent=3220|RQ|10:062498|1B): boff=0, want=3220|RP|10:062498|1B, tout=2021-12-23T16:23:57.583: QoS: IS_EXPIRED (giving up) (0/0)
My packet log at that time showes :
2538 045 RQ --- 30:123820 01:085674 --:------ 2349 001 02
2021-12-23T16:23:00.478081 048 RP --- 01:085674 30:123820 --:------ 2349 007 0206A402FFFFFF
2021-12-23T16:23:02.227505 051 I --- 04:175713 --:------ 01:085674 2309 003 060640
2021-12-23T16:23:02.794549 045 I --- 30:123820 --:------ 30:123820 1290 003 007FFF
2021-12-23T16:23:03.993273 045 RQ --- 30:123820 01:085674 --:------ 2E04 001 FF
2021-12-23T16:23:04.011855 048 RP --- 01:085674 30:123820 --:------ 2E04 008 00FFFFFFFFFFFF00
2021-12-23T16:23:07.695654 045 RQ --- 30:123820 01:085674 --:------ 2349 001 03
2021-12-23T16:23:07.711204 047 RP --- 01:085674 30:123820 --:------ 2349 007 0306A402FFFFFF
2021-12-23T16:23:07.731027 048 I --- 04:205059 --:------ 01:085674 2309 003 0105DC
2021-12-23T16:23:10.227468 070 I --- 04:166526 --:------ 01:085674 3150 002 0426
2021-12-23T16:23:14.729001 045 RQ --- 30:123820 01:085674 --:------ 2349 001 04
2021-12-23T16:23:14.745444 047 RP --- 01:085674 30:123820 --:------ 2349 007 0405DC02FFFFFF
2021-12-23T16:23:15.159330 045 RQ --- 30:123820 10:062498 --:------ 3EF0 001 00
2021-12-23T16:23:15.186041 051 RP --- 10:062498 30:123820 --:------ 3EF0 006 0000100000FF
2021-12-23T16:23:19.226583 065 I --- 04:166512 --:------ 01:085674 2309 003 050898
2021-12-23T16:23:22.668169 045 RQ --- 30:123820 01:085674 --:------ 2349 001 05
2021-12-23T16:23:22.682554 046 RP --- 01:085674 30:123820 --:------ 2349 007 05089802FFFFFF
2021-12-23T16:23:26.427461 051 I --- --:------ --:------ 10:062498 1FD4 003 0000BA
2021-12-23T16:23:29.989905 073 I --- 04:130039 --:------ 01:085674 3150 002 021E
2021-12-23T16:23:32.469336 072 I --- 04:130039 --:------ 01:085674 2309 003 0206A4
2021-12-23T16:23:32.553160 045 RQ --- 30:123820 01:085674 --:------ 2349 001 06
2021-12-23T16:23:32.569423 049 RP --- 01:085674 30:123820 --:------ 2349 007 06064000FFFFFF
2021-12-23T16:23:37.569100 045 RQ --- 30:123820 10:062498 --:------ 3220 005 0000050000
2021-12-23T16:23:37.952972 051 RP --- 10:062498 30:123820 --:------ 3220 005 00C00500FF
2021-12-23T16:23:38.057452 045 RQ --- 30:123820 10:062498 --:------ 3220 005 0000110000
2021-12-23T16:23:38.450762 051 RP --- 10:062498 30:123820 --:------ 3220 005 00F0110000
2021-12-23T16:23:38.555404 045 RQ --- 30:123820 10:062498 --:------ 3220 005 0000120000
2021-12-23T16:23:38.762396 045 RQ --- 30:123820 10:062498 --:------ 22D9 001 00
2021-12-23T16:23:38.792868 051 RP --- 10:062498 30:123820 --:------ 22D9 003 002328
2021-12-23T16:23:38.957684 051 RP --- 10:062498 30:123820 --:------ 3220 005 00C0120600
2021-12-23T16:23:39.064059 045 RQ --- 30:123820 10:062498 --:------ 3220 005 0080130000
2021-12-23T16:23:39.558662 051 RP --- 10:062498 30:123820 --:------ 3220 005 0070130000
2021-12-23T16:23:39.712008 045 RQ --- 30:123820 10:062498 --:------ 3220 005 0080190000
2021-12-23T16:23:40.062118 051 RP --- 10:062498 30:123820 --:------ 3220 005 00C0192F00
2021-12-23T16:23:40.234331 045 RQ --- 30:123820 10:062498 --:------ 3220 005 00801A0000
2021-12-23T16:23:40.561472 051 RP --- 10:062498 30:123820 --:------ 3220 005 00701A0000
2021-12-23T16:23:40.708096 045 RQ --- 30:123820 10:062498 --:------ 3220 005 00801C0000
2021-12-23T16:23:41.160292 051 RP --- 10:062498 30:123820 --:------ 3220 005 00701C0000
2021-12-23T16:23:41.306758 045 RQ --- 30:123820 10:062498 --:------ 3220 005 0080730000
2021-12-23T16:23:41.664063 051 RP --- 10:062498 30:123820 --:------ 3220 005 0070730000
2021-12-23T16:23:42.989727 045 RQ --- 30:123820 01:085674 --:------ 0006 001 00
2021-12-23T16:23:43.005391 048 RP --- 01:085674 30:123820 --:------ 0006 004 00050000
2021-12-23T16:23:49.914553 048 I --- 04:205059 --:------ 04:205059 30C9 003 0005C6
2021-12-23T16:23:54.906542 071 I --- 04:166526 --:------ 04:166526 30C9 003 000674
2021-12-23T16:23:55.981955 049 I --- 01:085674 --:------ 01:085674 1F09 003 FF0776
2021-12-23T16:23:56.011379 047 I --- 01:085674 --:------ 01:085674 2309 021 0007D00105DC0206A40306A40405DC050898060640
2021-12-23T16:23:56.028131 047 I --- 01:085674 --:------ 01:085674 30C9 021 0007BB0105C60206DD0305FC04060205075706065A
2021-12-23T16:23:56.509605 051 I --- --:------ --:------ 10:062498 1FD4 003 0000BB
2021-12-23T16:23:56.672295 095 RQ --- 18:012667 01:085674 --:------ 0006 001 00
2021-12-23T16:23:56.686284 049 RP --- 01:085674 18:012667 --:------ 0006 004 00050000
2021-12-23T16:23:56.716205 095 RQ --- 18:012667 01:085674 --:------ 0418 003 000000
2021-12-23T16:23:56.742646 047 RP --- 01:085674 18:012667 --:------ 0418 022 004000B0040004000000CB955F71FFFFFF70001283B3
2021-12-23T16:23:56.772343 095 RQ --- 18:012667 01:085674 --:------ 2E04 001 FF
2021-12-23T16:23:56.788225 049 RP --- 01:085674 18:012667 --:------ 2E04 008 00FFFFFFFFFFFF00
2021-12-23T16:23:56.976060 095 RQ --- 18:012667 10:062498 --:------ 3EF1 001 00
2021-12-23T16:23:57.009331 051 RP --- 10:062498 18:012667 --:------ 3EF1 007 007FFF003C0010
2021-12-23T16:23:57.037924 095 RQ --- 18:012667 10:062498 --:------ 12F0 001 00
2021-12-23T16:23:57.063238 052 RP --- 10:062498 18:012667 --:------ 12F0 003 007FFF
2021-12-23T16:23:57.098910 095 RQ --- 18:012667 10:062498 --:------ 3220 005 0000000000
2021-12-23T16:23:57.203595 095 RQ --- 18:012667 10:062498 --:------ 3220 005 0080010000
2021-12-23T16:23:57.307363 095 RQ --- 18:012667 10:062498 --:------ 3220 005 0000120000
2021-12-23T16:23:57.409612 095 RQ --- 18:012667 10:062498 --:------ 3220 005 0080190000
2021-12-23T16:23:57.513820 095 RQ --- 18:012667 10:062498 --:------ 3220 005 00001B0000
2021-12-23T16:23:57.928854 051 RP --- 10:062498 18:012667 --:------ 3220 005 00C01BE100
My setup is sligtly different, the openthem controller is connect to the GAS heater (Intergas HR28). At the gas heater, heating for the house is disabled, it is only used for shower.
Heating is done with a Heatpump in WAR mode, it is not connected to EVOHOME (yet).
Evohome only steer the valves at the radiator and floorheating.
Thank you for this project David and the great documentation. I got everything working last week by following the instructions on the wiki. I’ve installed evofw3 on a nanoCUL USB-stick FTDI CC1101 868MHz FW 1.67 FHEM CUL 868+ adapter. And all the devices show up in my HA instance (docker container on Synology NAS).
Yesterday I installed 0.17.0 and I also saw duplicate battery and window sensors. No problem.
If you need any information about the results with a R8810A bridge, just send me a message.
Or information about using this integration with an Itho Daalderop fan.
I have some questions about some of the (future) features later, but first I would love some information about the errors I see in my logs.
This is my configuration. Still using the official evohome integration next to it for the time being.
# Honeywell
evohome:
username: email
password: pass
scan_interval: 240
evohome_cc:
serial_port: /dev/ttyUSB1
packet_log: packet.log
restore_state: true
schema:
controller: 01:127571
heating_control: 10:105590
ramses_rf:
enforce_known_list: True
known_list:
- 04:132386
- 04:132388
- 04:132390
- 04:132392
- 04:172848
- 04:005218
- 37:060187
- 01:127571
- 10:105590
- 18:262143
- 00:127571
Question 1. I see these a lot. But can’t figure out whether it’s a problem. Is it?
Logger: ramses_rf.protocol.transport
Source: /usr/local/lib/python3.9/site-packages/ramses_rf/protocol/transport.py:786
First occurred: 03:10:35 (3838 occurrences)
Last logged: 13:48:38
PktProtocolQos.send_data(sent=3220|RQ|10:105590|01): boff=0, want=3220|RP|10:105590|01, tout=2021-12-24T12:48:37.641: QoS: IS_EXPIRED (giving up) (0/0)
PktProtocolQos.send_data(sent=3220|RQ|10:105590|11): boff=0, want=3220|RP|10:105590|11, tout=2021-12-24T12:48:37.742: QoS: IS_EXPIRED (giving up) (0/0)
PktProtocolQos.send_data(sent=3220|RQ|10:105590|12): boff=0, want=3220|RP|10:105590|12, tout=2021-12-24T12:48:37.843: QoS: IS_EXPIRED (giving up) (0/0)
PktProtocolQos.send_data(sent=3220|RQ|10:105590|19): boff=0, want=3220|RP|10:105590|19, tout=2021-12-24T12:48:37.944: QoS: IS_EXPIRED (giving up) (0/0)
PktProtocolQos.send_data(sent=3220|RQ|10:105590|1A): boff=0, want=3220|RP|10:105590|1A, tout=2021-12-24T12:48:38.045: QoS: IS_EXPIRED (giving up) (0/0)
Question 2. What does this mean? Excessive time difference between what? I have the same timezone in Evohome, my container and in HA.
Logger: ramses_rf.systems
Source: /usr/local/lib/python3.9/site-packages/ramses_rf/systems.py:964
First occurred: 03:10:22 (7 occurrences)
Last logged: 09:10:22
RP --- 01:127571 04:172848 --:------ 313F 009 00FC120084180C07E5 < excessive datetime difference: 1:00:20.382797
RP --- 01:127571 04:132390 --:------ 313F 009 00FC180084180C07E5 < excessive datetime difference: 1:00:20.384367
RP --- 01:127571 04:132392 --:------ 313F 009 00FC1C0084180C07E5 < excessive datetime difference: 1:00:20.887453
RP --- 01:127571 04:132386 --:------ 313F 009 00FC200084180C07E5 < excessive datetime difference: 1:00:20.016924
RP --- 01:127571 18:262143 --:------ 313F 009 00FC2A0A89180C07E5 < excessive datetime difference: 1:00:19.918391
Question 3. Should I worry about any of the following errors / warnings?
Log 3:
Logger: ramses_rf.protocol.transport
Source: /usr/local/lib/python3.9/site-packages/ramses_rf/protocol/transport.py:454
First occurred: 03:15:34 (6 occurrences)
Last logged: 08:32:36
RQ --- 18:000073 10:105590 --:------ 3220 005 0080010000 < There appears to be more than one HGI80-compatible device (active gateway: 18:262143), this is unsupported
RQ --- 18:000030 01:127571 --:------ 12B0 001 01 < There appears to be more than one HGI80-compatible device (active gateway: 18:262143), this is unsupported
RQ --- 18:000370 10:105590 --:------ 3220 005 0000000000 < There appears to be more than one HGI80-compatible device (active gateway: 18:262143), this is unsupported
RQ --- 18:000703 10:105590 --:------ 3EF0 001 00 < There appears to be more than one HGI80-compatible device (active gateway: 18:262143), this is unsupported
RQ --- 18:000070 10:105590 --:------ 3220 005 0080010000 < There appears to be more than one HGI80-compatible device (active gateway: 18:262143), this is unsupported
Log 4:
Logger: ramses_rf.protocol.transport
Source: /usr/local/lib/python3.9/site-packages/ramses_rf/protocol/transport.py:383
First occurred: 03:15:34 (6 occurrences)
Last logged: 08:32:36
Blocking packets with device_id: 18:000073 (is foreign gateway), configure the known_list/block_list as required
Blocking packets with device_id: 18:000030 (is foreign gateway), configure the known_list/block_list as required
Blocking packets with device_id: 18:000370 (is foreign gateway), configure the known_list/block_list as required
Blocking packets with device_id: 18:000703 (is foreign gateway), configure the known_list/block_list as required
Blocking packets with device_id: 18:000070 (is foreign gateway), configure the known_list/block_list as required
Log 5:
Logger: ramses_rf.protocol.transport
Source: /usr/local/lib/python3.9/site-packages/ramses_rf/protocol/transport.py:446
First occurred: 03:53:34 (23 occurrences)
Last logged: 12:29:37
000 RQ --- --:------ 10:105590 --:------ 3220 005 0080190000 < Cant create packet (ignoring): Corrupt addresses: Invalid addr set: --:------ 10:105590 --:------
058 RP --- 01:127571 01:136410 --:------ 0006 004 00050020 < Cant create packet (ignoring): Corrupt addresses: Invalid src/dst addr pair: 01:127571 01:136410 --:------
000 RQ --- --:------ 10:105590 --:------ 3220 005 0000110000 < Cant create packet (ignoring): Corrupt addresses: Invalid addr set: --:------ 10:105590 --:------
000 RQ --- 01:136410 01:127571 --:------ 2349 002 0600 < Cant create packet (ignoring): Corrupt addresses: Invalid src/dst addr pair: 01:136410 01:127571 --:------
059 RP --- 01:127571 01:136410 --:------ 2349 007 06044C02FFFFFF < Cant create packet (ignoring): Corrupt addresses: Invalid src/dst addr pair: 01:127571 01:136410 --:------
Log 6:
Logger: ramses_rf.protocol.transport
Source: /usr/local/lib/python3.9/site-packages/ramses_rf/protocol/transport.py:391
First occurred: 03:10:25 (28 occurrences)
Last logged: 13:04:25
Blocking packets with device_id: 00:078995 (is not whitelisted), if required, add it to the known_list
Blocking packets with device_id: 11:027571 (is not whitelisted), if required, add it to the known_list
Blocking packets with device_id: 01:127751 (is not whitelisted), if required, add it to the known_list
Blocking packets with device_id: 01:172571 (is not whitelisted), if required, add it to the known_list
Blocking packets with device_id: 01:217571 (is not whitelisted), if required, add it to the known_list
Log 7:
Logger: ramses_rf.protocol.message
Source: /usr/local/lib/python3.9/site-packages/ramses_rf/protocol/message.py:378
First occurred: 03:11:22 (13 occurrences)
Last logged: 13:32:37
RQ --- 18:262143 01:127571 --:------ E204 001 FF < Corrupt packet: Invalid code for 01:127571 to Rx: E204
RQ --- 18:262143 10:105590 --:------ 2320 005 0000110000 < Corrupt packet: Invalid code for 10:105590 to Rx: 2320
RQ --- 18:262143 00:127571 --:------ 0006 001 00 < Corrupt packet: Invalid code for 00:127571 to Rx: 0006
RQ --- 18:262143 10:105590 --:------ 2320 005 00801A0000 < Corrupt packet: Invalid code for 10:105590 to Rx: 2320
RQ --- 18:262143 10:105590 --:------ 3220 005 0008190000 < Corrupt payload: OpenTherm: Invalid spare bits: 0b1000
Answer 1: I see these a lot. But can’t figure out whether it’s a problem. Is it?
Yes. No. Maybe. Depends.
In this case, you’ve 3838 occurrences, so something is definitely going on.
All my testing is on an R8820A connected to a Worcester Bosch boiler. Thus, YMMV if you have (say) an R8810A…
It may be the case that your OTB (maybe it is an R8810A?) simply never responds to these OT msg_IDs: 01, 11, 12, 19, 1A? Maybe it is behind a brick wall & the reception is poor?
Please send me a packet log.
Answer 2 . What does this mean? Excessive time difference between what? I have the same timezone in Evohome, my container and in HA.
I’d say it has something to do with TZs, or DST.
All my testing is in GMT - if you want, we can dev/test a solution.
Question 3 . Should I worry about any of the following errors / warnings?
Log 3: and Log 4:
No. They should all be: 18:000730, but are not - you can blame the dongle, I’m afraid. The system isn’t clever enough to know the packets are corrupt, so (on the basis they’re valid packets) warns you it has seen a foreign gateway.
Yes. Get a better dongle - the ones from https://indalo-tech.onlineweb.shop/are best.
Log 5:, Log 6: and Log 7:
See above. For example, 01:127571 is a corruption of 00:127571.
The issue is that whitelisting (or blacklisting, if you’re not sensible enough to whitelist) occurs after packets are validated.
Q1, is indeed the same as i on message earlier showed.
I looked up the OT commands and if it should be support / my experience before :
I have a opentherm gateway, will re-install it comming days and due some logging.
Understand the warning now (thanks !)
In next release will you make the names again same as now ?
Would like to keep my " history ", but if not, then i will also soon update to the latest version.
Hi all,
Anyone any idea what these failures are about?
Many of them occur, also shortly after restarting HA (2021.12.5 with latest evohome_cc 16.30)
Otherwise everything seems to work, I see all thermostate and TRV data, I can control the temperature.
Logger: ramses_rf.protocol.transport
Source: /usr/local/lib/python3.9/site-packages/ramses_rf/protocol/transport.py:786
First occurred: 9:43:14 AM (66 occurrences)
Last logged: 10:02:22 AM
* PktProtocolQos.send_data(sent=0006|RQ|01:197498): boff=3, want=0006|RP|01:197498, tout=2021-12-25T09:59:37.687: QoS: IS_EXPIRED (giving up) (2/2)
* PktProtocolQos.send_data(sent=0418|RQ|01:197498|00): boff=3, want=0418|RP|01:197498|00, tout=2021-12-25T09:59:44.359: QoS: IS_EXPIRED (giving up) (3/3)
* PktProtocolQos.send_data(sent=0006|RQ|01:197498): boff=3, want=0006|RP|01:197498, tout=2021-12-25T10:00:15.436: QoS: IS_EXPIRED (giving up) (2/2)
* PktProtocolQos.send_data(sent=0418|RQ|01:197498|00): boff=3, want=0418|RP|01:197498|00, tout=2021-12-25T10:02:16.112: QoS: IS_EXPIRED (giving up) (3/3)
* PktProtocolQos.send_data(sent=2E04|RQ|01:197498): boff=3, want=2E04|RP|01:197498, tout=2021-12-25T10:02:22.126: QoS: IS_EXPIRED (giving up) (2/2)
I am thinking I will not change the unique IDs back. I would do if it was a true entity, but they are merely sensors, and only window_open, and battery_low.
If you are keen you can do an blanked update in the SQLite DB that will ‘keep’ your history by changing the unique ID of existing entries… You need to be a little brave to do this.
All (as I hide in the bedroom from a house full of 7 kids): you really want to provide a schema and a configuration if you want a reliable answer to questions like this.
1 Like
I would have to have a play - probably reproduce your edge-case - to be able to answer this.
Indeed, sorry.
Configuration, see below.
Schema, I found something in the home-assistant.log, maybe that is what you mean?
evohome_cc:
serial_port: rfc2217://192.168.1.172:2000
packet_log:
file_name: packet.log
rotate_bytes: null
rotate_backups: 7
restore_state: true
schema:
controller: 01:197498
ramses_rf:
enforce_known_list: true
max_zones: 9
#disable_discovery: true
#enable_eavesdrop: true
#disable_sending: true
known_list:
- '01:197498'
- '13:112233'
- '04:068997'
- '04:156239'
- '04:127179'
- '04:127161'
- '04:069001'
- '04:068999'
- '04:069003'
- '04:156243'
- '34:074756'
- '34:074774'
- '34:177017'
- '34:237681'
- '34:074660'
- '34:090069'
- '34:245641'
- '34:074832'
- '18:262143'
[custom_components.evohome_cc.schema] Using a Schema restored from cache: {'main_controller': '01:197498', '01:197498': {'system': {'heating_control': '13:112233'}, 'orphans': [], 'stored_hotwater': {}, 'underfloor_heating': {}, 'zones': {'01': {'_name': 'Hal', 'heating_type': 'radiator_valve', 'sensor': '34:074756', 'sensor_alt': '34:074756', 'devices': ['34:074756', '04:068997', '01:197498'], 'actuators': None}, '02': {'_name': 'Tuinkamer', 'heating_type': 'radiator_valve', 'sensor': '34:177017', 'sensor_alt': '34:177017', 'devices': ['34:177017', '04:127179'], 'actuators': ['04:127179']}, '03': {'_name': 'Studeerkamer', 'heating_type': 'radiator_valve', 'sensor': '34:237681', 'sensor_alt': '34:237681', 'devices': ['34:237681', '04:127161'], 'actuators': ['04:127161']}, '04': {'_name': 'Garage', 'heating_type': 'radiator_valve', 'sensor': '34:074660', 'sensor_alt': '34:074660', 'devices': ['34:074660', '04:069001'], 'actuators': None}, '05': {'_name': 'Badkamer', 'heating_type': 'radiator_valve', 'sensor': '34:074832', 'sensor_alt': '34:074832', 'devices': ['34:074832', '04:156243'], 'actuators': ['04:156243']}, '06': {'_name': 'Marit', 'heating_type': 'radiator_valve', 'sensor': '34:090069', 'sensor_alt': '34:090069', 'devices': ['34:090069', '04:068999'], 'actuators': ['04:068999']}, '07': {'_name': 'Vera', 'heating_type': 'radiator_valve', 'sensor': '34:245641', 'sensor_alt': '34:245641', 'devices': ['34:245641', '04:069003'], 'actuators': ['04:069003']}, '08': {'_name': 'Woonkamer', 'heating_type': 'radiator_valve', 'sensor': '34:074774', 'sensor_alt': '34:074774', 'devices': ['34:074774', '04:156239'], 'actuators': ['04:156239']}}}, 'orphans': [], 'device_hints': {}}
And a snippet of the packet.log, showing I guess some of these 0418 “failures”, meanwhile 867 since this morning.
PktProtocolQos.send_data(sent=0418|RQ|01:197498|00): boff=3, want=0418|RP|01:197498|00, tout=2021-12-25T16:47:16.628: QoS: IS_EXPIRED (giving up) (3/3)
4:49:16 PM – (WARNING) /usr/local/lib/python3.9/site-packages/ramses_rf/protocol/transport.py - message first occurred at 9:43:14 AM and shows up 876 times
2021-12-25T16:46:16.144037 000 RQ --- 18:199184 01:197498 --:------ 2E04 001 FF
2021-12-25T16:46:18.144927 000 RQ --- 18:199184 01:197498 --:------ 2E04 001 FF
2021-12-25T16:46:18.261488 056 RP --- 01:197498 18:199184 --:------ 2E04 008 00FFFFFFFFFFFF00
2021-12-25T16:46:18.394809 000 RQ --- 18:199184 01:197498 --:------ 0418 003 000000
2021-12-25T16:46:19.986676 000 RQ --- 18:199184 01:197498 --:------ 0418 003 000000
2021-12-25T16:46:21.990530 000 RQ --- 18:199184 01:197498 --:------ 0418 003 000000
2021-12-25T16:46:23.996404 000 RQ --- 18:199184 01:197498 --:------ 0418 003 000000
2021-12-25T16:46:24.141858 056 RP --- 01:197498 18:199184 --:------ 0418 022 000000B0000000000000000000007FFFFF7000000000
2021-12-25T16:46:24.252157 000 RQ --- 18:199184 13:112233 --:------ 0008 001 00
2021-12-25T16:46:24.339272 041 RP --- 13:112233 18:199184 --:------ 0008 002 0078
2021-12-25T16:46:24.499042 000 RQ --- 18:199184 13:112233 --:------ 3EF1 001 00
2021-12-25T16:46:24.620985 041 RP --- 13:112233 18:199184 --:------ 3EF1 007 00020E020EC8FF
2021-12-25T16:47:02.863314 056 I --- 01:197498 --:------ 01:197498 1F09 003 FF06A9
2021-12-25T16:47:03.043894 055 I --- 01:197498 --:------ 01:197498 2309 024 0108660208980308340407080508FC060834070834080866
2021-12-25T16:47:03.201686 108 I --- 01:197498 --:------ 01:197498 30C9 024 0108170208A70308600406EB05090706082E07081B08086B
2021-12-25T16:47:03.289817 054 I --- 04:069003 --:------ 04:069003 30C9 003 000947
2021-12-25T16:47:06.742790 030 I --- 34:074756 --:------ 34:074756 30C9 003 000818
2021-12-25T16:47:10.126693 000 RQ --- 18:199184 01:197498 --:------ 0006 001 00
2021-12-25T16:47:10.524750 000 RQ --- 18:199184 01:197498 --:------ 0006 001 00
2021-12-25T16:47:10.615321 055 RP --- 01:197498 18:199184 --:------ 0006 004 00050027
2021-12-25T16:47:10.733194 000 RQ --- 18:199184 01:197498 --:------ 0418 003 000000
2021-12-25T16:47:11.144217 000 RQ --- 18:199184 01:197498 --:------ 0418 003 000000
2021-12-25T16:47:12.741046 000 RQ --- 18:199184 01:197498 --:------ 0418 003 000000
2021-12-25T16:47:14.747657 000 RQ --- 18:199184 01:197498 --:------ 0418 003 000000
2021-12-25T16:47:16.737949 000 RQ --- 18:199184 01:197498 --:------ 2E04 001 FF
2021-12-25T16:47:16.855416 056 RP --- 01:197498 18:199184 --:------ 2E04 008 00FFFFFFFFFFFF00
2021-12-25T16:47:21.150279 000 RQ --- 18:199184 13:112233 --:------ 0008 001 00
2021-12-25T16:47:21.239748 041 RP --- 13:112233 18:199184 --:------ 0008 002 0078
2021-12-25T16:47:21.364919 000 RQ --- 18:199184 13:112233 --:------ 3EF1 001 00
2021-12-25T16:47:21.484235 041 RP --- 13:112233 18:199184 --:------ 3EF1 007 0001D501D5C8FF
2021-12-25T16:47:44.550058 093 I --- 37:204863 --:------ 37:204863 31DA 030 00EF007FFF37EF7FFF7FFF7FFF7FFFF800EF0101000000EFEF7FFF7FFF00
2021-12-25T16:47:49.385557 061 I --- 04:156243 --:------ 01:197498 3150 002 0536
2021-12-25T16:47:58.149872 054 I --- 04:068997 --:------ 01:197498 3150 002 01A6
2021-12-25T16:47:59.335258 081 I --- 04:069001 --:------ 01:197498 3150 002 0454
2021-12-25T16:48:04.828907 073 I --- 34:245641 --:------ 34:245641 30C9 003 00081F
2021-12-25T16:48:05.126139 070 I --- 34:177017 --:------ 34:177017 30C9 003 0008A7
2021-12-25T16:48:10.199443 000 RQ --- 18:199184 01:197498 --:------ 0006 001 00
2021-12-25T16:48:10.527519 000 RQ --- 18:199184 01:197498 --:------ 0006 001 00
2021-12-25T16:48:10.750931 078 I --- 34:090069 --:------ 34:090069 30C9 003 00082E
2021-12-25T16:48:12.135373 000 RQ --- 18:199184 01:197498 --:------ 0006 001 00
2021-12-25T16:48:14.135343 000 RQ --- 18:199184 01:197498 --:------ 2E04 001 FF
2021-12-25T16:48:16.147969 000 RQ --- 18:199184 01:197498 --:------ 2E04 001 FF
2021-12-25T16:48:18.145602 000 RQ --- 18:199184 01:197498 --:------ 2E04 001 FF
What a legend, still offering support on Christmas day!
My “invalid verb/code” warnings and associated QoS messages seem to have gone away after a second schema rebuild (although a diff of the new vs old schema shows no differences.) My suspicion is that these messages are somehow related to the electric zone type, not zone valve, as I used to see them when my zone 8 was configured as an electric zone. Maybe after I first rebuilt the schema following the configuration change to zone valve there was still some state left over?
Anyway, if it’s useful my current schema is as follows.
{
"version": 1,
"minor_version": 1,
"key": "evohome_cc",
"data": {
"client_state": {
"schema": {
"main_controller": "01:225826",
"01:225826": {
"system": {
"heating_control": null
},
"orphans": [],
"stored_hotwater": {},
"underfloor_heating": {},
"zones": {
"00": {
"_name": "Living room",
"heating_type": "radiator_valve",
"sensor": "34:118197",
"sensor_alt": "34:118197",
"devices": [
"04:044935",
"04:044929",
"04:044933",
"34:118197"
],
"actuators": [
"04:044935",
"04:044929",
"04:044933"
]
},
"01": {
"_name": "Cinema room",
"heating_type": "radiator_valve",
"sensor": "22:247202",
"sensor_alt": "22:247202",
"devices": [
"04:044931",
"22:247202"
],
"actuators": [
"04:044931"
]
},
"02": {
"_name": "Study",
"heating_type": "radiator_valve",
"sensor": "22:134470",
"sensor_alt": "22:134470",
"devices": [
"04:044937",
"22:134470"
],
"actuators": [
"04:044937"
]
},
"03": {
"_name": "Spare room",
"heating_type": "radiator_valve",
"sensor": "04:044943",
"sensor_alt": "04:044943",
"devices": [
"04:044943"
],
"actuators": [
"04:044943"
]
},
"04": {
"_name": "Guest room",
"heating_type": "radiator_valve",
"sensor": "04:044941",
"sensor_alt": "04:044941",
"devices": [
"04:044941"
],
"actuators": [
"04:044941"
]
},
"05": {
"_name": "Bedroom 2",
"heating_type": "radiator_valve",
"sensor": "04:044939",
"sensor_alt": "04:044939",
"devices": [
"04:044939"
],
"actuators": [
"04:044939"
]
},
"06": {
"_name": "Bedroom",
"heating_type": "radiator_valve",
"sensor": "34:123457",
"sensor_alt": "34:123457",
"devices": [
"04:256404",
"04:256402",
"34:123457"
],
"actuators": [
"04:256404",
"04:256402"
]
},
"08": {
"_name": "Garden room",
"heating_type": "zone_valve",
"sensor": "22:237373",
"sensor_alt": "22:237373",
"devices": [
"22:237373"
],
"actuators": []
}
}
},
"orphans": [
"13:076092"
],
"device_hints": {}
},
The orphan is actually the BDR for the Garden room zone valve.
Previously, zone 8 looked like this:
"08": {
"_name": "Garden room",
"heating_type": "electric_heat",
"sensor": "22:237373",
"devices": [
"22:237373",
"13:076092"
]
}
This zone actually fires a proprietary single-zone UFH pump/mixing valve using the zone valve’s orange wire, and is a very small UFH zone (the only one in the house). I’ve re-configured as a zone_valve from electric_heat for now as, being a very small UFH zone, it seems the system was poorly specified and the boiler struggles to module down low enough when the demand is low and causes it to trip out. So I’m now using a zone valve configuration to dissipate some heat through some always-open radiators. Not ideal but I’ll keep it like this until I can get someone to fix it properly.
I’m sorry - ser2net is not officially supported. It creates big propagation delays (and other things), that may be the cause of your issue (I can’t see any another reason).
Do let me know if you get the same issues when you don’t use it.
I will add this code:
_LOGGER.warning(
"Windows " if os.name == "nt" else "This type of serial interface "
"is not fully supported by this library: "
"please don't report any Transport/Protocol errors/warnings, "
"unless they are reproducable with a standard configuration "
"(e.g. linux with a serial port"
)
I am merely hiding from the kids.
The schema from evohome_cc is what it is running, but doesn’t tell you why it has that schema.
How the schema is built is a complex thing, but it is either:
a) restored from cache if configured to do so via restore_state: true,
or;
b) built from the configuration file
It (there may be no schema initially) is then filled out via discovery (and possibly eavesdropping). The schema in the configuration.yaml should be as thin as possible - the one in the cache is likely to be ‘complete’.
It seems to me you continued to use a cached schema when you re-configured the zone type?
No, when I reconfigured the zone type I set restore_state to false and restated HA, then I set it back to true shortly after. The warnings continued every 15 mins until yesterday when I again set restore_state to false and restated. Other than a single occurrence just after this restart, I’ve not seen the warnings again.
The schema I posted earlier is my cached schema in .storage/evohome_cc. My configuration doesn’t specify any schema information, other than my controller ID.
I also no longer see 0008 001 08 RQs being sent to the controller (according to the packet log) which is what was triggering the warnings. (Note however these were regularly sent when the zone was configured as electric.)
I’ll let you know if I see it again.
I suppose it’s possible I forgot to save the file when initially setting restore_state to false 