I have done this probably 5-6 time previously, when the issue was noticed originally - with the result always being the same.
Just to make sure, the below:
Should resolve this?
âŚ
Yes, there is a fix to specifically address your 000C packets: that are a little odd, as described before.
As youâd expect, I do test these fixes against the logs youâve already provided, but I also ask people to send up-to-date logs whenever there is an issue - even though I have the latest parser, the old logs were made with an old version of the engine, after all.
The truth is, experience has shown that debugging issues using logs made with older versions of the engine is incredible inefficient, and often ineffectiveâŚ
In any case, IIRC, your issue isnât exactly the same? That is, for some of your zones, all the actuators were missing, and now only some are missing for those zones?
Thatâs why I suggested:
Please rebind it to the zone. Please remove all hints for that zone. Reboot HA with no cache / no eavesdropping & see what happens.
This is from a previous post:
⌠and now: loook at actuators:
Having review your latest logs - I stand by my diagnosis: rebind the missing TRV to the zone (do both if you canât recall which is which), and let me know if that doesnât fix the problem.
To be clear: before ramses_rf wasnât decoding certain 000C packets (those which were âstrangeâ, and had more than one TRV/actuator), but now it is. Your zone 00 appears to have only one TRV bound.
If you wish, send the packet log of that process.
Some feedback after running 0.17.4 for a numer of days:
First, I have two HR92s (04:044933 and 04:256402) that have become orphans - there is no change to my evohome configuration and previous versions have correctly identified them with their respective zone. Restarting with restore_state: false does not help.
These HR92s each belong to zones with multiple HR92s, but they are not in the same zone as each other. I think whatâs happening is that for zones with multiple HR92s, the packet parser is dropping the last one from the 000C RP.
Here are examples from my log for what looks like incorrect decoding:
2022-01-08 12:16:37 INFO (MainThread) [ramses_rf.protocol.protocol] rcvd: RP --- 01:225826 18:204306 --:------ 000C 018 00000010AF8700000010AF8100000010AF85
2022-01-08 12:16:37 INFO (MainThread) [ramses_rf.message] || CTL:225826 | HGI:204306 | RP | zone_devices | 0000 || {'zone_idx': '00', '_device_class': '00', 'device_class': 'zone_actuators', 'devices': ['04:044935', '04:044929']}
and
2022-01-08 12:16:40 INFO (MainThread) [ramses_rf.protocol.protocol] rcvd: RP --- 01:225826 18:204306 --:------ 000C 012 06000013E99406000013E992
2022-01-08 12:16:40 INFO (MainThread) [ramses_rf.message] || CTL:225826 | HGI:204306 | RP | zone_devices | 0600 || {'zone_idx': '06', '_device_class': '00', 'device_class': 'zone_actuators', 'devices': ['04:256404']}
It looks like the raw RP for zone 00 correctly contains three actuators but it gets decoded as two: the AF85 corresponding to the orphan 04:044933. Similarly the RP for zone 6 appears to correctly contain two actuators, but the 3E992 (corresponding to orphan 04:256402) gets dropped,
The second thing Iâve seen with 0.17.4 is a big increase in expired messages for a number of message types. Having said that, Iâve just done another restart (with restore_state: false) and they seem to have settled. Iâll keep my eyes on this and report back with details if it continues.
If it helps, hereâs a packet log from today:
This contains two restarts: the first at 10:52 was with restore_state: true and the one at 12:16 was with restore_state:false.
(Edit: apologies I missed the last post which said there were some issues with multiple-actuator zones, however the log snippets above are from 0.17.4.)
Thank you for your very useful post - I have identified, and corrected this regression.
@iMiMx It appears I owe you an apology - my mistake was to rely upon the parser, without reviewing the underlying packet:
> cat .secrets/imimx/2022-01-05b.log | grep ' 000C 011 ' | python client.py -ns parse
...
09:43:21.506 || CTL:050858 | HGI:141846 | RP | zone_devices | 0000 || {'zone_idx': '00', '_device_class': '00', 'device_class': 'zone_actuators', 'devices': ['04:055514', '04:055594']}
09:43:21.967 || CTL:050858 | HGI:141846 | RP | zone_devices | 0008 || {'zone_idx': '00', '_device_class': '08', 'device_class': 'rad_actuators', 'devices': ['04:055514', '04:055594']}
A new drop will be coming later today - I will squeeze this fix in.
2 Likes
OK, version 0.17.6 released as a beta.
Adds some stuff for OTB, HVAC, and bugfixes.
Unfortunately I still see the same - 1 actuator, 1 missing device:
zones:
'00':
_name: Living Room
zone_type: radiator_valve
zone_sensor: '22:245508'
sensor_alt: '22:245508'
devices:
- '04:055514'
- '22:245508'
actuators:
- '04:055514'
evohome_cc:
restore_state: false
serial_port:
port_name: /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0
baudrate: 57600
packet_log:
file_name: /config/packet.log
rotate_backups: 3
ramses_rf:
enforce_known_list: true
max_zones: 8
schema:
controller: 01:050858
# zones:
# '00':
# devices:
# - '04:055594'
# - '04:055514'
known_list:
- 01:050858 # Controller
....
I restarted with restore_state: false - unfortunately my âpatch Sundayâ early morning maintenance window has had to end early, the house is waking up.
I shall try rebinding it, if you consider this to still be a good thing to rule out, tomorrow and will ping over a packet log for this latest version if it is of any use?
EDIT: Even though I selected beta and 0.17.6 from the down down, the version.py shows as:
__version__ = "0.17.4" # revision 0
So for a reason as yet unknown, it looks like it still installed 0.17.4 - will investigate this further and/or install manually.
EDIT 2: Not sure if this is a HACs bug, but it seems to show 0.17.6 out-of-order in the list (HACs did update as well, recently)
Reinstalling again and I have 0.17.6 - although perhaps related to the âout of orderâ listing, it seems to think that 0.17.6 is an older version to 0.17.4:
Again, not sure if this is a HACs bug, but it seems to change between showing the plugin as âRAMSES RFâ and âEvohome Ccâ, maybe this changes between restarts, or as HA is starting up etc.
When correctly running 0.17.6 it does indeed seem to resolve the problem - much obliged:
zones:
'00':
_name: Living Room
zone_type: radiator_valve
zone_sensor: '22:245508'
sensor_alt: '22:245508'
devices:
- '04:055514'
- '04:055594'
- '22:245508'
actuators:
- '04:055514'
- '04:055594'
My TRVs are also now back in the correct place using 0.17.6. Thanks.
@stevieb12345 I would love to see you run 0.17.6, and send me a packet log after youâve fiddled with all your HVAC (PIV) switches. Please go through all the modes (fan speed/fan off/heater on/boost/whatever)
Sorry - will be 0.17.7, or higher. your CO2 sensor should show up now, though.
I have deleted all the old releases - only two now - stable (older version) & pre-release (newer version).
i have got the next error in my log:
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 382, in async_add_entities
await asyncio.gather(*tasks)
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 520, in _async_add_entity
original_icon=entity.icon,
File "/config/custom_components/evohome_cc/sensor.py", line 141, in icon
return "mdi:radiator-off" if self.state == 0 else "mdi:radiator"
File "/config/custom_components/evohome_cc/sensor.py", line 124, in state
return state * 100 if state is not None else None
TypeError: unsupported operand type(s) for *: 'Message' and 'int'
Thereâs something unfortunate about the word ânextâ - sorry!
Help me a little:
- did this happen during startup (if it didnât, and now it does, donât
restore_statefor the next restart & see if that helps) - what version - does it happen with both versions
- did you change you evohome configuration
This is a heat_demand - the most complicated sensor, by far - may be difficult to get to the bottom off.
Anyone else have this issue?
@zxdavb I am sorry! I donât mean anything wrong with it. In Dutch we use ânextâ to indicate something in Dutch written language.
It happens after an update to version 17.6.
After a restart with restore_state: false, it doesnât popup anymore.
Can i support you with the itho fan part?
No, to be clear: Iâm not upset at all - it was irony - a joke I was making at myself. I think ânextâ was about right after what I did to @imimx & co.!
And it is now OK with restore_state: true - I wonder if it was a corrupt packet? The code should handle that, thoughâŚ
Do you use (or have you recently added) a known_list - do you have UFH or a Zone Valve zone?
The next drop has a lot of HVAC refactoring - switches, sensors, etc. So I will need help with that.
It also has a super special new feature!
When i set restore_state: true i get the old error again. I use UFH and valves.
I use as config:
evohome_cc:
serial_port: /dev/ttyUSB-EVOHOME
scan_interval: 60
packet_log:
file_name: /config/evohome_cc.log
rotate_backups: 3
restore_state: true
ramses_rf:
enforce_known_list: true
max_zones: 10
schema:
controller: 01:087939
system:
heating_control: 10:078099
known_list:
- 01:087939 # Controller
- 04:225661 # Badkamer
- 04:225663 # Slaapkamer Evi
- 02:017205 # Woonkamer
- 04:023992 # Kastenkamer
- 04:059569 # Slaapkamer
- 04:225657 # Toilet
- 04:024000 # Slaapkamer Nova
- 10:078099 # Heating control
- 18:073736 # Vloerverwarming (UFH)
advanced_features:
send_packet: false
message_events: true
Could you also take a look about the log config? it doesnât stop at 3 days. i have still the logs from 14 days and older.
This is a known bug. I had a quick look, and it needs a long look.
known_list:
- 01:087939 # Controller
- 02:017205 # Woonkamer (UFH controller)
- 04:023992 # Kastenkamer
- 04:024000 # Slaapkamer Nova
- 04:059569 # Slaapkamer
- 04:225657 # Toilet
- 04:225661 # Badkamer
- 04:225663 # Slaapkamer Evi
- 10:078099 # Heating control
- 18:073736 # Gateway (HGI80-compatible)
- 20:007902: {"class": "FAN"},
- 20:032436: {"class": "FAN"},
- 44:072017: {"class": "SWI"}
Please provide me with your latest packet logs (24-48h) - and a copy of the schema from the HA UI - look for 01:087939 (schema)
There will be a couple of restarts in my log files. Is that a problem?
No - I want all that. Also, I am just about you update your known_list, above, again.
Please let me know your Itho make/models.
log today: https://file.io/09XEyb0AeXXy
log 09-01-22: https://file.io/ysSjHNa7WxnX
log 08-01-22: https://file.io/0Xizd0ffuj9I
schema:
system:
heating_control: '10:078099'
orphans: []
stored_hotwater: {}
underfloor_heating: {}
zones:
'00':
_name: Woonkamer
zone_type: underfloor_heating
zone_sensor: null
sensor_alt: null
devices: []
actuators: []
'01':
_name: Badkamer
zone_type: radiator_valve
zone_sensor: '04:225661'
sensor_alt: '04:225661'
devices:
- '04:225661'
actuators:
- '04:225661'
'02':
_name: Slaapkamer Evi
zone_type: radiator_valve
zone_sensor: '04:225663'
sensor_alt: '04:225663'
devices:
- '04:225663'
actuators:
- '04:225663'
'03':
_name: Kastenkamer
zone_type: radiator_valve
zone_sensor: '04:023992'
sensor_alt: '04:023992'
devices:
- '04:023992'
actuators: []
'04':
_name: Toilet
zone_type: radiator_valve
zone_sensor: '04:225657'
sensor_alt: '04:225657'
devices:
- '04:225657'
actuators:
- '04:225657'
'05':
_name: Slaapkamer Nova
zone_type: radiator_valve
zone_sensor: '04:024000'
sensor_alt: '04:024000'
devices:
- '04:024000'
actuators:
- '04:024000'
'07':
_name: Slaapkamer
zone_type: radiator_valve
zone_sensor: '04:059569'
sensor_alt: '04:059569'
devices:
- '04:059569'
actuators:
- '04:059569'
friendly_name: 01:087939 (schema)
Do i also have to add this:
- 20:007902: {"class": "FAN"}
- 20:032436: {"class": "FAN"}
- 44:072017: {"class": "SWI"}
to my known_list?