I’d say what has happened is that you’ve blown the RF duty cycle on the HGI80 (evofw3 devices don’t suffer from this issue).
If I am right, the system simply won’t transmit, but there’s no way of knowing this specifically: you will simply see what you’re describing.
This can happen if you restart HA a few times in a short period of time, and especially so if you are not using the restore_state cache.
The only thing you can do is power off ( the HGI80 and then restart HA.
Rebooting hgi80 and HA, power whole system down, take adapter out wait 1 minute, doesn’t work isseu Stay same. As long it is running i can set temperature, the main controller Will show the updates and demand Will update, so the hgi80 transmit ?
If you can set the temperature by evohome_cc, then the HGI80 must be transmitting OK.
OK, let’s reset…
What is the issue you want resolving? Many of the HA log errors can be ignored.
Do you get the same behavior on 0.16.26 and 0.16.30?
Version 0.17.0 has been released as a pre-release. It exposes boiler state flags.
I need people with OpenTherm bridges (R8810A, R8820A), or the new BDR91T relays (specifically if connected to a heat pump, or being used for cooling).
It may be that your system doesn’t expose all flags - YMMV.
The Latest Stable release remains available if things go wrong.
Due to a suspected plumbing issues I have, for the time being, re-configured a zone that was previously an “Electric” type to “Zone Valve”. (Although previously configured as electric, it is actually a zone valve which switches the boiler via the orange wire independently of the main circuit; I’ve now set it as a Zone Valve zone so that the main circuit’s BDR also comes on at the same time.) I re-built my schema after doing this.
Like with the electric zone I see the following warnings in the log:
RQ --- 18:204306 01:225826 --:------ 0008 001 08 < Corrupt packet: Invalid verb/code for 01:225826 to Rx: RQ/0008
and
PktProtocolQos.send_data(sent=0008|RQ|01:225826|08): boff=3, want=0008|RP|01:225826|08, tout=2021-12-21T10:30:06.810: QoS: IS_EXPIRED (giving up) (2/2)
(Note, the zone in question is Zone 08, which I guess is what the payload is referring to.)
The packet log confirms that the following RQ packets are sent to the controller with no response:
2021-12-21T10:30:04.728182 000 RQ --- 18:204306 01:225826 --:------ 0008 001 08
2021-12-21T10:30:04.833085 000 RQ --- 18:204306 01:225826 --:------ 0008 001 08
2021-12-21T10:30:05.233128 000 RQ --- 18:204306 01:225826 --:------ 0008 001 08
The following 0008 packets (sent to zone 08’s BDR with 00 message code) do get responded to:
2021-12-21T10:30:12.726093 000 RQ --- 18:204306 13:076092 --:------ 0008 001 00
2021-12-21T10:30:12.736138 048 RP --- 13:076092 18:204306 --:------ 0008 002 0000
As do those sent to the boiler relay BDR:
2021-12-21T10:30:16.802777 000 RQ --- 18:204306 13:032648 --:------ 0008 001 00
2021-12-21T10:30:16.813626 041 RP --- 13:032648 18:204306 --:------ 0008 002 006A
Bug, or something to be ignored? It looks like a bad query is being sent to the controller for the Zone Valve/Electric zone types, which the controller consistently ignores.
This is version 0.16.30.
Just updated! I will keep you posted!
Not related to the latest update, but looks like there is a typo in the name of the service evohome_cc.set_zone_config. It shows “RAMSES RF: Reset a zone’s config” and should be Set
The window and battery state of version 0.17.0 are unavailable.
it has been running for about 8hours
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
restore_state: true
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
Sorted - thanks.
Anyone else have this issue? These packets don’t come that often, so I’d reboot HA & give it 24 hours.
It seems to stabilize … the time that it fails becomes longer and longer (from 1 1/2 hour… to 4 hours, to half day, then 1 item dropped (heat_demand), which was the first indicator that in ~ 30 minutes all would be not available, now recoverd …
So now it is running stable for 1.5 day.
The issue was the same but the error was different :
16:26 :
2021-12-18 00:48:36 WARNING (MainThread) [ramses_rf.protocol.transport] PktProtocolQos.send_data(sent=30C9|RQ|01:085674|02): boff=3, want=30C9|RQ|01:085674|02, tout=2021-12-18T00:48:36.646: QoS: IS_EXPIRED (giving up) (2/2)
vs
16:30
2021-12-18 01:23:17 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-18T01:23:17.753: QoS: IS_EXPIRED (giving up) (0/0)
This error shows up ever ~ 30 seconds in the log…
which is still the case…
In case of 10 i could understand something, since it is heating for module “10” (opentherm) is disabled.
I use a heatpump in “WAR” and use currently evo only as rooms temperature controller
Mine have been unavailable after updating yesterday morning. Tried a restart and I’ll give it a little longer.
I had renamed the entity_id of the battery state sensors. After updated to 0.17.0 these old sensors didn’t work but there a new sensors created for the battery state. They have the original generated entity_id name and these works immediately.
Battery state is now getting faster than before even from the room sensor most far away.
Get this warning even the 13:147080 is added to the known_list in my configuration file. I have found this same warning also in my 24-hour log of 0.16.24.
2021-12-22 11:45:16 WARNING (MainThread) [ramses_rf.protocol.transport] Blocking packets with device_id: 13:147080 (is not whitelisted), if required, add it to the known_list
I’ve just checked and also have new sensors.
Could you share an example? Perhapse I’m looking in the wrong place
So binary_sensor.04_155533_window changed to binary_sensor.04_155533_window_open
So binary_sensor.04_155403_battery changed binary_sensor.04_155403_battery_low
@zxdavb it solved, apparently it’s renamed
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.