fix(sensors): treat 0.0 solar accuracy as a real value, not 'missing' (#892)#892
Open
jackmcintyre wants to merge 1 commit into
Open
fix(sensors): treat 0.0 solar accuracy as a real value, not 'missing' (#892)#892jackmcintyre wants to merge 1 commit into
jackmcintyre wants to merge 1 commit into
Conversation
…#892) ForecastAccuracyComparisonSensor used `if localshift_accuracy:` (truthiness) in four places, which treats a genuine 0.0% accuracy — a terrible forecast where every sample was wrong — identically to None (unavailable). The sensor would then report only the Solcast-derived value (or None) instead of the blend, and the localshift_accuracy_pct attribute would collapse to None. Replace every truthiness check with `is not None` so 0.0 flows through the blend branch correctly. TDD: two failing tests first (blend with 0.0 + Solcast reported 90.0 instead of 45.0; 0.0 alone reported None instead of 0.0), then fix. 3216 tests pass.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
ForecastAccuracyComparisonSensorusedif localshift_accuracy:(truthiness) in four places, which treats a genuine 0.0% accuracy — a terrible forecast where every sample was wrong — identically toNone(unavailable). The sensor would then report only the Solcast-derived value (orNone) instead of the blend, and thelocalshift_accuracy_pctattribute would collapse toNone.This is a latent correctness bug — only bites when accuracy is exactly 0.0 — but it masks the underlying value and breaks the blend branch in exactly the scenario where the LocalShift-tracked value matters most (systematic forecast failure).
Changes
Replaced every
if localshift_accuracywithif localshift_accuracy is not Noneincustom_components/localshift/sensors/solcast.py:localshift + solcast/ 2).localshift_accuracy_pctattribute emission.Validation
test_zero_accuracy_is_not_treated_as_missing— 0.0 alone must report 0.0, not None.test_zero_accuracy_blended_with_solcast— 0.0 + MAPE 10% must blend to 45.0, not skip to Solcast's 90.0.Out of scope
The live
sensor.localshift_solar_forecast_accuracyreadingunknownis a separate root-cause issue (coverage gate intick_scheduler._backfill_solar_actualtoo strict — 70 pending, 0 samples). Tracked in a follow-up issue. This PR only fixes the truthiness handling so that when accuracy DOES populate, 0.0 is reported correctly.