Remove last_reset attribute and set state class to total_increasing for fronius energy sensors

[emontnemery]

Proposed change

Remove last_reset attribute from and set state class to total_increasing for fronius energy sensors

Background: #54755

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 @nielstron, mind taking a look at this pull request as it has been labeled with an integration (fronius) you are listed as a code owner for? Thanks!
_{^{(message by CodeOwnersMention)}}

[nielstron]

Thanks, this looks like it makes good use of the new TOTAL_INCREASING class.
This might be a too general comment, but I have to add that I don't like completely abandoning the last_reset attribute. Checking for external resets manually by checking whether a reduction occured in a monotonous sensor, is a great idea. However there is always a tiny chance for the first value received after a reset to be larger than the previous value, and this would skew the measurements (nearly non-reconstructable). If a last_reset attribute is known (like here, the day sensor will definitely reset every midnight), why should we ignore it?

[frenck]

However there is always a tiny chance for the first value received after a reset to be larger than the previous value, and this would skew the measurements (nearly non-reconstructable). If a last_reset attribute is known (like here, the day sensor will definitely reset every midnight), why should we ignore it?

We consider this an edge case at this point that we are most likely not to encounter. We decided to minimize first and extend later when actual occurrences show the need.

[emontnemery]

@nielstron the last_reset was very tricky to use in a correct way. One way it could introduce errors was if the last_reset was not synchronized with the state updates from the API or device. This causes a race where state updates around the reset point may be attributed to the wrong cycle.
I think that may have been the case here since the last_reset attribute only used Home Assistant's local clock, instead of synchronizing with the fronius API?

there is always a tiny chance for the first value received after a reset to be larger than the previous value, and this would skew the measurements

Yeah, that's indeed possible. A solution to that issue is for the integration to force a reset / new cycle by inserting an extra 0-state, if it knows the underlying sensor or API resets periodically by calling self.async_write_ha_state().

[nielstron]

Okay got it, thanks for the feedback!