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
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).
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.
Do I understand this correctly?
For template sensors name is the Entity ID and the title has to be configured in the UI.
For MQTT sensors object_id is the Entity ID and name is the title?
It’s a tad confusing.
Also, above the history graph it’s always the name that is shown, making it ugly for template sensors. To prevent this, unique_id can be set (probably best to use the Entity ID here) and name can be used for the title. Afterwards, the Entity ID has to be copied into the UI. That’s rather involved. 
I know I’m reviving an old topic, but it makes more sense to post to this thread than creating a new one on the exact same issue (also because this is the first Google result for “home assistant set sensor template id” - besides docs, which are flaky, see the “bonus” below). Trying to summarize all that was discussed in the past here:
The only way to write entity_id + friendly_name* via YAML is indeed to have them in two completely separate places, the entity being generated from the name property under sensor, and the friendly_name depending on the generated entity_id and written under customization.
Is this correct?
If that’s so, in my team we call that WET code. Follow with me the path we must take to define a sensor with an entity following a pattern, and a name that actually makes sense for humans and the family. It’s quite complicated for the user to define a name, which under the hood becomes an entity_id (unless you define the “name” as a slug, what goes against the meaning of “name”); but don’t forget to also set a real slug for the unique_id (which may become the same slug you set as name!?), otherwise you won’t be able to set some other stuff through the UI later; then, you have to use said “name/slug” (or the magically-generated slug from the actual “name”) on a whole other section to define what is the actual “entity name” shown everywhere in the UI (what you use most of your time as a user). Bonus: the customization section will be, most certainly, quite far from the sensors, making for a lot of back-and-forth - that is, if you’re not using includes, what makes for even more burdensome work!
I don’t really want to offend the devs here, but looking from a user point of view, with a developer background, this feels like a change which wasn’t tested by plain users (only tested by HA devs, weighing more on the implementation view than user view) and now seems to be stuck this way “because it’s the way things are”. And I really feel that, if I report this ~nonsense~ WET pattern as an improvement request, it will be turned down because “it’s the way things are” or because of some other pattern in the project which makes sense from the implementation level (but, as mentioned before, doesn’t on the user level).
Bonus:
- docs don’t explain clearly how to set all those details about a template sensor
- docs still don’t explain the relation between
nameandentity_id, and thatunique_idisn’t used for that, contrary to common sense (coming from a user PoV; after this thread, I understood how it ended up this way, but it simply doesn’t make sense from the user PoV). I plan to submit a PR to docs after I confirm my findings here. - edit: one other thing that’s missing on the docs is stating that, once you firstly create the sensor with a
unique_id, other changes should be done via the UI. I’ve also spent quite some time restarting HA and trying to figure out why my “fixed” name/entity_ids were not propagating…
On other words: why did the attributes: { friendly_name: XYZ } suggestion stopped working? It was the only way to keep the “user-important stuff”* neatly in the same place.
* Those two are what’s really important by the end of the day for the user, since as a user you don’t need the
unique_id, that’s an implementation detail which HA needs to get the UI running. What you need is theentity_id, for automation and overall referring to that sensor you created, and the human-friendly name which you see in the UI.
No one is stopping you from making a change to add in the ability to set the object_id to whatever you want. It’s been discussed before and no one (on the main dev team) is against setting it. It just hasn’t been developed.
FYI the object_id is the second half of the entity_id.
The main dev team is against changing the unique_id → entity_id → name generation code because all integrations use it.
So, to be clear: You can add object_id as an option specifically for the new template integrations. Just don’t try to change the current methods in place that autogenerate the unique_id/entity_id/name.
Because other users want to use templates in the name field that is outside attributes. The other users that wanted it, wanted it so bad that they developed it and added it. Whatever changed to make that happen, broke the friendly_name inside attributes.
This whole “the devs” crap is so annoying and just flat out misguided. These are other volunteers and other users who decide to make these changes and these changes get put into the software. They are simply approved by the main development team. I can tell you first hand that most of these changes were not performed by the main development team. This is open source, keep that in the back of your mind at all times.
If you want to make a change, make a PR. Follow the rules the main development team imposes. If you can do that, your PR will go through.
First of all, thank you very much for such a fast answer lol
I came here to edit my post and now I have to reply you 
Also thanks for the object_id explanation, and to explain how other integrations weigh in (since we can’t easily see how it runs under the hood). That would make sense indeed and I’ll try to report it 
What I came here to edit was actually that another way people usually suggest around the forum instead is: “just use the old syntax”, but then… it’s old for a reason, right? No new features (such as triggers and whatnot) will be added to that. Even if that’s not going to be deprecated, it’s not going to be updated as well, so there’s little incentive to use the old syntax - that’s a bad suggestion as well.
(but that’s not what you said now, I’m just pointing out another thing that someone else might suggest)
Now, the rant parts:
Answering “no one is stopping you from changing how HA runs” is, honestly, the usual OS crap that’s thrown to OS users - “Wait, what was coded doesn’t make any sense for the user? So let them take a bunch of their time to make the change themselves!”. It’s like telling someone to go home make their own soup if they complain about a fly on the soup they ordered at the restaurant.
This should be well-thought at the first place, or just accept it as a problem report, instead of leaving to the user the burden of fixing something that they’re already trying hard to understand and put to work, and then discover it doesn’t work as it’s expected. It’s awesome to have a lot of volunteers to work on HA, but not every user has the ability and time to understand the inner workings and write a PR following all the rules, so a bug report (even an informal one, while trying to understand stuff in the forum) never should be automatically answered with “go change it yourself” - if the user could, they would instead of just explaining the thing they’re trying to do.
The the devs entity which I mean (and, I guess, other people too) is people actually changing how HA runs under the hood; be them users which volunteered or the main dev team, the end result is that some stuff simply doesn’t seem to have been given complete thoughts; for instance, they made a change which worked for their use-case, but then broke the attributes.friendly_name use case 
But yeah, if that’s something that just broke, it seems a bug report would do. Hopefully.
That’s open source though. You mentioned you were a developer and started criticizing the current implementation. That’s a recipe for “fix it yourself” response. I thought about adding this, but at the end of the day, I don’t really see the need to add it. I could spend a couple of hours making a large change, submitting the work, reviewing the work, updating the documents, adding tests… or I could just maintain the customize.yaml file for 3 entities where the name differs from the entity_id.
It was well thought out in the first place. The only non-well thought out process that causes issues is the automatic appending of template_ to the unique_id when generating the entity_id from the unique_id. Had that never been implemented in the first place, then this whole topic wouldn’t exist. Now removing that would be a massive breaking change. The reviews didn’t catch it, no one caught it in beta, and no one noticed this for a few months. So here we are.
It was a trade off that was accepted. If I recall correctly, there was no way to have both. So if you attempt to get this working again, it will most likely break templates in the name, and then that whole argument thread will start again (which was about the same size as this).
But being able to cook a soup doesn’t mean I want to cook a soup by myself instead of just ordering it at the restaurant.
Being a developer doesn’t mean I have the time and ability to get into HA and code stuff myself.
And yeah, at the end of the day that’s what I did - ended up with a weird solution instead of something that should “just work” from the user PoV. But not before spending a lot of time trying to understand that, and then, reporting here to see if I pieced it all right (and I did, thus next step is at least making a formal report at GitHub. Thanks again!)
Also, it would be easy if it’s three entities, but if you’re with 7, 10, 20, it starts to become very WET code.
It was well thought out in the first place. The only non-well thought out process that causes issues is the automatic appending of
template_to the unique_id when generating theentity_idfrom theunique_id. Had that never been implemented in the first place, then this whole topic wouldn’t exist. Now removing that would be a massive breaking change. The reviews didn’t catch it, no one caught it in beta, and no one noticed this for a few months. So here we are.
Oh, the marvels of development in you-can-never-go-back projects 
(hello Java!)
It was a trade off that was accepted.
Oh boy. Thanks for saving me the headache then. I guess stating these stuff in the docs will be helpful enough, will try to work on that.
Cheers, sir! 
My current count (without maybe one to two dozen others in the „new“ template sensor style):
It was a lot of fun. Counting in days meanwhile, no kidding.
I knew it would grow (and that project has not finished yet), that’s why I initially asked here to shorten every step and limit or reduce the overall time needed.
As I don’t have any dev skills - and even it hurts seeing others struggle with the exact same thing - I have a little bit of hope maybe things might change in future, seeing others stepping up and asking the very same questions. Without asking questions, nothing will ever improve.
Currently everything seems to be said over and over again, only with other words from other people 
Thank you all not giving up and still being motivated enough to improve things - for everyone.