Repository navigation
Conversation
`steps` and `distance` come from currentActivitySummary for the daily, weekly and monthly periods, and all three reset to zero at the start of their period (local midnight for the daily pair). They were declared TOTAL_INCREASING, which Home Assistant treats as a monotonic counter: every midnight reset is recorded as a counter reset and shows up as an anomaly in long-term statistics, so the daily_history graphs are wrong. TOTAL is the state class for "a running total that may reset", which is what these actually are. Both sensors share one SensorEntityDescription per key, so this covers all six period-scoped entities (daily/weekly/monthly x steps/distance), not just daily_distance. Closes tryfi#13 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
TOTAL alone does not fix the statistics: the recorder starts a new cycle for a TOTAL sensor only when last_reset changes, so without one the first zero point is kept and every later midnight reset is summed as consumption. Report the start of the current day, week or month.
TOTAL alone does not fix the statistics: the recorder starts a new cycle for a TOTAL sensor only when last_reset changes, so without one the first zero point is kept and every later midnight reset is summed as consumption. Report the start of the current day, week or month.
SensorEntity.state_attributes is where Home Assistant publishes last_reset, as an ISO string, and only for state_class TOTAL. Returning it from extra_state_attributes bypassed that. The test now reads the attribute Home Assistant publishes, and fails on the previous code.
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
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.
Fixes #13.
stepsanddistancecome fromcurrentActivitySummaryfor the daily, weekly and monthly periods. All three reset to zero at the start of their period — local midnight for the daily pair — soTOTAL_INCREASINGis the wrong state class: Home Assistant treats that as a monotonic counter and records every midnight reset as a counter reset, which shows up as an anomaly and breaks the long-term statistics.Changing the state class alone is not enough. In
components/sensor/recorder.py, a new statistics cycle starts for aTOTALsensor only when itslast_resetattribute changes; with nolast_resetthe first zero point is kept forever and every later reset is summed as though it were consumption. So these sensors now also publishlast_reset: the start of the current day, week or month, in local time.Sleep and nap are durations rather than period-resetting counters, so they keep their existing behaviour and report no
last_reset.Scope
Both sensors share one
SensorEntityDescriptionper key and the entity is built per period insensor.py, so this covers six period-scoped entities —daily/weekly/monthly×steps/distance— not justdaily_distance. Issue #13 namesdaily_distance, butdaily_stepsand the weekly/monthly pairs reset the same way and have the same defect.Test
Two tests:
test_period_counters_use_total_state_classasserts both descriptions areTOTAL, andtest_period_counters_report_a_last_resetasserts the daily/weekly/monthly counters return alast_resetat the start of their period while a duration sensor returns none. Both fail on the pre-fix tree.Note on existing statistics
This corrects the state class and the reset signal going forward. Values already recorded under
total_increasingmay still show the old anomalies until those samples age out; that is not fixable from the integration side.