Officially allow enities to set their entity ID not based on their names

[ekutner]

Context

Deriving entity IDs from the entity name, which is also used as the display name of the entity, may be a reasonable work around when the entity is not offering its own ID but it is very limiting and doesn't always make sense. The main limitations in that approach are:

• Changing an entity name will break things - the need to change a name may rise from an external change, for example if the name of the physical device is changed, or because we want to display more contextual information, for example a play/pause button that changes its name based on the current state (only showing "play" or "pause"), not both.
• Entity names can't be translated - This is based on a discussion I had in the core discord channel. I couldn't find a way to translate entity names (unlike values which can be easily translated) and the person I was talking to said that this wasn't supported because the name is also the ID so it can't be translated. If that is correct than that is a very serious limitation. It makes little sense to translate values but not the display names of entities.

In reality I didn't find anything that was forcing this connection between ID and display name. In the integration I was working on I found a workaround for explicitly setting the entity ID by setting it like this on my entities: self.entity_id = f'dummy.{self.unique_id}' This "trick" is based on the way HA core currently generates the entity_id but this it is based on reverse engineering the current code it may break at any time. That said, using this trick, everything was working fine with me entities and it allowed me to change the names without affecting anything else in HA.

Proposal

Separate the display name of an entity from its entity ID. The display name can be used as a fallback but if an explicit ID is provided then it should be used.

Consequences

The above limitations will be lifted. Especially the translation of entity names is critical in my eyes and must be supported. To be honest, I don't really see why it can't be supported in the frontend even without the proposed changed but I may be missing something here, so this change should definitely allow for it. As long as names are still used as a fallback for existing integrations that don't provide an explicit entity_id there should be no negative effect on existing integrations.

[balloob]

Entities with a unique ID will register their entity ID and will be assigned the same one even if their name changes.

Entities can already suggest an entity ID by setting the entity_id instance variable before being passed to async_add_entities.

[ekutner]

@balloob As I pointed out, this is doable, and I was doing it in my entity. I'm happy to hear that it's supposed to work like that but it's not documented anywhere that I could find and the entity_id has to be constructed in a specific way for it to work: ".". It would be a very good idea to document it and maybe allow it to be defined in a more natural way. I will open a separate issue about translation of entity names.