Add entity specific force_update for DSMR

[yurnih]

Breaking change

Proposed change

#42086 changed the force_update property for each entity by default to True and with #43057 the interval of state updates can be modified. However, in some cases only a few properties are relevant to update every second, and for others it is fine to get updated when there is a new value. With this PR the property force_update is entity specific instead of default True for all.

This PR is in conflict when #43405 get merged.

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

Example entry for configuration.yaml:

# Example configuration.yaml

Additional information

• This PR fixes or closes issue: fixes DSMR power_tariff state registers as a change every update #43556
• 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 @RobBie1221, mind taking a look at this pull request as its been labeled with an integration (dsmr) you are listed as a codeowner for? Thanks!
_{^{(message by CodeOwnersMention)}}

[RobBie1221]

Why make it customizable? Can we perhaps come up with better entity specific defaults?

[coryshack]

4Cure Foundation has sent you an email via Gmail confidential mode: [image: Gmail logo]Re: [homeH-assistant/core] Make force_update customisable for DSMR integration (#46111) <https://confidential-mail.google.com/msg/AJd0jO2p_TQtEkxADsdjDEFqVLP7bRD0QmwMxNrBhgT3wUoetKxSW1yZYQEv9oN_lMUru8uvBht5l-fEuF8Ou8GvcE1xOqkEEyjsGLUmW0v-rpaY-1OJTApj8OMp9pJvkpp6UFBZdxd9djwywfU7n96sulM_b41rLKL4Kdy1l0qApzot1o98Qi4H2Ba_PhOusPD657BUDhCZ6g==> This message was sent on Feb 6, 2021 at 5:30:48 AM PST You can open it by clicking the link below. This link will only work for reply@reply.github.com. View the email <https://confidential-mail.google.com/msg/AJd0jO2p_TQtEkxADsdjDEFqVLP7bRD0QmwMxNrBhgT3wUoetKxSW1yZYQEv9oN_lMUru8uvBht5l-fEuF8Ou8GvcE1xOqkEEyjsGLUmW0v-rpaY-1OJTApj8OMp9pJvkpp6UFBZdxd9djwywfU7n96sulM_b41rLKL4Kdy1l0qApzot1o98Qi4H2Ba_PhOusPD657BUDhCZ6g==> Gmail confidential mode gives you more control over the messages you send. The sender may have chosen to set an expiration time, disable printing or forwarding, or track access to this message. Learn more <https://support.google.com/mail/answer/7674059> Gmail: Email by Google Use is subject to the Google Privacy Policy <https://myaccount.google.com/privacypolicy?hl=en> Google LLC, 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA You have received this message because someone sent you an email via Gmail confidential mode. [image: Google logo]

[yurnih]

Why make it customizable? Can we perhaps come up with better entity specific defaults?

I completely agree with you, having defaults specified for each entity would be much easier. But the reason I created the extra option is since I think it is hard to determine which entity should be forced pushed and which not, since this could be different for everyone using this integration.

Like a few entities only get updated a few times per day (Tarif) and others every "x"-seconds (Power).
I can think of that some want to have Tarif / Power logged into influxdb for each telegram, where others want to have it stored in the recorder for just viewing history in HA.

[RobBie1221]

I think we should limit the number of options presented to the user. Furthermore, the approach is not very generic. If force_update would be something that a user wants to customize per entity, it should be added to customization: https://www.home-assistant.io/docs/configuration/customizing-devices/

Within the integration we should try to make a default choice taking into consideration the type of data that is represented by an entity. In my opinion, force_update makes most sense for power and energy entities, because users want to have all datapoints of those to make charts and do statistics. For the other entities, For the other entities, I don't see a use case to have updates forced.

[yurnih]

That sounds fair. I'll update this PR, with just an extra label for force_update in the obis_mapping list.

[RobBie1221]

Looks good, thanks!

[MartinHjelmare]

Looks good!