Allow storing device options in DeviceEntry

[frenck]

Proposed change

This is a meta/suggestion PR at this point.

And is inspired by #58757 (review) and earlier discussions.

This change adds a fairly simple options dictionary to the DeviceEntry, in which we would allow integrations to store additional device options. These can be used for adjusting the behavior of a specific device, or, expose entities that control these parameters to adjust behavior.

This is very much in line with the ConfigEntry options (except for that one, we have a flow, in this case, we can leave it up to the integration).

This can be useful for things like:

• Storing device preferences, e.g., update channel preferences in Add button to trigger ota firmware update for Shelly devices #58757 (see comment for details
• Preferred unit the device uses (e.g., Add support to a different unit of measurement(mmol/L) on Nightscout  #58921 mmol/L or mg/dL to measure blood sugar levels) and can expose the matching sensor for that unit (instead of both, or breaking changing when switching).
• Integrations that provide multiple devices, but like to offer configuration per device. For example, Add option to select quality of camera snapshots taken from Synology DSM connected cameras #58306, Synology DSM provides cameras and could provide a per device snapshot quality selection, instead of the global integration option (that applies to all cameras).

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.
• For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.
• 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.

[frenck]

As pointed out by @mib1185 on Discord, there is a problem with this approach. Devices are potentially shared across integrations, thus options can conflict. Does this need namespacing or something? This gets ugly fast probably.

Another option would be adding methods for getting/setting options, and making domain mandatory in these calls.

[marciogranzotto]

It would be great for #58921

Devices are potentially shared across integrations

I'm curious about how does this works. I thought that each device was bound to just one integration.

[mib1185]

I'm curious about how does this works. I thought that each device was bound to just one integration.

See the developer docs here https://developers.home-assistant.io/docs/device_registry_index especial the connections property 😉

[elupus]

I like having it inside the entry. If it's just calls on integration level, it would still need to figure out a storage location.

[frenck]

@elupus you mean config entry? If so, a config entry is not device level, as a config entry can provide multiple device.

If not, I think I don't understand your comment.

[frenck]

Please note ⚠️

I made this PR as a draft as an example. I have another option ready and I actually believe this PR is a wrong approach

[elupus]

@elupus you mean config entry? If so, a config entry is not device level, as a config entry can provide multiple device.

If not, I think I don't understand your comment.

No i meant the entry for the device in the device registry. I commented on your alternate approach of setters/getters. I think i thought about it backwards. I thought you intended for a integration level callback (like async_setup/restore state). But i realize that doesn't make much sense.

So setters getters in device registry could make sense. Mainly to avoid clobbering other domains settings by misstake. Could simplify code too, since you would not need an instance of the device to get device settings, just it's identifiers.

[frenck]

I think I have an idea on how to make this easier to use. will try to work an example out.