You have the power to implement those changes or just make a suggestion to.
I think that if you put a unique ID on the definition - which is allowed, that then you can set the name in the UI, or if you want to do it programmatically via the hass-cli command line tool.
1 Like
Well, adding a unique id might be a possibility, but it feels like a workaround to me. I’m curious what the reason is behind not making it possible to add a friendly name.
3 Likes
setting attributes of a single object in different places of the system is very inefficient approach.
Historically HA provides separate customization of entities, like setting icons. I never understood why it was invented this way. Maybe because back in time integrations were inconsistent so it was easier to program a feature overriding attributes, instead of extending all entities with such options (which should be easy task considering use of OOP though). But OK, it was long ago.
But why recently invented features scatters their settings across various places not allowing to set them in single file, using single method? Really the need of editing name using UI or calling api methods just after editing config files misses the mark.
I understand a need to have option to change name from UI. but it’s not against an option of being able to initialize this name in yaml config
1 Like
I’m on the same boat and struggling with deficient diverse object_id / entity_id / unique_id and name / friendly_name relation implementation.
I find the arguments exposed against the Op’s requirement very scarce. Four wheels doesn’t make enough for a Ferrari. The same way, having the ability of getting an entity name in the interface (any name) does not make for a complete solution but the scarce.
I’m trying to build a package for advanced PV management, and I want to share it with my channel and group friends. I think that’s packages are for. I’m not building an integration or component.
So if I want that this package doesn’t interfere with anything that the installers already has on their systems, I must plan an entity_id (I name it like this bc that’s what gui shows).
The package has lots, lots of mqtt entities. And those end as:
- platform: mqtt
#name: 'Battery SoC'
name: energy_battery_soc
unique_id: energy_battery_soc
state_topic: "storage/battery"
value_template: "{{ value_json['soc'] }}"
unit_of_measurement: "%"
device_class: battery
state_class: measurement
So, the entity id I decided is <package>_<device / section>_<measurement>.
- Name has to be like this or weird things happen. I’ve tried all combinations.
- Unique_id is useless (for me) but I must reiterate or the entity can’t have a human name.
- And then I must rely in the user to know what I’m talking about and write the “friendly name” for himself.
I’m also developer, and with the experience I know this is a fault.
If I put “Battery soc” as a name and don’t look back, the user could be squinting the eyes to get this one over a possibly large list of battery entities. I still don’t know how the included automations would function if the user has a phone battery entity.
Manual customizations are out of the equation if you want to share something or store something for rapid deployment.
Plus platform: mqtt is Pita compared to other entities. Someone talked about doing template entities instead, but I still haven’t found how to write an mqtt template entity. Just to replace the above one, for example. Or even better, to build a battery device that has all it’s measurements in child entities.
The package also has automations and helpers. Input selects, numbers… those are really ok.
The question is: Why all other entities, specially mqtt or modbus, are not defined like helpers? What are the wrong / obsolete one’s?
Please don’t take it badly. I have no intention to offend. Only give feedback and a defined field application where this is a problem.
Edit:
If unique_id is automatically calculated from the name, why isn’t automatically populated for the gui not complaining about not having an unique_id? Why it does exist (in yaml) in the first place?
Wouldn’t be better to have something like this for all yaml entities? (id + name)
platform_mqtt:
energy_battery_soc:
name: 'Battery SoC'
icon: mdi:battery-charging
state_topic: "storage/battery"
value_template: "{{ value_json['soc'] }}"
unit_of_measurement: "%"
device_class: battery
state_class: measurement
Or like gui elements:
platform: mqtt
energy_battery_soc:
...
All entities that follow the unique_id and name paradigm have this design flow, everything is shifting this direction.
If you’re using packages, you can simply setup customized entities in your package to set the friendly name. I.e.
sensor:
- platform: mqtt
name: energy_battery_soc
unique_id: energy_battery_soc
...
homeassistant:
customize:
sensor.energy_battery_soc:
friendly_name: Battery SoC
2 Likes
using the new MQTT format, why wouldn’t you use:
mqtt:
sensor:
- unique_id: energy_battery_soc # or some_other_unique_id_whichisofnofurtherconsequence
name: Battery SoC
state_topic: etc etc
the entity_id would be editable in the UI, and no need for customization
Well that’s very nice, thanks for that solution.
But that everything being steering that direction, in my opinion are bad news. Perhaps in a while would have a richer “new way”…
@petro Do you know anything about the possibility to group mqtt entities in a “device” or write them as a template?
Marius, that’s a proposal or it’s already available? Because I like it.
its available now as of 2022.6
The new way is to manage entities through the UI. 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.
There have been talks, currently this can only be done through discovery.
You keep insisting on editing things in the UI 
but the main idea is that UI editing is what most of the people complaining here really do not want to do.
I, myself is one of them. I like having everything in YAML and be able to restore to a new HASS instance without then spending hours editing things in UI.
True, Petro’s above solution with YAML customization works and can be acceptable. But having shifting to this direction only adds more complication instead of reducing it.
2 Likes
sure, I have all I YAML too. No problem there with my config suggestion. It allows for editing in the UI if you add a unique_id, it doesnt force you to.
Why would you say I
?
Merely suggesting… also because of 2022.6: Gaining new insights! - #356 by Mariusthvdb
Is there documentation for me to read? Thank you.
Edit: I’m still on 2022.5.5 … updating 
@clau-bucur That add’s version control. It’s so useful on large/proper implementations.
But it’s not completely true that advanced users don’t like using the ui. I’m myself waiting with hopes of being able to edit “included” files in the gui.
Petro
It’s only shifting this direction because most people want to edit entities in the UI, including yaml entities. Just do a simple search for “This entity does not have a unique ID” and you’ll fine 100s of threads about adding unique_id to yaml or how to customize yaml only entities. When you add unique_id to an integration, this is the trade off that you get. The unique_id / name convention builds the entity_id off one of those 2 fields and automatically increments it if there’s a confliction. If you want to generate an entity_id and a differing friendly name, then you have to use customize. Otherwise just use name alone and be done with it.
2 Likes
Unfortunately didn’t work. If I’ve not messed it. I mean keeping the chosen id convention, for use in automations.
mqtt:
sensor:
- unique_id: energy_battery_voltage
name: 'Battery voltage'
icon: mdi:battery-charging
state_topic: "storage/battery"
value_template: "{{ value_json['voltage'] }}"
unit_of_measurement: "V"
device_class: voltage
state_class: measurement
Perhaps it was so nice to be true. (Customization still required)
EDIT:
The following is the combination that works. It allows for a fixed id, specifies a Friendly name and allows edition (Friendly name translation)
mqtt:
sensor:
- unique_id: energy_battery_voltage
name: energy_battery_voltage
#name: 'Battery voltage'
#- name: energy_battery_voltage
icon: mdi:battery-charging
state_topic: "storage/battery"
value_template: "{{ value_json['voltage'] }}"
unit_of_measurement: "V"
device_class: voltage
state_class: measurement
homeassistant:
customize:
sensor.energy_battery_voltage:
friendly_name: 'Battery voltage'
I might have used a too strong a word, no offence intended. Saw a couple of times where someone said UI edit is out of the question, that’s why I was left with this feeling.
Will have to read that thread.
I don’t think we will be able to get away without customization in the future, if old style yaml templates become unsupported (I’ll have some lovely days of HA offline then).
1 Like
Ofc! None taken.
Was kidding.
1 Like
I’ve read about this shifting towards UI configuration across many topics here and have still no clue why it should be necessary to reduce YAML configuration options along the way. Why can’t there be both ways?!?
Maybe new users (I’m new to HA too) find it pleasant to take their first steps in the UI. But soon your instance grows and creating/editing entities via UI gets repetitive and error prone.
So you have to turn to YAML configuration to keep track of your programming (not to mention lovelace).
Prohibiting the possibility to set entity_id and friendly_name in YAML is a design flaw evoked by ideology (like the trend towards vast numbers of sensors instead of one sensor with attributes).
3 Likes