Packet log please!
Iāve updated to 0.16.4 and so far so good. I have no āsending is disabledā message and the system seems to work as expected. 
Anyone could send me 24h packet logs please - especially if UFH, or an R8820A.
For those with UFH - are you seeing a zoneās heat_demand?
Could you pm me a list (make/model) of all your MVHR bits - fans, switches, sensorsā¦
Yes i see. I Will send you my log tomorrow
Thank @zxdavb Iāve updated to 16.4 with the restore_state: true option now and all seems well so far.
With the latest 0.16.4 update or are older ones fine? I do not (yet) have heat_demand for UFH zones. Everything else is working fine.
And something else I wasnāt able to find where restore_state: true should be placed, is it under ramses_rf: or directly under evohome_cc:?
BTW:
NOTE: If you add or remove a zone, or move/add/remove a device, you must rebuild the state cache from scratch
Here is a challange for anyone with a HVAC unit:
python client.py monitor /dev/ttyUSB0 -X scan_hard 32:123456 -o scan_hard.log
Where 32:123456 is the device ID of your ventilation unit.
If you can manage that, please send me the log file.
After running 0.16.4 for something more then 12hours, most climate entities go to a unknow state.
Config:
evohome_cc:
serial_port: /dev/ttyUSB0
scan_interval: 60
packet_log: /config/evohome_cc_packet.log
ramses_rf:
enforce_known_list: true
schema:
controller: 01:223036
system:
heating_control: 10:040239
known_list:
- 01:223036
- 10:040239
- 04:231770
- 04:231772
- 04:231774
- 04:231776
- 04:050559
- 04:155445
- 04:155403
- 04:081849
- 04:155443
- 04:155407
- 04:155551
- 04:155533
- 04:155537
Iām seeing the same. Also, Iām noticing that it also forgets the mode and preset_mode fields after a few hours too. I only noticed this because I display these values in a custom card and they flag up as null at the moment, or crash the logic processing in the cardās code because it wasnāt expecting null values (ok, that bitās my fault for not writing better code).
Iāve remembered why I had ārestore_state: falseā option now. If I have it as true, my devices seem to time out as unknown, and eventually all of the names drop to lower-case and punctuation-free. But if I set it to false, I get all of the correct details straight away. Ok, so the trade-off is that some of the entities (like batteries and windows) donāt have a status until the next poll, but it was preferable to have that than an unavailable climate device with a strangely formatted name. See the screenshots:
ārestore_state: trueā:
ārestore_state: falseā:
So, iāve been toying with this integration and my hardware for the last couple days, but still failing to understand all of it and have some questions.
I have a fairly simple setup:
- chronotorm cm927 (discovered as a 12:xxxxxxx entity), sensors created in HA for battery and temperature but always unavailable
- bdr91 relay (discovered as a 13:xxxxxx entity), with sensor data visible in HA
- nanocul with evofw3 (discoverd as a 18:xxxxxxx entity), config sensor data showing up
In the packet.log I can see a ton of requests from the nanocul to the relay, which it does to populate the relay sensor data in HA I guess.
I would have expected to also see requests from the cm927 to the relay from either my manual use of the cm927 or the programmed schedule it has, but nothing like that is to be seen in the packet logs. The only lines containing the cm927 id are all of the āIā kind like this:
2021-11-11T14:51:45.451848 049 I --- --:------ --:------ 12:132867 1030 016 01C80137C9010FCA0196CB010FCC0101
Is this normal or should I be seeing the 12:xxxxxx to 13:xxxxxx requests too?
I also see no climate entity in HA, but I understand that is because sending commands to the bdr91 via a nanocul is not supported yet?
Or do I need to bind the nanocul to the bdr91 to get a climate entity?
Because my cm927 has a failing display Iām planning on replacing it. Iād hoped to use the nanocul and this integration as a replacement, but if thatās not possible in the near future and say I get a Lyric T6, would I then be able to control the relay via this integration in some way?
Iāve tried to do the scan_hard as requested, but I run into a problem running the python client.py (never done it before so I may be missing something obvious).
I installed everything as explained in the post here. It s dated from May 2020 so might not be valid anymore but could find other instructions in the thread.
I installed everything on a spare RPi I have with my HGI80 connected to it (I wanted to avoid messing up my HA computer and also Iām running hassio which does not seem to let you run python easily).
Unfortunatelly, each time I try to run the any command involving client.py I have the following error message:
Traceback (most recent call last):
File "client.py", line 22, in <module>
from ramses_rf import Gateway, GracefulExit, is_valid_dev_id
File "/home/pi/temp/evohome_rf/ramses_rf/__init__.py", line 24, in <module>
from .devices import Device, create_device
File "/home/pi/temp/evohome_rf/ramses_rf/devices.py", line 1050
elif zone_idx := msg.payload.get("zone_idx"):
^
SyntaxError: invalid syntax
If anyone can point me in the right direction I would be gratefull.
(you need to run 3.9 or greater, really, on you Pi)
Send me your logs - HA and packet log - I think I have an idea whatās going on - I think unrelated to restoring state, but letās see
Welcome
Chromotherm support is currently experimental. The BDR91 shoudl be fine.
I canāt recall the answer - the CM927 may just be broadcasting stuff, and the BDR91 just listens - there is precedent for this - Iād have to see the packet logs.
This 1030 pkt, essentially, is an artifact.
No - Iād have to do things.
Consider getting a Y87RF or similar (round thermostat) - it is compatible with the BDR91 you already have, and gives you the option of an RFG100 to get access via the Internet - these can be picked up cheaply. Then you can have access via the officially supported evohome integration.
The Lyric is not compatible with RAMSES_II, the RF protocol used here. If you buy a Lyric, youāll have to re-wire your boiler with a different relay.
Please send me a HA/packet log pair - also indicate what time things went unavailableā¦
I have an idea what is going on - nothing to do with restore_state, I think.
The good news is, I now whatās going onā¦ The bad news is, Iām going senile.
Fix coming.
2 Likes