fix: don't slow EMA smoother across zero-crossings for high alpha#373
Conversation
The sign-flip "catchup" branch in SmoothedPowermeter was meant to react faster when raw power crosses zero by boosting the effective alpha to `alpha * 4`, capped at 0.5. But `min(0.5, alpha * 4)` is only a boost while `alpha < 0.125`; for any larger configured alpha it just clamps to 0.5, and for alpha > 0.5 it actively reduces the step. Users running near self-consumption with a high `SMOOTH_TARGET_ALPHA` (e.g. 1.0 for instant tracking) therefore saw randomly halved deltas whenever the raw reading happened to straddle zero, often dragging the smoothed value back into the deadband and snapping it to 0. Raise the catchup alpha to at least the configured alpha so the branch can only ever speed the smoother up, never slow it down. Refs #371
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
WalkthroughThis PR fixes EMA smoothing responsiveness when crossing zero in power meter readings. The catchup logic now respects high ChangesEMA Smoothing Catchup Responsiveness
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary
Fixes #371.
The sign-flip "catchup" branch in
SmoothedPowermeter(src/astrameter/powermeter/wrappers/smoothing.py:75) was intended to react faster when the raw total crosses zero by boosting the effective alpha toalpha * 4, capped at0.5:But
min(0.5, alpha * 4)is only a boost whilealpha < 0.125. For any larger configured alpha the result simply pins to0.5, and oncealpha > 0.5the branch actively reduces the step instead of accelerating it.Reported symptom: running close to full self-consumption with
SMOOTH_TARGET_ALPHA = 1.0(instant tracking) randomly halves the delta whenever the raw reading happens to straddle zero — so a1 → 101step moves the smoothed value by 100, while-1 → 99moves it by only 50, often dragging the smoothed value back insideDEADBANDand snapping it to 0.Fix
Raise the catchup alpha to at least the configured alpha, so the branch can only ever speed the smoother up, never slow it down:
0.1 → 0.4) the existing behaviour is preserved — that case still has a dedicated test (test_sign_change_catchup).alpha ≥ 0.5the branch becomes a no-op instead of a slowdown.Test plan
test_sign_change_catchupstill passes (alpha=0.1, expected delta unchanged).test_sign_change_does_not_slow_high_alphacoversalpha=1.0and asserts the sign-flip step is no longer halved.uv run ruff format .uv run ruff check .uv run mypy src/uv run pytest— 674 passed, 27 skipped (mosquitto-only tests).Generated by Claude Code
Summary by CodeRabbit
Bug Fixes
SMOOTH_TARGET_ALPHAis configured above 0.5. The catchup coefficient logic now correctly applies the configured alpha value without artificial capping, restoring expected behavior for high smoothing settings (issue#371).Tests