Add field "unique_id" to "config/entity_registry/list" websocket response

[philippwaller]

Breaking change

none

Proposed change

Problem Statement

In the current implementation, no unique_id is returned in the config/entity_registry/list websocket response. The client must use the entity_id as the primary key. However, since the entity_id can change during the lifecycle, it is very complex to build a local application cache. When a change is made, it is very tricky to perform an incremental update due to the lack of a constant ID.

Proposed solution

Similar to the "config/entity_registry/update" response, the "config/entity_registry/list" response should also provide a unique_id. This change increases the payload footprint but allows a unique identification over the entire entity lifecycle.

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)
• Deprecation (breaking change to happen in the future)
• 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.

[homeassistant]

Hi @philippwaller,

It seems you haven't yet signed a CLA. Please do so here.

Once you do that we will be able to review and accept this pull request.

Thanks!

[probot-home-assistant]

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

[emontnemery]

@philippwaller please note that the unique_id is not unique across integrations, and is also not guaranteed to be stable. RegistryEntry.id may be a better choice for what you want to do.

Also, can you give some details on how your changes will be used?

[emontnemery]

If this is added here, it should be removed from _entry_ext_dict below

[philippwaller]

Hey @emontnemery, thanks for your feedback! I had picked the "unique_id" field as this is also provided as part of the update response. If we would introduce the RegistryEntry.id (which make sense), other responses need to be adapted as well.

The main use case is to identify entities after the entity_id has been changed. I am developing a HA Addon UI that will allow power users to edit registry entries faster (advanced filtering, inline editing, possibly mass updates, etc). For these use cases I needed a constant/reliable UID to keep my EntityCache in sync with the EntityRegistry.

[emontnemery]

@philippwaller OK, thanks for explaining the use case. I think it would be better to use the id because it's guaranteed to be unique and stable, unlike the unique_id. If you add id to _entry_dict, it will also be included in the reply to config/entity_registry/update if that's what you refer to as "the update response".

[balloob]

You can already get the unique ID by querying specifically for the entity in config/entity_registry/get. We shouldn't add this to the list command.

The best way to keep it up to date is to listen to entity_registry_updated event. If the entity is changed, it is action=update, changes=[entity_id], entity_id=light.new_entity_id, old_entity_id=light.old_entity_id