Closed maeklund86 closed 7 months ago
LGTM. Thanks for your contribution!
I'm not sure this change from total_increasing tot total is right. State class total would allow for odometer rollback which should not happen, as an odometer is meant to always increase. State class total_increasing is for totals that cannot decrease. It assumes that a lower value is the result of a replacement of the counter for a new one that started at 0. Imo that is a better fit for an odometer than total, which assumes you can undo distance traveled.
The documentation stated a pretty clear example: "The sensor's value never resets, e.g. a lifetime total energy consumption or production: state_class total, last_reset not set or set to None"
"It's recommended to use state class total without last_reset whenever possible, state class total_increasing or total with last_reset should only be used when state class total without last_reset does not work for the sensor."
On the other hand: "The sensor's value may reset to 0, and its value can only increase: state class total_increasing. Examples: energy consumption aligned with a billing cycle, e.g. monthly, an energy meter resetting to 0 every time it's disconnected"
https://developers.home-assistant.io/docs/core/entity/sensor/#entities-representing-a-total-amount
I think it doesn't matter all that much in this case, as it should never decrease anyhow.
Defining a state class for odometer allows for long-term statistics. Fixes the issue #213
Total: "The state represents a total amount that can both increase and decrease, e.g. a net energy meter."
Examples:
The sensor's value never resets, e.g. a lifetime total energy consumption or production: state_class total, last_reset not set or set to None
https://developers.home-assistant.io/docs/core/entity/sensor/#available-state-classes