ComfoConnect.connect() implements a mitigation for a known bug in the bridge where, upon first connection, invalid 0 sensor values are emitted before real values are finally sent:
# Wait for a specified amount of seconds to buffer sensor values.
# This is to work around a bug where the bridge sends invalid sensor values when connecting.
From what I can tell reading the code, incoming sensor updates are held for sensor_delay seconds (default 2s) and after the delay, _unhold_sensors() forwards only the last cached value for each sensor. This should prevent the "startup garbage" from reaching the callback and in turn polluting statistics.
However, after a cold boot (HAOS/host reboot where the bridge fully disconnects for a non-trivial amount of time), I’m sometimes seeing invalid startup readings passed through. When it happens, it affects all sensors, but here's example data for one sensor extracted from my HA states table:
SELECT s.state_id, sm.entity_id, s.state, s.last_updated_ts
FROM states s
inner join states_meta sm on s.metadata_id = sm.metadata_id
where sm.entity_id like 'sensor.comfoair_q_days_to_replace_filter'
order by s.state_id asc
state_id entity_id state last_updated_ts
9117065 sensor.comfoair_q_days_to_replace_filter unknown 1762857244.5328326
9117601 sensor.comfoair_q_days_to_replace_filter 70 1762857246.297034
9140980 sensor.comfoair_q_days_to_replace_filter 69 1762898875.1175113
9164423 sensor.comfoair_q_days_to_replace_filter unknown 1762925364.8378952
9164990 sensor.comfoair_q_days_to_replace_filter 0 1762925364.839745
9165281 sensor.comfoair_q_days_to_replace_filter 69 1762925364.936789
The first three rows show normal behaviour, showing a ~2 second delay between unknown → 70. However looking at the last three rows, state moves from unknown → 0 → 69 within 0.1 seconds of each other, so it appears the 2 second sensor hold period did not work as intended?
From what I can tell reading the code, there's no opportunity for sensor_delay to be ignored, so this confuses me. If you can suggest what I can do to investigate further, and help narrow down the underlying cause, I'm happy to help.
ComfoConnect.connect()implements a mitigation for a known bug in the bridge where, upon first connection, invalid 0 sensor values are emitted before real values are finally sent:From what I can tell reading the code, incoming sensor updates are held for
sensor_delayseconds (default 2s) and after the delay,_unhold_sensors()forwards only the last cached value for each sensor. This should prevent the "startup garbage" from reaching the callback and in turn polluting statistics.However, after a cold boot (HAOS/host reboot where the bridge fully disconnects for a non-trivial amount of time), I’m sometimes seeing invalid startup readings passed through. When it happens, it affects all sensors, but here's example data for one sensor extracted from my HA
statestable:The first three rows show normal behaviour, showing a ~2 second delay between
unknown→70. However looking at the last three rows, state moves fromunknown→0→69within 0.1 seconds of each other, so it appears the 2 second sensor hold period did not work as intended?From what I can tell reading the code, there's no opportunity for
sensor_delayto be ignored, so this confuses me. If you can suggest what I can do to investigate further, and help narrow down the underlying cause, I'm happy to help.