Seem to be losing hot water state, shows Unknown:
Unavailable after around 4 hours, even though it has been on/off since then:
Temperature reports ok:
… rest seems to be good for me, heating zones have correct state, temperature etc
I forgot to say - you should be having something like this in your configuration.yaml:
evohome_cc:
schema:
controller: 01:145038
zones:
"07": {"sensor": {"device_id": "03:256029", "is_faked": true}}
If you ever are not using a cached schema, the discovered schema will include the is_faked.
@iMiMx Could you provide the specific times when the DHW setpoint gaps started/stopped - the corresponding packet log would be great.
Have just messaged it to you 
@iMiMx Not enough: on your first graph, the one with the light blue line - tell me the times the gaps started/stopped. Hover your mouse cursor over the line.
@iMiMx OK, I can do something with that:
MSG_TIMEOUTS = {
...
"10A0": {I_: timedelta(hours=2), RP: timedelta(hours=2)},
… becomes:
MSG_TIMEOUTS = {
...
"10A0": {RP: timedelta(hours=4)},
Can people report any other bugs - all I have so far is:
AssertionError: invalid device type
AttributeError: 'NoneType' object has no attribute 'encode'
These have all been fixed and will be ‘released’ soon.
[EDITED] Before I push another release - are there any more?
CorruptStateError
Got this at startup, maybe just a one-off…
055 RP --- 13:259021 18:070162 --:------ 3EF1 007 00012C012C00FF < Inconsistent state: 13:259021 (BDR) changed parent: 01:201047 (evohome) to 01:201047_00 (radiator_valve), (try restarting the client library)
Traceback (most recent call last):
File "/srv/homeassistant/lib/python3.8/site-packages/ramses_rf/message.py", line 711, in process_msg
update_entities(msg, msg._gwy._prev_msg) # update the state database
File "/srv/homeassistant/lib/python3.8/site-packages/ramses_rf/message.py", line 652, in update_entities
this._gwy.device_by_id[this.src.id]._handle_msg(this)
File "/srv/homeassistant/lib/python3.8/site-packages/ramses_rf/devices.py", line 1207, in _handle_msg
super()._handle_msg(msg)
File "/srv/homeassistant/lib/python3.8/site-packages/ramses_rf/devices.py", line 328, in _handle_msg
super()._handle_msg(msg)
File "/srv/homeassistant/lib/python3.8/site-packages/ramses_rf/devices.py", line 486, in _handle_msg
self._set_parent(self._ctl._evo._get_zone(msg.payload["parent_idx"]))
File "/srv/homeassistant/lib/python3.8/site-packages/ramses_rf/devices.py", line 505, in _set_parent
raise CorruptStateError(
ramses_rf.exceptions.CorruptStateError: Inconsistent state: 13:259021 (BDR) changed parent: 01:201047 (evohome) to 01:201047_00 (radiator_valve), (try restarting the client library)
I got this one but it’s not breaking anything
Logger: ramses_rf.message
Source: /usr/local/lib/python3.8/site-packages/ramses_rf/message.py:323
First occurred: June 21, 2021, 9:42:48 PM (166 occurrences)
Last logged: 10:52:51 PM
Message( I|04:164247|3150|04), received at 2021-06-22 20:32:30.972321: msg has tombstoned (0:40:20.604883, 0:20:00)
Message(RP|01:205114|313F), received at 2021-06-22 21:42:41.612285: msg has tombstoned (0:00:09.969086, 0:00:03)
Message( I|04:164247|3150|04), received at 2021-06-22 21:13:12.019577: msg has tombstoned (0:44:39.566576, 0:20:00)
Message(RP|01:205114|313F), received at 2021-06-22 22:42:41.574493: msg has tombstoned (0:00:10.014959, 0:00:03)
Message( I|34:018143|3120), received at 2021-06-22 20:51:02.685446: msg has tombstoned (2:01:48.908273, 1:00:00)
Also an unrelated question: all these device IDs mean nothing to me. I seem to have more IDs in my allow_list than i have devices (including the fake sensors). How can I ever find out which ID is which device? How do I know I’m not accidentally adding a neighbor’s device to my list… ?
Happens every 5 minutes or so, but everything appears to work normally…
055 RP --- 13:259021 18:070162 --:------ 3EF1 007 000053005300FF < Inconsistent state: 13:259021 (BDR) changed parent: 01:201047 (evohome) to 01:201047_00 (radiator_valve), (try restarting the client library)
056 RP --- 13:259021 18:070162 --:------ 3EF1 007 00012C012C00FF < Inconsistent state: 13:259021 (BDR) changed parent: 01:201047 (evohome) to 01:201047_00 (radiator_valve), (try restarting the client library)
055 RP --- 13:259021 18:070162 --:------ 3EF1 007 00012C012C00FF < Inconsistent state: 13:259021 (BDR) changed parent: 01:201047 (evohome) to 01:201047_00 (radiator_valve), (try restarting the client library)
Been following this thread now for quite a while and what is a bit confusing to me is whether you require a HGI80 or not. Can someone educate me on that point? I am under the impression that a 868mhz nanocul is all the hardware you need (aside from a working Evohome system with the radiator knobs, central unit and opentherm receiver)…
Oke tried this in de configuration.yaml and now the schema is good after a reboot without a cached schema, I will wait for a while and look if it stays good. After that i will try a reboot with cached schema on.
I had a drop-out to ‘unavailable’ at about 4am so I guess it wasn’t as fixed as I’d hoped 
I’ve enabled the logging levels you’ve requested so will DM you the logs when it fails again.
I noticed my climate.* entities became unknown over night:
If you trigger a change, it seems to re-learn/update the correct state - so hopefully it’s just a timeout or similar issue:
The rest of the various sensors seem to be ok
I guess you have eavesdropping enabled in your configuration.yaml?
enable_eavesdrop: true
If so…
Using this technology is to be discouraged, but I appreciate some require it. I would like to implement you a viable alternative. Please submit a issue at: Issues · zxdavb/ramses_rf (github.com) so that I can best attack the problem.
Call it “Eavesdropping causes CorruptStateError”
Please include the reasons why you’re needing eavesdropping - please remind me to add a logger warning people to use avoid using it.
These logger messages are not show-stopper errors and can be ignored - they are for my benefit.
The following is related to the above.
I have implemented a feature were stale packets are removed from the system. There are good reasons for doing so, but perhaps I am trying to be too clever about the way it is done…
I could tell you lots about it, but really, I just need useful logs please:
I would be grateful if someone opened an issue on Issues · zxdavb/ramses_rf (github.com), so that I can best attack track this problem.
After a few hours the schema stayed good, i just did a reboot with the cache on and then directly i have 5 orphaned devices. I turned off cache again and everything is good.