If you just have unique_id, the object_id will be based on the unique_id. You’ll be able to edit from the UI.
If you have name and unique_id, the object_id will be based on the name. You’ll be able to edit from the UI.
If you have just name, the object_id will be based on the name. You won’t be able to edit from the UI.
Understood. The “under the hood” bit was that HA is using it to follow it and enable changes via the UI.
So the basic answer is no, I can’t preset everything in the yaml file entry for the template and I need to edit at least one of the properties via the UI.
Fine with that (albeit some work), but wanted to ensure I hadn’t missed something as this is the first time I’m playing with the new modern way of doing them.
You can set the name in the customization section of your configuration.yaml. Or set it through the UI.
but you have to omit name in the template
OK, will have a play later on and see what I can do. Thanks for the info.
This won’t provide exactly what you want but I am posting it here for future reference. The result of this will be sensor.template_track_darren_desktop whose friendly_name is “Darren’s Desktop” (assuming I configured the quotes correctly).
template:
- sensor:
- unique_id: track_darren_desktop
state: "{{ 'Connected' if is_state('device_tracker.darren_desktop', 'home') else '------------------' }}"
icon: "{{ 'mdi:desktop-classic' if is_state('device_tracker.darren_desktop', 'home') else 'mdi:lan-disconnect' }}"
attributes:
friendly_name: "{{ 'Darren''s Desktop' }}"
Reference:
I don’t think you even need the templates there
template:
- sensor:
- unique_id: track_darren_desktop
state: "{{ 'Connected' if is_state('device_tracker.darren_desktop', 'home') else '------------------' }}"
icon: "{{ 'mdi:desktop-classic' if is_state('device_tracker.darren_desktop', 'home') else 'mdi:lan-disconnect' }}"
attributes:
friendly_name: Darren's Desktop
Hmm. I have a vague recollection of trying that and it wasn’t successful but now I am uncertain. The documentation indicates it expects a template. I’ll try again when I have access to my system.
No need to try, I use the attributes area to set flags for items. I have it in all my templates, you can check my github
Yes, does exactly that. Almost there but gives the unwanted template_ prefix.
Is there any way around that?
No, that’s done automatically by Home Assistant when it builds the sensor’s object_id and there’s no name defined.
It’s why I made the disclaimer that it wouldn’t give you exactly what you wanted; its just for reference purposes, mostly to show how friendly_name can be set in the sensor’s configuration. However, only if there is no name option present otherwise Home Assistant will default to using that for friendly_name. See the linked post to learn about how it behaves when various options (unique_id, name) are included/excluded.
Yes I saw the disclaimer 
So I have three basic options here:
template_ version.template_ (which is what I was trying to avoid in the first place).Any idea what the reasoning is for the automatic addition, as it’s somewhat frustrating. Is there a specific reason that it needs to be done differently in the two routes, as it seems to me that the “modern” version is less flexible than the legacy one?
I have no knowledge why it works the way it does; I think only someone involved in the design of ‘modern’ format can provide a factual answer.
Fair enough.
Thanks for the help so far anyway. I think I’ll roll back to the legacy method at least for now, and will consider the best way of the other two for the future.
As you say, hopefully someone can cast light on why the prefix is being enforced on the id, as it seems very undesirable to me from the user viewpoint and will end up as a similar roadblock in the future if the legacy method is depreciated and later removed.
OK, got it doing what I wanted by using the customization section and letting that handle the friendly name. No unwanted Template_ in the sensor ID, and everything’s working fine.
Seems an oddity that I have to customise a sensor that I just created, but at least it’s working without having to manually tweak anything in the UI.
One note though, it does seem to work with name in the original template, the customize overrides it fine.
Will call this one completed, as a learning experience. Thanks again for the support chaps 
what is your final yaml code now? please post one template: including the customize?
homeassistant:
customize:
sensor.track_darren_desktop:
friendly_name: Darren's Desktop
template:
- sensor:
- name: track_darren_desktop
unique_id: track_darren_desktop
state: "{{ 'Connected' if is_state('device_tracker.darren_desktop', 'home') else '------------------' }}"
icon: "{{ 'mdi:desktop-classic' if is_state('device_tracker.darren_desktop', 'home') else 'mdi:lan-disconnect' }}"
That’s a slight edit as I’m using separate files for the customisation and templates (via !include in configuration.yaml), so I’ve sewn everything together for the above example.
thanks. made my first tracker. 
sensor:
- unique_id: track_marijn
state: >
{{'In huis' if is_state('device_tracker.life360_marijn','home') else 'Uit huis'}}
attributes:
friendly_name: Waar is Marijn
so thats promising no editing, no customizing.
otoh, this icon template wont stick, though it should?
icon: >
/local/images/family/marijn_bmj_{{'home' if
is_state('device_tracker.life360_marijn','home') else 'not_home'}}.png
returns a validation error on non whitespace, which I’ve never seen before:
Error validating template result '/local/images/family/marijn_bmj_home.png' from template 'Template("/local/images/family/marijn_bmj_{{'home' if is_state('device_tracker.life360_marijn','home') else 'not_home'}}.png")' for attribute '_icon' in entity sensor.track_marijn validation message 'contains non-whitespace: /local/images/family/marijn_bmj_home.png'
darn, beginners error, using icon: for an entity_picture…
sensor:
- unique_id: track_marijn
state: >
{{'In huis' if is_state('device_tracker.life360_marijn','home') else 'Uit huis'}}
picture: >
/local/images/family/marijn_bmj_{{'home' if
is_state('device_tracker.life360_marijn','home') else 'not_home'}}.png
attributes:
friendly_name: Waar is Marijn
it is then, using picture: for entity_picture…
entity card doesnt show the picture, the entities card does:
never realized that tbh, same goes for the fact we can not edit the picture in the editor GUI
but that might be another matter? editing the template: entities and showing them in the frontend
I’m a little surprised that you’re seeing sensor.track_marijn and not sensor.template_track_marijn .
Every time I tried the set-up like yours (as per the post 7 from 123 above, where he also highlights that limitation) I got the template prefix that I couldn’t get rid of. The only difference is the icon / picture usage as far as I can see. Or did you adjust it in the UI or elsewhere?
Ditto. I pasted the example into my test system and the resulting sensor’s object_id includes the leading word “template”. Would be interesting to know what Mariusthvdb did to eliminate it.
Nevermind, I figured it out. You can modify the sensor’s object_id using the dialog-box shown in Mariusthvdb’s post.
So we have control over the object_id but via an extra editing step. 
I would prefer if it didn’t prepend “template” and simply used the supplied unique_id verbatim.
I have to say, getting modern format to reproduce what was easily done in legacy format has been quite the puzzle.
