Closed jasperb-iot closed 2 years ago
MsgTransport.write(RQ --- 18:000730 01:072888 --:------ 002 0004): no dispatcher
These messages can be ignored - they were debug code, and have since been removed. The issue they were highlighting for me won't be affecting you.
You can stop obscuring your device_id
s - there is no value in doing so (but do continue to do so if you wish).
Generally: please cut-and-paste text instead of providing screen captures.
Inconsistent schema: 04:056057 (02): None cant change parent (01:145038_02 (RAD)_02 to 01:145038_00 (RAD)_00) (try restarting the client library)
It really depends if this is a one-off, or it happens a often. If a one-off, then it likely to be a corrupt packet.
Otherwise: I cannot be 100% certain, unless I see a packet log form your system (please feel free to PM me one), but:
An example would be where a TRV was - in the past - moved from one zone to another, but not removed form the old zone. The only way to remove a TRV from a zone (via the evohome UI) is to delete/recreate that zone.
If you want, PM me a packet log - or simply close this issue. Please tell me if you have eavesdropping on (generally: don't).
Hi, thank you for your replies and comments.
I indeed replaced one failing TRV once. It was never removed from the zone and the zone was never deleted. Do you suggest to delete the zone and add the current TVR's back?
I created this post because the restore cache doesn't work. If I disable restore from cache, everything is working fine. When cache is enabled everything is and stays unavailable. Is this caused by the removed TRV?
Eavesdropping is disabled. I enabled it during installation. How can I create a packet log and PM it to you?
I indeed replaced one failing TRV once
It is a misconfigured TRV (child of two zones), not a missing TRV, that would cause this issue.
Send me a packet log, and/or the config/.storage/ramses_cc file - you can ask on the community forum for the details of this... or you try to simply re-create zone 0, zone 2 - I'd probably want to look at the schema first.
I created this post because the restore cache doesn't work.
Not sure - packet log please. It won't be cause by a missing TRV - there is no such concept.
How can I create a packet log and PM it to you?
Post a message on the community forum & I'll ping you
Hi,
After removing the affected zone and recreating it, the errors disappeared. I can now use the cache function.
2022-07-04 15:28:27 WARNING (MainThread) [custom_components.evohome_cc.schema] Using a Schema restored from cache: {'main_controller': '01:072888', '01:072888': {'system': {'heating_control': '13:090460'}, 'orphans': [], 'stored_hotwater': {}, 'underfloor_heating': {}, 'zones': {'00': {'_name': 'Woonkamer', 'zone_type': 'radiator_valve', 'zone_sensor': None, 'sensor_alt': None, 'devices': ['04:023497', '04:023501', '04:147405'], 'actuators': ['04:023497', '04:023501', '04:147405']}, '01': {'_name': 'Entree', 'zone_type': 'radiator_valve', 'zone_sensor': '04:023285', 'sensor_alt': '04:023285', 'devices': ['04:023285'], 'actuators': ['04:023285']}, '02': {'_name': 'Keuken', 'zone_type': 'radiator_valve', 'zone_sensor': '04:023503', 'sensor_alt': '04:023503', 'devices': ['04:023503'], 'actuators': []}, '03': {'_name': 'Zolder', 'zone_type': 'radiator_valve', 'zone_sensor': '04:147415', 'sensor_alt': '04:147415', 'devices': ['04:147415'], 'actuators': ['04:147415']}, '04': {'_name': 'Bijkeuken', 'zone_type': 'radiator_valve', 'zone_sensor': '04:023293', 'sensor_alt': '04:023293', 'devices': ['04:023293'], 'actuators': ['04:023293']}, '05': {'_name': 'Slaapkamer', 'zone_type': 'radiator_valve', 'zone_sensor': '04:023295', 'sensor_alt': '04:023295', 'devices': ['04:023295'], 'actuators': ['04:023295']}, '06': {'_name': 'Garderobe', 'zone_type': 'radiator_valve', 'zone_sensor': '04:023297', 'sensor_alt': '04:023297', 'devices': ['04:023297'], 'actuators': ['04:023297']}}}, 'orphans': [], 'device_hints': {}}
I do see invalid addresses in the packet log. I don't have devices which start with "37" How can I avoid this? I have an allow list in configuration.yaml
configuration.yaml part:
#Honeywell HGI80
evohome_cc:
serial_port:
port_name: /dev/serial/by-id/usb-Texas_Instruments_TUSB3410_Boot_Device_TUSB3410-if00-port0
packet_log: evohome_cc.log
schema:
controller: 01:072888
restore_cache: true
ramses_rf:
restore_state: true
enable_eavesdrop: false
enforce_allowlist: true
enforce_known_list: true
allow_list:
- "04:023497": {"alias": "--Woonkamer raam--"}
- "04:023501": {"alias": "--Woonkamer convectie--"}
- "04:147405": {"alias": "--Woonkamer aquarium--"}
- "01:072888": {"alias": "--EVO Touch--"}
- "04:023285": {"alias": "Entree"}
- "04:147415": {"alias": "Zolder"}
- "04:023293": {"alias": "Bijkeuken"}
- "04:023295": {"alias": "Slaapkamer"}
- "04:023297": {"alias": "Garderobe"}
- "04:023503": {"alias": "Keuken"}
- "13:090460": {"alias": "heating_control"}
- "18:013466": {"alias": "HGI80"}
known_list:
- "04:023497": {"alias": "--Woonkamer raam--"}
- "04:023501": {"alias": "--Woonkamer convectie--"}
- "04:147405": {"alias": "--Woonkamer aquarium--"}
- "01:072888": {"alias": "--EVO Touch--"}
- "04:023285": {"alias": "Entree"}
- "04:147415": {"alias": "Zolder"}
- "04:023293": {"alias": "Bijkeuken"}
- "04:023295": {"alias": "Slaapkamer"}
- "04:023297": {"alias": "Garderobe"}
- "04:023503": {"alias": "Keuken"}
- "13:090460": {"alias": "heating_control"}
- "18:013466": {"alias": "HGI80"}
trace log attached.
Your config is a mix of the old scheme (<= 0.19.x) and the new (>= 0.20.x). For example, you only use one of known_list
(newer) or allow_list
(older), depending upon which version of the code you are using.
Below is the version for version 0.20.x.
You use enforce_known_list
to exclude the orphan/alien devices from HA - note: they will still be still logged in the packet log - just ignore them.
FWIW - I have never seen so many 37:xxx
devices (heat recovery/ventilation units) - you must be living in a block of apartments? DO you have a ventilation unit in your house?
evohome_cc:
serial_port:
port_name: /dev/serial/by-id/usb-Texas_Instruments_TUSB3410_Boot_Device_TUSB3410-if00-port0
packet_log: evohome_cc.log
restore_cache: true
ramses_rf:
enable_eavesdrop: false
enforce_known_list: true
schema:
controller: 01:072888
known_list:
- "01:072888": {"alias": "--EVO Touch--"}
- "04:023497": {"alias": "--Woonkamer raam--"}
- "04:023285": {"alias": "Entree"}
- "04:023293": {"alias": "Bijkeuken"}
- "04:023295": {"alias": "Slaapkamer"}
- "04:023297": {"alias": "Garderobe"}
- "04:023501": {"alias": "--Woonkamer convectie--"}
- "04:023503": {"alias": "Keuken"}
- "04:147405": {"alias": "--Woonkamer aquarium--"}
- "04:147415": {"alias": "Zolder"}
- "13:090460": {"alias": "heating_control"}
- "18:013466": {"alias": "HGI80"}
Hi, thanks again.
There are three story apartments on the other side of the road, but not that many.
I have a ITHO ventilator unit in house which I control via MQTT. I have pulled the plug, 37:xxx messages are still coming in, so it's not this unit.
I guess I can just ignore it, right?
Yes: the known_list
limits what is passed up to HA - you can ignore the packet log (which will have all packets seen by the USB dongle).
There must be at least two-dozen 37: devices...
One (some, if you have a remote, and/or a sensor) of them is yours - if you can work out which, then add it too... The ventilator's sensors will show up in HA as well (and soon, you will be able to control it via ramses_cc).
I suggest you run version 0.20.x (a beta/pre-release).
Hi
I managed to fully add evohome_cc to HA, however when I set 'restore_cache' to 'true', it gives an error in HA. Leaving 'restore_cache' to 'false' works fine, however load times are long.
Any ideas how to fix this? I would like to use the cache option to improve performance