Skip to content

fix: always persist calibration after sampling, not only when correction moves - #198

Merged
bvweerd merged 1 commit into
devfrom
claude/fix-calibration-stuck-at-cap
Sep 27, 2026
Merged

bvweerd merged 1 commit into
devfrom
claude/fix-calibration-stuck-at-cap

Conversation

@bvweerd

@bvweerd bvweerd commented Sep 27, 2026

Copy link
Copy Markdown
Owner

Root cause

When the efficiency correction hits CALIBRATION_APPLY_MAX (1.05) — which happens when the battery consistently outperforms its configured curve — every new sample is recorded in the in-memory rolling window but record() returns moved=False. Because async_save() was only called when moved=True, the .storage file was never updated.

On every HA restart the stale file (still in the old raw_ratio schema) was loaded, _migrate_ratios() ran again, and the correction snapped back to 1.05. New samples kept coming in and hitting the cap, the file was never written, and the sensor value never changed — until a manual reset via the service call.

Fix

Save after every successful sample (CALIBRATION_SAMPLED), not only when the correction moves by more than CALIBRATION_SIGNIFICANT_CHANGE. This ensures:

  • The file is converted to the efficiency_factor schema on the first sample after startup, so subsequent restarts load clean data
  • The sample count in the file stays current
  • The sensor reflects actual sampling activity even when correction is at the cap

Test plan

  • python -m pytest tests/ -v — all 1052 tests pass
  • Deploy and verify last_result shows sampled after a charge/discharge step instead of staying at direction_not_planned
  • Verify .storage file is updated after each run (schema becomes efficiency_factor, sample count increments)

…ion moves

When the efficiency correction is at CALIBRATION_APPLY_MAX (1.05) every new
sample is added to the rolling window but record() returns moved=False, so
async_save() is never called. The file on disk then keeps the old raw_ratio
schema indefinitely and is re-migrated on every HA restart, resetting to
correction=1.05 each time. The sensor appears permanently stuck.

Fix: save after every successful sample (CALIBRATION_SAMPLED), not only when
the correction shifts by more than CALIBRATION_SIGNIFICANT_CHANGE. This keeps
the file in the current efficiency_factor schema and the sample count current,
so a reset is not needed to unblock the sensor.
@github-actions github-actions Bot added the bug Something isn't working as expected label Sep 27, 2026
@bvweerd
bvweerd merged commit 659fd5d into dev Sep 27, 2026
7 checks passed
@bvweerd
bvweerd deleted the claude/fix-calibration-stuck-at-cap branch September 27, 2026 17:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working as expected

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant