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.
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.
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
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).
Ofc! None taken.
Was kidding.
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).
I would love to stay on the old model, since I have ~30 template binary sensors setup (my alarm system.)
Can we attach unique_id’s in the old format? I want to start placing these sensors into my Zones.
yep
now that would hardly be a reason not to migrate… 30 sensors wouldn’t take 30 minutes… and you’d be all set
When all the template stuff is exposed in the UI, I can remove the remainder of my entries from config and forget about any disparity. I don’t use the config because it’s “faster” or “convenient” or anything like that. My config contains manually entered bits because they aren’t available in the UI yet. That’s it. YAML otherwise sucks, it’s in contention for being one of the worst scripting languages to ever be created. It’s handy to be able to tweak fine details of an entity, but having to do it in YAML is like going to a dentist appointment to put air in my tires. I’d rather be writing PHP, Python, Perl, BASIC 2.0 honestly.
I came to this thread because of the same reason. I want to have friendly_name other than the entity_id-schema. As in the “old format”. Then I read from top and stopped here and tried. But this is (still?) not working, isn’t it? Perhaps you can correct it, so others, who will search and find this and then are happy to try it after reading from top to bottom, they will fail as well.
Then I read the rest and still not understand, why it is not there optionally. As the other requesters as well. It was possible in the old format and it is possible via UI. But then every user has to maintain twice and in different areas, what is of course not that good, if you want to keep the overview, what is derived from where, etc. And if you want to setup a lot of these templates, e.g. test created outside HA via Excel or something else, you have a UI click orgy afterwards.
Yes, everyone can argue, that a workaround is there. But it is only a workaround with more effort, more areas of maintaining, etc., where an optional attribute would make everyone happy. And for those, who don’t need it, they don’t have to set it or set it still via customizing or UI. No one would loose anything.
What I posted no longer works. Use the legacy format, otherwise make a feature request to allow you to set the entity_id.
I’ve been using successfully the method of defining name and unique_id s as the same id, and then adding a customization for every entity at the end of the file.
That’s satisfactory on packages.
But today i defined a template sensor in there separate templates.yaml file included, and I had to add the customization on the config.yaml file. Totally detached from the definition. And that will make version control harder. And ugly.