Remove last_reset attribute from FritzBoxEnergySensor

[emontnemery]

Proposed change

Remove last_reset attribute from FritzBoxEnergySensor and set device class to STATE_CLASS_TOTAL_INCREASING

There are two options for sensors representing meters such as energy meters, where the sensor itself doesn't have a last_reset available:

• STATE_CLASS_TOTAL_INCREASING
  With STATE_CLASS_TOTAL_INCREASING, a new meter cycle will be detected if the value of the sensor's value decreases. This should be correct if the sensor only counts used (or delivered) energy, but not both in a single sensor, i.e. the sensor's value can't be decreased. Things will then work as expected if the sensor is for some reason reset to 0, for example after a firmware upgrade or factory reset.
• STATE_CLASS_TOTAL
  With STATE_CLASS_TOTAL, a new meter cycle will never be detected, and the statistics won't be correct if the sensor is reset.

This PR sets the device class to STATE_CLASS_TOTAL_INCREASING

Background in #54523

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 request:

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.

[probot-home-assistant]

Hey there @mib1185, mind taking a look at this pull request as it has been labeled with an integration (fritzbox) you are listed as a code owner for? Thanks!
_{^{(message by CodeOwnersMention)}}

[emontnemery]

@mib1185 With STATE_CLASS_TOTAL_INCREASING, a new meter cycle will be detected if the value of the sensor's value decreases. This should be correct if the sensor only counts used (or delivered) energy, but not both in a single sensor.
Can you help confirm this is correct?

[dennisschroer]

Your tests still think that the last_reset property is set.

[mib1185]

@mib1185 With STATE_CLASS_TOTAL_INCREASING, a new meter cycle will be detected if the value of the sensor's value decreases. This should be correct if the sensor only counts used (or delivered) energy, but not both in a single sensor.
Can you help confirm this is correct?

I'm not sure, if I get your question correct, but this sensor should always return the total used energy, since there are only smart plug devices available, which measures the used energy of connected devices.

[mib1185]

change it self looks good, but you still need to adopt the test, so that last_reset is proper recognized by decreasing the measured value.

[mib1185]

btw I guess background is #54523 not #48261 🤔

[mib1185]

lgtm, thanks