Add support for total and total_increasing sensor state classes

[emontnemery]

Breaking change

Although not a breaking change from a user's perspective, this is a significant change from a developer's perspective.
It should be noted that the state class total was removed.

Details here: home-assistant/developers.home-assistant#1028

Proposed change

Add support for total and total_increasing sensor state classes:

# The state represents a measurement in present time
STATE_CLASS_MEASUREMENT: Final = "measurement"
# The state represents a total amount, e.g. a value of a stock portfolio
STATE_CLASS_TOTAL: Final = "total"
# The state represents a monotonically increasing total, e.g. an amount of consumed gas
STATE_CLASS_TOTAL_INCREASING: Final = "total_increasing"

If the sensor's state class is STATE_CLASS_TOTAL, the last_reset attribute can optionally be set to indicate a new meter cycle.

If the sensor's state class is STATE_CLASS_TOTAL_INCREASING, a decreasing value is interpreted as the start of a new meter cycle or the replacement of the meter. The last_reset attribute will be ignored when compiling statistics. This state class is useful for gas meters, electricity meters, water meters etc.

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New integration (thank you!)
• New feature (which adds functionality to an existing integration)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue:
• Link to documentation pull requests:
  • blog post: Add blog post about new sensor state classes developers.home-assistant#1023
  • developer documentation: TODO

Checklist

• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• The code has been formatted using Black (black --fast homeassistant tests)
• Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• Untested files have been added to .coveragerc.

The integration reached or maintains the following Integration Quality Scale:

• No score or internal
• 🥈 Silver
• 🥇 Gold
• 🏆 Platinum

To help with the load of incoming pull requests:

• I have reviewed two other open pull requests in this repository.

[TomBrien]

Might be worth usings omething like fstate < 0.9 * old_state? I'm just thinking of cases where a slightly noisy energy sensor is being used in an integration to calculate power. If the sensor is measuring 0 +/- some noise it is possible for the value to creep down a small amount without being a true reset

[emontnemery]

I think that needs to be handled by the integration if it claims STATE_CLASS_TOTAL_INCREASING.
In the example with integrating a noisy power sensor (I think that's what you meant?) it could perhaps be handled by ignoring negative power?

[TomBrien]

Agreed. I think it's best that the integration claiming that the sensor will only increase ensures that is true. I thought of some others where a less than could be an issue but in all cases the integration should know what it's doing better

[ludeeus]

This is not needed, L162 will not continue if this is None

[emontnemery]

Thanks, added to #54624

[frenck]

Removed the breaking change label, as it never went to stable.