Thanks for the idea, but just gave it a quick test and it’s cumulative. If I set a unique_id at the higher level (for example testing) I get a sensor of sensor.template_testing_darren_desktop
1 Like
Ah bummer, oh well
I never had the template_ before my sensor either. I did nothing special
I did nothing special either (I used the example posted by Mariusthvdb) and did get template_ prepended so it begs the question “What’s different?” 
I tested it with 2021.5.2. The sensor resides in a templates.yaml file along with several others.
Exactly the same set-up as me, although I’m now on 2021.5.3 core since last night (with no difference). Running on a Pi4 using the uSD card image. Templates set up in templates.yaml with a !include from configuration.yaml.
Every time I try the config without the name, I get the forced template_ prefix.
I do also see that the modern way is slowing things up compared to the legacy way. When I first open Lovelace (especially via the mobile app) it can take up to a few seconds before the customizations get applied. I have one which changes the icon on a couple of buttons on my opening LL pane, and often I can see the original icons for a short time before they change to the altered ones.
It’s the exact same code, just a different startup and configuration… something else is causing the slowdowns.
EDIT: And looking at the code, under the hood we ‘rewrite the config’ for legacy template sensors into the new method. So both legacy and new template configurations are stored and used in the exact same way. So all configurations from 2021.5 are using the new template integration even with the old template configuration.
1 Like
it’s going to be something with the entity creation process which is the same for all integrations that use a unique_id. There’s methods in place that automatically handle everything for the dev’s of a component. I’ve never bothered looking at the code because it always does what I want. Unique_id’s in general will gain the integration it comes from as a xxx_. There should be a path that creates the object_id from the unqiue_id, and that’s where we’d want to look. Post your entity config for template in question from the .storage/config_entries file.
EDIT: It may have to do with entity_config in general. I was taking existing templates and moving them. This may have caused the object_id to be carried from legacy. I see the code that does this but without debugging into the process while it’s flowing through the legacy ‘conversion’, I can’t see whats in the objects. I can tell you definitively, if this is a new template sensor, omitting the name will cause the unique_id to don ‘template-’ as the first portion of the string.
The only file in there similar to that is core.config_entries, and there is no template entity entries in there (the only one for Darren-Desktop is from Kodi).
The icon changing (customisation) delay only seems to have started since I moved the templates from legacy to modern, and that’s about the only thing that’s happened recently (aside from updates).
Yes, it’s a new Template Sensor (copied from the example posted by Mariusthvdb).
If I have understood it correctly, you and Mariusthvdb are getting the object_id you want (free of the leading word template and without additional manual editing) only because the entity already existed that way; it had already been included in the entity registry.
@petro Is there a reason behind why that addition must be done?
It’s quite inconvenient if you want to have full control over the object_id , for example to move an existing sensor from legacy to modern without having to go through everything uses it and add that prefix, or remove that prefix manually from every newly created entity via the UI or other customisation?
I’d honestly have to say for me that is a regression when moving from legacy to modern, compounded by the lack of friendly_name alongside name.
At first I thought the automatic inclusion of “template” might have been considered to be a convenience in the event a sensor was created automatically. For example, an automatically created sensor might be assigned an unfriendly-looking random alphanumeric string (like an automation’s id option) and it is helpful to prepend “template” to it to better understand its provenance.
HOWEVER, that’s all false because this is a Template Sensor, it’s not automatically generated, and its configuration is composed manually. The entity’s object_id ought to be based exclusively on what the user has entered. It deviates from how all other manually configured entities are handled. We don’t see “automation”, “light”, “switch”, etc automatically prepended for other domains.
The irony here is that it mandates the automatic inclusion of “template” yet allows you to remove it in a separate editing step.
I have no idea what you mean “must be done”? You don’t have to switch from legacy if you don’t want to. It’s legacy, it’s not going away unless it’s deprecated. And it’s not deprecated.
Well, it is what it is. I made the config as posted and you see the result.
I didn’t edit it in the ui and I didn’t use customize for the friendly_name
I merely showed the Ui to point to the omission for a picture
I meant why the template_ prefix must be added.
Was it just a coding decision, or is there something that necessitates the addition?
I know it’s not depreciated (at least for now), but the docs state that it’s recommended to use modern and not legacy from now onward. Which would tend to at least tacitly imply that depreciation may occur in the future perhaps.
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?
1 Like