Actually, most ‘new’ integrations do this. However they prepend the integration name. The difference is, these other integrations provide a name, which always takes precedence over unique_id when creating the object_id.
Just go through your entities_conf in the hidden folder and look at the unique_id, they will almost always have the integration name if they are in the ‘big’ domains, i.e. light, switch, sensor, etc.
it’s to ensure that the device has a unqiue_id in the entity database. It is a requirement so that you don’t end up with integrations getting confused as to which entity is theirs. For example, if zwave made xyz and template made xyz, depending on which one started faster, xyz would get assigned to 1 or the other. Then you’d have weirdness happen with your configurations through the UI.
Was it an existing entity, that you converted from legacy to modern, or a new one that you created in modern format?
When I paste your example into my system, it’s a brand new entity and gets the word “template” prepended to its object_id (DarrenHill reported the same behavior).
no it was completely new, and inspired by Darrens tracker… up to now, it is my only also 
OK, so that confirms the hypothesis. Just for fun, make a new one similar to it and you will see it automatically gets “template” added to its object_id.
@123 I think the simplest route here is your already in-place feature request to re-add friendly_name to modern templates. Then name can be used for the desired object_id and friendly_name for the name that’s shown on Lovelace etc.
That would I think cover all bases with minimal fuss for everything?
well I am amazed here, another brand new template and that does get the template_ prefix…
- unique_id: track_wijke
state: >
{{'In huis' if is_state('device_tracker.life360_wijke','home') else 'Uit huis'}}
icon: >
mdi:{{'home' if
is_state('device_tracker.life360_wijke','home') else 'home-export-outline'}}
attributes:
friendly_name: >
{{'Wijke is ' if is_state('device_tracker.life360_wijke','home') else 'Wijke vertrok '}}
how can this be…
please add that to Add (bring back) friendly_name to template sensors, it would be of great help indeed
That’s the feature request I was referring to (and I’ve already voted for).
How best to add this to it do you think? Link to this thread or something else?
I highly doubt it will be added. It’s been said time and time again that friendly_name templates will not be added. It only exists on legacy template sensors. All other legacy template domains (light, switch, binary_sensor, etc) do not have friendly_name_template. The likely hood that this gets added to the new template sensors is almost non-existent.
So if we’re to use a modern style for templates, then we’re forced to immediately customise them (via yaml or UI) to get control over the visible naming of them in Lovelace alongside the object_id that we want?
Seems like a crazy regression to me…
I don’t see how an extra action is a ‘crazy regression’. It’s literally 2 seconds. And if you already have a customization section, it’s zero seconds. 
The amount of effort on this thread out weighs the time it would take to just make the changes.
If you really want to get around it without having to have 2 sections, just load the configuration with a name and unique_id. Then change the name in the configuration to what you want the ui to be, then reload. It’ll now have the old entity_id with a new friendly_name.
load1:
template
- sensor:
name: Something I Want
unique_id: lskjadkfja2342
...
load2:
template
- sensor:
name: My UI Name
unique_id: lskjadkfja2342
...
Load 1 will set the object_id and load 2 will rename it but the entity_id will remain the same.
For each sensor I now have to have config entries in two distinct locations (one under template and one under customization), whereas under legacy it’s all nicely in one place and under control.
And having to go in either via the UI or customization to correct the template sensor I just created seems very wrong to me. That’s the regression bit. In legacy it’s a simple one-stop shop, make the sensor and forget it as everything is nicely in one place. Here you have to adjust it afterwards as you can’t set everything in one place and time.
Then use the legacy configuration…
Just to clarify, Mariusthvdb is the Feature Request’s author.
My interest is limited to understanding how modern format currently works and to get the desired result whichever way it currently permits.
Although I have created Feature Requests, I am aware they amount to little more than a wish list. There are many suggestions that are never implemented; it’s like winning the lottery.
My impression is that the friendly_name option was not accidentally but purposely excluded (I am unaware of the reason); getting it back may not fit with whatever was the justification for excluding it.
tl;dr
No harm in asking for its return but don’t bet on it.
Legacy Sensor configuration format
This format still works but is no longer recommended. Use modern configuration.
So it’s not recommended, but to get a useful and convenient template sensor we have to do so?
If you value having a name that differs from the object_id and not customizing it, then yes. It’s a recommendation. You’re welcome to ignore it. The vast majority of people will name their template sensor and run with the entity_id name they have been given.
Fair enough. At least the work-around works, even if it is odd to have to do it and it being rather messy in the config.
I just wait for the fun in the future if it is decided to move legacy to depreciation though, as it could be a very breaking change, either cosmetically or for object_id's. Either via the displayed name being wrong or having to work with template_…
that’s not as large of a breaking change as you’re making it.
Run this in the template editor
{% for s in states %}
{{ s.entity_id }}:
friendly_name: {{ s.attributes.friendly_name }}
{% endfor %}
copy the contents to customization.yaml
Now just name all your template sensors with what you want the object_id. And you’re done. The new templates will have the names you want from your legacy templates.
Could have used that yesterday
It still seems strange to me though that the extra customisation step is required in modern but isn’t for legacy.
If you went to buy a car and I told you that you could have last years model in any colour you liked, or you could have this years model (same engine, chassis and spec) but only in black, and if you want any other colour here’s a spray gun and a tin of paint and go respray it yourself.
Which would you buy? It’s exactly the same situation here isn’t it?
By the way, on your point about template_ forced prefix and duplication, wouldn’t it be more logical to check if the object_id to be created already exists and if so post-fix _2 or higher on it, like happens currently if a sensor is edited and clashes with a restored earlier (possibly zombie) version of itself?