Using unique_id within templates to get state

Feature Requests
1

I recently fell over the following problem.
I already have a sensor in my HA which is named “Battery level”. This sensor has a unique_id and its entity_id is sensor.battery_level.
Yesterday i’ve added this yaml to my configuration. The yaml contains another “Battery level” sensor with an unique_id and gets the entity_id sensor.battery_level_2. So far so fine.

But: The yaml also contains a template sensor which refers to sensor.battery_level. So in my case the template sensor didn’t work out of the box because it refers to the wrong “Battery level” sensor. I fixed my problem by refering to sensor.battery_level_2, but i would find it way more elegant if the unique_id could be used in templates.

According to the docs the entity_id is used to access the states via e.g.

states('sensor.battery_level')

Is there any change to acces the state via its unique_id e.g.

states('unique_id.sg_battery_level')
2

You can change the entity id to whatever you want. As the sensor has a unique id you can do it from the UI.

1 Like
3

I know, that i can change the entity id, but that’s not the point.

I’m using the existing sensor.battery_level in some automations/template sensors.
And the new one is used by template sensors in the yaml file it is defined in.

So currently i have two options:

  1. Rename my old sensor and adjust all my existing automations/template sensors.
  2. Adjust the new yaml to use sensor.battery_level_2

If unique_id could be used in templates i would not have to change anything.

4

Yes you would. You’d have to change all the new yaml where sensor.battery_level is used.

Change the new entity id to match the unique id. Problem solved. Same amount of editing.

5

No, i would not need to change anything, if this feature would be available and the imported yaml would support it.
And if the imported yaml doesn’t support it (yet), one can update it so other users don’t run into the same problem.

6

The problem here is really that both the old and the new sensor is using too generic names.
At least the old sensor should have a non-generic and unique name at the time of import.

It is the users task to name entities in a good way and there are several ways to choose from.

7

When i started the name was not too generic because i only had one sensor of this type. For sure i can rename the old sensor but then i have to adjust all my templates und automations as well.

Another, in my option not very user experience friendly, point is that if a rename the old sensor to “Device A battery level” and the new one to “Device B battery level” is that the whole long names will show up in the dashboard.
I normally group sensors for one device under the device name. Having every entity name starting with the device name is redundant information and makes it harder to read. Fore sure i can change the entity names in the dashboard again, but this is unnecessary work.

I know there are several ways to solve my problem, but this is a feature request and i think it brings a lot of benefit in some use cases without negative side effects for other parts of Home Assistant.

8

No they won’t. The entity_id is seperate to the name (if you have a unique id). So you can have multiple different entity_ids all with the same short name for display. To do this you just edit the entity id in the UI, as I said earlier. Click on your entity in a dashboard or devices and services, click the cog icon in the pop-up card, edit the entity id. Leave the name or edit it as you see fit.

1 Like
9

Like i said, i know i can change the names via the UI, but with the feature request i would not have to do so, because i can configure every sensor with a nice an neat short name and refer it via its unique id.

10

No you are still not understanding. Don’t change the names. Change the entity ids. They are two different things.

Keep your short names for display.

Use a descriptive entity id.

2 Likes
11

I think the issue here is that the thread starter has an entity with an entity_id already and now something else comes in and try to add another entity with the same entity_id, which then gets _2 appended to create an unique entity_id.

HA did actually create a unique id, but not in the way the thread starter wished for.

12

Which is why, no matter what method you use, some editing has to be done.

13

I know i can change the entity ids via the UI. But as far as i know i can’t set the entity id via yaml. Via yaml i can only set the name and the unique id.
So in every case a have an additional manual step to get my setup workin.

14

That’s not a reason.

Even if you got your request you would still have to edit the code to use unique ids instead of entity ids.

15

Sure, i need to update my code but i cannot run into the same problem again in future.

Heretical question:
Do we really need entity ids at all? Aren’t name and unique id not enough for accessing and displaying sensors, templates, etc?

16

I think the main reason having a fixed unique id “under the hood” was introduced was because it allowed the automatically generated entity id to be changed for discovered devices. Entity ids have been around since the beginning. Removing them would not be breaking change it would be a catastrophic change, for everyone.

17

I totally agree that removing entity ids would be a catastrophic change.
But why shouldn’t it be possible to use unique ids and entity ids on equal terms in parallel?

18

Entity ids are required to be unique, so you have your unique id, it is just called an entity id.

19

But they are autogenerated by Home Assistant and i cannot define them in yaml. That’s the problem with entity ids.

20

Settings → Devices & Services → Entitites → click on an entity → Click gear → rename entity

The type can’t be changed, but you can have sensor.uniqueid_battery_level if you like.