Add way to assign Entity IDs different from Entity Name

[nanderson97651]

Describe the problem you have/What new integration you would like

Building off of #2114. Add a way to separate the device and entity IDs from the friendly name. This would allow an update to the friendly name of a device for re-use, but keep the entity ID constant.

Please describe your use case for this integration and alternatives you've tried:

Example: I have a sonoff s31 outlet that is used for christmas lights in the winter and a fan in the summer. Current implementation of friendly name will change all entity IDs forcing a refactor of dashboards and automations. Allowing an option to set the entity name while leaving the entity ID intact (as can be done in the HA UI). i.e. I move outlet from christmas lights to fan and have an optional flag to force entity_id to be derived from name rather than friendly name, leaving the entity in HA as switch.sonoff_s31_relay with a name of Bedroom Fan Relay.

This also becomes useful with HA 2023.2's ability to group sensor states. I have a sensor group of energy consumed by all smart plugs to display in my energy dashboard but anytime I move a device its ID is updated forcing me to update the group and losing past data.

Additional context

This is admittedly a pretty narrow use case but I think in general the ability to disconnect entity ID from entity name without hand editing dozens of items could be useful.

[ezpl]

Your use case could be narrow, but the general problem is considerable. Not being able to change the display name without breaking things is not good design!

[EmhyrVarEmreis]

I was looking for this exact feature many times, and here it is, unimplemented :/

[ezpl]

I was looking for this exact feature many times, and here it is, unimplemented :/

Yes, I was really surprised when first discovering this fragile design. Can't imagine it is difficult to add as an option. Tempted to look into it myself..

[abichinger]

Proposal Add object_id as an optional variable to the entity schema.

# Example sensor configuration
sensor:
  name: Temperature
  object_id: temp_1

This would also require some changes here.

Case 1: Friendly Naming

Entity id is constructed from device name and object id

If friendly_name is set the resulting entity_id is f"{domain}.{device_info.name}_{entity_info.object_id}"

Example:

esphome:
   name: "livingroom"
   friendly_name: "Living room"

The entity_id would be sensor.livingroom_temp_1

Case 2: Legacy Naming

Entity id is constructed from entity name

Example:

esphome:
   name: "livingroom"

Without any changes to the esphome component of HA the entity ID would be sensor.temperature, because HA uses the name of the sensor as object_id. To get the entity ID sensor.temp_1 the EsphomeEntity.entity_id could be set to f"{domain}.{entity_info.object_id}"

[jougs]

A solution to this problem would also be extremely useful in situations where the friendly name of the entity contains special characters.

Here's an example: I have a light in my Gewölbekeller (vaulted cellar), for which I would like the name to be Gewölbekeller (in German, with the umlaut), while I'd strongly like my entity_id to be light.vaulted_cellar.

Right now, the entity_id becomes light.gewolbekeller. This makes automations a mess due to a mix between the English entity names I use everywhere else and the (weirdly, it should be gewoelbekeller) auto-transliterated ones coming from ESPHome.

A fully backwards-compatible solution would be add an optional field friendly_name for all entities.

• if unset, name in ESPHome would be used for both entity_id and name in Home Assistant, as it is now
• if set, name would become the entity_id in HA and friendly_name would become name.

An alternative could be to expose the id field of the entity as entity_id to Home Assistant if it is set and use the ESPHome entity name as name in HA. This behavior could be made optional by setting internal to False explicitly for the entity.

[clarencelocke]

+1 for getting this kind of change added.

I believe this situation would be correctly addressed by https://github.com/esphome/esphome/pull/4508

The whole crux of the matter here is that an entity's object_id in ESPHome is what is used as Home Assistant's entityID — and the only way it can be defined right now (see here) is as a side effect of the entity's name or the core friendly_name.

While having this automatically-produced property may be convenient for an ease of entry into using ESPHome in Home Assistant, it can so easily cause breakage of scripts from within Home Assistant if you decide you want a different / better name to be presented in the UI (i.e., you are forced to change the name parameter). A programming identifier (the entity ID) should always be decoupled from it's human-readable representation (the name).

Having an optional object_id parameter in the yaml configuration which would take precedences over the (friendly_)name-based properties allows for explicit (and more importantly, stable) control over entity names while still remaining backward compatible with legacy behavior.

The only way I see to get around this without a PR is to add a lambda function to a esphome:|on_boot: entry which then calls id(___).set_object_id("..."); for each entity involved. Painful and ugly.

[tjakubo]

It's quite baffling that this hasn't been exposed after years and dozens of requests. Yes, usually the autogenerated ID is good. But there's plenty of cases when not being able to control it at all is a huge pain. A simple optional property that doesn't try to be smart and just sets the ID would be perfect for that.

[Ziron]

I would say this is an absolute must-have feature for any non-english (non-ascii) user. Especially as long as ESPHome does not implement a more sophisticated slugify function that transliterates characters in the same way as Home Assistant would, instead of just replacing all non-ascii characters with _ which makes it painfully inconsistent with how the Entity IDs are assumed to be generated matching the friendly names in Home Assistant.