That’s quite motivational, besides all my rant hahah
If you got links to other posts talking about the same stuff, either post here or message me in private with them - it would be really helpful once I try to get this topic into GitHub.
1 Like
Just don’t continue with the “soup at a restaurant” analogy when you go to GitHub, because at a restaurant you pay. 
(Btw, I understand all the confusion and the issues, but it’s also nice to learn more about the history.)
1 Like
Definitely all valid points!!! hahahaha
Came here with the same issue as @e-raser . I am shocked with disbelief that this is not possible. Inconceivable.
As many people reporting here, I have a scheme for entity IDs but names are different. Hard for me to understand how this could have been dropped.
1 Like
I don’t think that means what you think that means.
2 Likes
I think it does, according to my dictionary but disclosure, English is not my 1st language in case there’s a nuance you’re referring to.
Sorry, it’s a pun lost on you if English is not your first language. It’s a reference to The Princess Bride.
1 Like
Very on-topic and helpful, thanks.
1 Like
name: "{{ 'desired_object_id' if this.state == 'unknown' else 'Desired (friendly) name'}}"
if you set that as the name when creating the sensor initially it will use desired_object_id combined with the domain (eg sensor) to create the entity_id (eg sensor.desired_object_id) and it will use Desired (friendly) name as the name of the entity as soon as the state template is rendered.
2 Likes
On top of this, it’s been discussed many times that a PR that adds object_id to template entities configuration would be allowed. Just no-one has wanted to do the work. All it takes is a volunteer interested in adding the functionality. They can even use the MQTT integration as an example on how to code it.
2 Likes
Like many others, I’ve just run into this issue as well. Arghh! I’ve got a pile of Modbus devices, things like humidity sensors for which I’d carefully set the unique_id to a useful value and then the name was just “Humidity”, assigned to various rooms. What HA has helpfully done is mangled the name into totally meaningless “humidity”, “humidity_2”, “humidity_3”, “humidity_4”… who on earth thought that this was a good idea?
What’s worse is that I can’t delete these things! Even if I can bring myself to tediously hand-edit each one through the UI (there’s a lot of them), only the “Update” is enabled, the “Delete” is greyed out. So I can’t go back because I can’t get rid of the sensors now they’re added, and I can’t go forward because all of them have meaningless entity_ids.
Does anyone know how to purge these sensors with their unusable auto-generated entity_ids so I can start again?
Alternatively, is there any way to determine the unique_id so I can figure out which of the meaningless entity_ids goes with which sensor? The UI doesn’t show them, only the entity_id.
Answering my own question: If the YAML exists you can’t delete the sensors, so you have to go into whatever code editor you like, delete the YAML, and then you can go back via the UI and delete each sensor in turn.
Looks like I’ve got it sorted now, I’ll post a writeup that tries to summarise bits and pieces from various posts above for people new to the thread in a day or two when I confirm everything is working as intended.
Modbus is not template entities. Template entities are the only integration that allowed users to generate a separate name & slug. Its up to you to name them accordingly in yaml. This is one of the drawbacks of yaml, entity_id’s need to be unique however users can type in anything. HA doesn’t know what the user typed in until it starts, at that point it needs to be able to handle duplicate entity_ids. HA went the route of “keep all entities” as opposed to the “replace the existing entity” (which would have caused just as much confusion).
Remove the yaml, restart HA, clear your browser cache, then delete.
This is an attempt to summarise the above discussion in a single post for people who have run into this problem. In brief, HA takes the sensor’s name: and silently mangles it into an entity_id: which is often nothing like what you want it to be. Of the three identifier fields:
name: This is used either as, or to generate, the entity_id. That means that when you set it you need to choose a name that works as an entity_id, not a descriptive friendly_name:-type value. In addition any uppercase letters are silently forced to lowercase so it’s best to always use lowercase otherwise breakage occurs when you refer to it elsewhere using the original name that includes uppercase letters.
unique_id: A value that can’t be displayed or accessed but that’s necessary or your entity can’t be managed via the GUI. Think of it as a cookie, not an ID.
customize: friendly_name: The actual display name that you want to use.
So the mapping is: name: → entity_id, unique_id: → cookie, customize:friendly_name: → name/label/UI name/whatever.
To apply these, you need to specify them in two different locations in your YAML, some parts in mqtt: sensor: and other parts in homeassistant: customize:. For example say you have a solar setup and want to display voltages for the grid, solar backed-up circuits, and non-backed-up circuits. Then your mqtt: sensor: section would be:
mqtt:
sensor:
- name: grid_voltage
unique_id: uniqueid__grid_voltage
icon: mdi:sine-wave
state_topic: "grid/voltage/state"
value_template: "{{ value | round(1) }}"
unit_of_measurement: "V"
device_class: voltage
- name: non_backup_voltage
unique_id: uniqueid__non_backup_voltage
icon: mdi:sine-wave
state_topic: "non_backup/voltage/state"
value_template: "{{ value | round(1) }}"
unit_of_measurement: "V"
device_class: voltage
- name: backup_voltage
unique_id: uniqueid__backup_voltage
icon: mdi:sine-wave
state_topic: "backup/voltage/state"
value_template: "{{ value | round(1) }}"
unit_of_measurement: "V"
device_class: voltage
and your homeassistant:customize: section would be:
homeassistant:
customize:
sensor.grid_voltage:
friendly_name: "Voltage"
sensor.non_backup_voltage:
friendly_name: "Voltage"
sensor.backup_voltage:
friendly_name: "Voltage"
The result is then:
Since this is a pain to hand-edit and synchronise I’ve created a script to automate the process, I’ll post it to github in a day or two.
1 Like
Dave, I know your heart is in the right place, but you keep using integrations that do not have this friendly name problem.
With MQTT you can define the object_id, so none of your work around is necessary for that integration.
mqtt:
sensor:
- name: Voltage
object_id: grid_voltage
unique_id: uniqueid__grid_voltage
icon: mdi:sine-wave
state_topic: "grid/voltage/state"
value_template: "{{ value | round(1) }}"
unit_of_measurement: "V"
device_class: voltage
didnt read all of the thread above I admit, but this is simply not necessary at all. You don’t need to use customize: at all.
As a matter of fact, that is against your own interest, as writing anything in customize will be fixed in the state machine for that entity, and no longer editable in the UI.
It has been said frequently in this community, so not really sure why this misconception is still alive.
You can set any name you like in the UI config, or in yaml for that matter.
If you work in yaml (as I do mostly) the only prerequisite is a unique_id, to be able to edit afterwards in the UI and make it even easier. You can also change the object_id if you so desire.
Since I am seeing the blue notification this topic is already solved, and to only write with new info: that’s why I am doing this, future readers of this topic might end with you summary, which could lead to false conclusions.
Please have a look again, to see where your misunderstanding lies?
I was just following the instructions given in this thread by, ah, you actually:
If you want this to be all yaml, then you have to use customize. I don’t see this every changing and there’s no reason to use unique_id at that point either.
A bit further down is the details on how to apply customize, which is what I did. There are also various posts saying the current situation isn’t going to change to sort out the naming issues, which meant I wasn’t keen to experiment any further, particularly since the first attempt resulted in having to painfully manually delete a large number of sensors in the UI where HA did things behind the scenes that I wasn’t expecting.
Yes, but you’ll notice that the entire thread is dedicated to template sensors. Not MQTT sensors. This is what you are missunderstanding. Integrations have different configuration variables, an issue that template entities have may not be an issue for modbus entities (for e.g.).
Yes, the situation isn’t likely to change for the template integration.
I was playing with templates as well, which is how I got onto the thread in the first place… I’m trying to come up with a solution that isn’t dependent on the particular details of a sensor or entity type. It’s already quite a challenge to adapt what you’re doing to the internal details of each different entity type, the current solution just works for MQTT sensors, template sensors, and hopefully other sensor types as well although I haven’t got around to looking at those yet. And since it’s all generated automatically it doesn’t cost you anything whether the output is sensor-type-specific or (hopefully) sensor-type-independent.