Skip to content

docs(output-data): correct savings_total_predbat's description (#3894) - #5081

Merged
springfall2008 merged 1 commit into
mainfrom
fix/savings-total-docs-3894
Sep 14, 2026
Merged

springfall2008 merged 1 commit into
mainfrom
fix/savings-total-docs-3894

Conversation

@chalfontchubby

Copy link
Copy Markdown
Collaborator

Posted by Claude on behalf of @chalfontchubby.

Problem

docs/output-data.md described predbat.savings_total_predbat as "a running total... of the below savings_yesterday_predbat sensor" - implying it sums that sensor's own displayed state. It never has: the sensor's state is the adjusted saving (factors in the day's battery-value change), while the total accumulates the real, unadjusted figure - deliberately, per @springfall2008 on #3894 ("the total savings is meant to be based on real data, if you use adjusted its not a true savings").

That's the root of #3894: a user sees the daily bars dip negative (adjusted) next to a total that keeps climbing (real) and reasonably expects them to reconcile, because the docs said they would.

Supersedes #5061, which took the opposite approach (make the total match the adjusted figure) - closed once the maintainer confirmed the total's real-data semantics are intentional, not a bug.

Change

Corrects the description and adds a note explaining the real/adjusted split, pointing to the saving_real/saving_adjusted attributes already published on savings_yesterday_predbat for anyone who wants to chart either figure explicitly.

Follow-up

A separate, still-open question on #3894: whether savings_yesterday_predbat's own displayed state should switch to the real figure, so the daily and total charts visibly reconcile. Left for the maintainer to decide - not touched here.

🤖 Generated with Claude Code

The doc claimed savings_total_predbat is "a running total of the below
savings_yesterday_predbat sensor" - implying it sums that sensor's own
displayed state. It doesn't: the sensor's state is the adjusted saving
(factoring in the day's battery-value change), while the total
deliberately accumulates the real, unadjusted figure instead - real
money saved is what a running total is meant to track.

That's not a recently introduced mismatch (output.py has kept the two
separate since a very early commit), just never documented as
deliberate. #3894 reported exactly the visible symptom: daily bars
dip negative on the adjusted state while the total keeps climbing,
which reads as inconsistent unless the two are known to be different
metrics. Documents that distinction and points to the saving_real /
saving_adjusted attributes for anyone who wants to chart either one
explicitly.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@springfall2008
springfall2008 merged commit 4ee3b29 into main Sep 14, 2026
2 checks passed
@springfall2008
springfall2008 deleted the fix/savings-total-docs-3894 branch September 14, 2026 12:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants