🐛 monotone reconcile skips small backward corrections #66
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "monotone-reconcile"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Stop the HA recorder
total_increasingwarnings (state is not strictly increasing...) that spam the logs every hour on the Comwatt*_total_energysensors.Problem
PR #64 made the hourly reconciliation against server
QUANTITY/HOURbuckets unit-aware, but it applies EVERY backward correction. Measured live backward drift is small (~0.05 to 2.6 Wh/h per device) but constant — each one makes HA recorder log a WARNING. The*_total_energysensors arestate_class: TOTAL_INCREASING, so any backward state-change is flagged.Fix
_RECONCILE_BACKWARD_DRIFT_TOLERANCE_WH = 5.0._fetch_device_metricsreconciliation (else:branch when the stream owns the live total), afterval_wh = _server_bucket_to_wh(val, live_wh):correction >= 0): apply as before (the common case — missed stream samples under-count).-correction > 5.0): apply the snap as before (genuine drift must be corrected — once PR #65 persists the live total across restarts, skipping ALL backward corrections would lock in permanent over-counting).0 < -correction <= 5.0): SKIP the correction — don't mutatelive_total_wh, don't overwritelive_by_hour[hour]. The bucket is still marked done (last_bucket_ts = bucket_dtruns unconditionally) so it's not reconsidered. The entity state stays unchanged ⇒ no recorder warning.sensor.py/ entitystate_classunchanged.Tests
4 new (RED→GREEN): small-backward skip + HWM not reconsidered, large-backward snap, inclusive boundary at exactly 5 Wh, forward-unchanged regression guard. 84 total passing, ruff + mypy clean. Existing
test_reconcile_*audited — every backward correction uses −10 Wh (> tolerance), all stay GREEN unchanged.Scope
coordinator.py+tests/test_coordinator.pyonly. Basemain.Interaction with PR #65 (persist-energy-state)
Orthogonal semantics. #65 touches the
if live_total is Nonelegacy-seed path; this slice touches theelse:reconciliation branch. A trivial textual conflict may occur on shared context lines if this slice merges first — resolvable by keeping both sets of additions (no shared logic). Merging #65 first avoids it.The *_total_energy sensors declare state_class: TOTAL_INCREASING. Most hourly backward corrections from the server QUANTITY/HOUR bucket are tiny drift (measured live: ~0.05 to 2.6 Wh/hour); each one made HA recorder log a WARNING ("state is not strictly increasing... please create a bug report"), spamming logs. Large backward corrections, however, indicate genuine drift and must still be applied — otherwise (with the live total now surviving restarts via PR #65) skipping them all would lock in permanent over-count forever. Introduce _RECONCILE_BACKWARD_DRIFT_TOLERANCE_WH = 5.0 (inclusive <=): backwards at or below the tolerance are skipped silently (live total and live_by_hour[hour] unchanged; high-water mark still advances so the bucket is not reconsidered next fetch), forwards and large backwards still snap. Document the rationale in the _fetch_device_metrics docstring. Add four tests (skips small backward, applies large backward, boundary at tolerance is skipped, forward correction unchanged). Audit of existing reconcile tests confirms none use a backward correction within (0, 5] Wh, so none broke and none required modification.WIP: fix: monotone reconcile skips small backward corrections (Problem 2)to WIP: 🐛 monotone reconcile skips small backward corrections (Problem 2)WIP: 🐛 monotone reconcile skips small backward corrections (Problem 2)to WIP: 🐛 monotone reconcile skips small backward correctionsWIP: 🐛 monotone reconcile skips small backward correctionsto 🐛 monotone reconcile skips small backward corrections