Oh. I guess that makes sense then, I’ve never done that in any of my template entities. I always provide a name and also provide a unique ID 99% of the time (basically only omit if I’m testing something I’m going to delete).
Although I kind of wish unique_id was just a boolean. Like “do you want me to generate a guid for you or not?”. I just have a little python script I run to generate a guid for me and copy and paste it in. Not like anyone ever sees that value.
Any idea if there will be a fix for this behavior. With the new template it is impossible to define the entity id via the yaml, only changing it back in the gui fixes it but is isn’t really a solutions. I tried the following combinations (all after fully deleting the old entities:
- unique_id: temperature_woonkamer
name: Woonkamer temperature
unit_of_measurement: "°C"
state: "{{ states.climate.woonkamer.attributes.current_temperature }}"
attributes:
friendly_name: Friendly Name
results in:
entity_id: sensor.woonkamer_temperature,
name: Woonkamer temperature,
friendly name: ignored
- unique_id: Temperature woonkamer
unit_of_measurement: "°C"
state: "{{ states.climate.woonkamer.attributes.current_temperature }}"
attributes:
friendly_name: Friendly Name
results in:
entity_id: sensor.template_woonkamer_temperature,
name: Friendly name
- unique_id: Temperature woonkamer
name: Woonkamer temperature
unit_of_measurement: "°C"
state: "{{ states.climate.woonkamer.attributes.current_temperature }}"
results in:
entity_id: sensor._woonkamer_temperature,
name: Friendly name
So seems there is no possibility to have the entity_id without the template_ or different then the friendly name. I cannot find is as a bug somewhere, is this by design and do we need to keep it with the legacy format to define a own entity_id via the yaml different then the (displayname)?
use:
- unique_id: temperature_front_room_tester
state: >
{{state_attr('climate.front_room','current_temperature')}}
and change both entity_id and name in the UI to your liking.
after first template reload
change name and entity_id:
result:
btw, you could even care less, and simply have the Frontend config handle it for you. including an icon 
- type: entities
title: Set Friendly name in Lovelace card
entities:
- entity: sensor.temperature_front_room_tester
name: My friendly name in a card
icon: mdi:thermometer
Hi,
I still have somes trouble with new template definition for sensor/binary_sensor.
As behind, I want to defined a sensor with a specific object_id (technical, in english) and a friendly name (human easy reading name. like “Leavingroom switch”).
I think it’s important too be able too setup in yaml, i don’t want to have to use UI to custumize de friendly_name like in your message @Mariusthvdb .
with the yaml below it’s don’t work :
- unique_id: temperature_front_room_tester
name: Front Room Temp
state: >
{{state_attr('climate.front_room','current_temperature')}}
the result is not what i expect :
The unique_id is not taken in account, if name is given.
I try other yaml setup, like :
- unique_id: temperature_front_room_tester
state: >
{{state_attr('climate.front_room','current_temperature')}}
without name, but the result is not good :
I try to setup the name and change friendly name by customize section in yaml
template:
- sensor:
- name: temperature_front_room_tester
state: >
{{state_attr('climate.front_room','current_temperature')}}
homeassistant:
customize:
sensor.temperature_front_room_tester:
name: Front Room Temp
But once againt, it’s not the expected result
To make thoses tests you need too delete entity between each test, because entity are store in files in .storage folder.
Is-it realy difficulte to add object_id entry like in older yaml definition because the following yaml work perfectly :
sensor:
- platform: template
sensors:
temperature_front_room_tester:
friendly_name: Front Room Temp
value_template: >
{{state_attr('climate.front_room','current_temperature')}}
result is good.
Thanks for your help.
The work of HA team is amazing ! Thanks to all…
if only for convenience: add a unique_id, also to the legacy format.
You’ll be able to edit in the UI, and quickly appreciate the advantages.
btw in the yaml format (the legacy format is what you mean) you should customize ]friendly_name:, not name: like you do now.
wait, your are not using the legacy format in the last example, but keep mixing styles and techniques. Either use legacy, and customize friendly_name:, or use the new template: format, and set name: in the config itself (or edit it in the ui)
But the problem is, if you do, the unique_id entry is ignored and overridden with one generated from the name. As I understood the unique_id is deprecated and ignored, but that does not appear to be true reading the docs. So it feels like a bug to me.
unique_id is not overridden. You shouldn’t fight the idea, but work with it. Unique_id is used perse to make the entity editable in the UI.
It doesn’t have to relate to the entity or integration at all, in fact you can use, and many do, a unique_id creator like https://www.uuidgenerator.net to do that for you.
After that, you want to change the resulting templates name and entity_id probably, depending on how detailed you configure it in the yaml. It wont change the unique_id. (which you can check in the .storage)
its all been said and explained above, most eloquently by Petro (search for it in this thread)emphasized text
I’m not 100% sure what I said is true anymore because of the introduction of templating the name field. That changed the behavior. As far as I can tell, you can’t get the entity_id you want and the friendly name you want out of a single config if you want them to differ.
It’s not a bug btw, it was by design because people wanted to template name. Stupid decision IMO but people wanted it the way it is. I’ve been toying with the idea about adding object_id to the new template configuration, I just haven’t had the time (been building a deck on my house).
Why does a templated name pose problems for unique_id? Or does templated names imply you can setup multiple template sensors in one go if the template expands to a list?
Logical to me seems: If you supply a unique_id it is used, otherwise it is generated from the name. if you supply a templated name, you cannot specify entity_id yourself (unless that also supports templating, which I assume it doesn’t).
Nothing poses problems for unique_id. Templating the name poses a unique scenario for the entity_id generation.
When you omit a unique_id, the name (sluggified) is used to generate the object_id. When you use unique_id without a name, the object_id becomes {integration_identifier}_{unique_id}. When you include both, the object_id becomes the name (sluggified). This is how it works everywhere btw, not just templates.
When you introduce a template to the name, it resolves the template, sluggifies the name, and uses that as the object_id.
At some point, it was determined that you can’t template both friendly_name and name because it becomes a “who resolves first”. And it was removed. So now you have to use various combinations to get what you’d want.
EDIT:
I think you are having issues with unique_id btw. It’s an ID that’s used to generate a entity registry, which allows users to adjust the attributes via the UI. It has nothing to do with the entity_id or anything else. If you continously change the unique_id between restarts, you’re effectively creating new entities while the old ones still exist in the system. And if you kept the name the same the whole time, you’d see your entity_id’s increment because the entity_id is already in use (By the previous unique_id).
Exactly that. Unique_id is a set and forget.
In my config I can change anything in the Ui that hasn’t been set in the yaml. Provided the unique_id.
Name/icon/device_class/object_id . the latter is ofc the same as entity_id really.
Ofc, when you set a template in the yaml , you don’t want to change that in the Ui. Tbh, I truly don’t understand the noise that has followed in this FR after it was solved such a long time ago….
I’ve seen that happen indeed. All the different ID’s confuse the hell out of me. I put the unique_id in because I thought I had to in order to be able to set an area in the UI. But then I started seeing the id in the yaml was not the one I saw in the UI. So I changed it in the yaml to reflect what I saw in the UI, only to find that it somehow cause things to be recreated. So then I used the UI to rename the ID I saw there (which I now realise is the entity_id and not the unique_id?) and my OCD was at ease again 
For me that’s the point, I need the capability to set the object_id.
Take time you need, it’s not a big issue while I can use old plateform: Template format.
Thanks for your response.
BR
you can change object_id in the UI using the new template: syntax
the template sensor doesn’t allow copy and past of the entity_id (step backward) and doesn’t allow dynamic display names. e.g. the folllowing doesn’t work
- sensor:
- name: QQQ percent change today
unique_id: qqq_percent_change_today
unit_of_measurement: "%"
state: >
{{ "{:.2f}".format((state_attr('sensor.qqq', 'regularMarketPrice') | float(0) - state_attr('sensor.qqq', 'previousClose') | float(0)) / state_attr('sensor.qqq', 'previousClose') | float(0) * 100) }}
availability: "{{state_attr('sensor.qqq', 'regularMarketPrice') != none and state_attr('sensor.qqq', 'previousClose') != none}}"
attributes: { "friendly_name": "{{ 'QQQ ' + '{:.2f}'.format(state_attr('sensor.qqq', 'regularMarketPrice') | float(0)) }}" }
simply use the friendly_name: template directly under name:
- unique_id: driveway_buiten_sensor_light_level
state: >
{{state_attr('sensor.driveway_buiten_sensor_illuminance','light_level')}}
name: >
Driveway buiten:
{% set light_level = state_attr('sensor.driveway_buiten_sensor_light_level','lightlevel')|int %}
{% if light_level < 1 %} dark
{% elif light_level < 3000 %} bright moonlight
{% elif light_level < 10000 %} night light
{% elif light_level < 17000 %} dimmed light
{% elif light_level < 22000 %} 'cosy' living room
{% elif light_level < 25500 %} 'normal' non-task light
{% elif light_level < 28500 %} working / reading
{% elif light_level < 33000 %} inside daylight
{% elif light_level < 40000 %} maximum to avoid glare
{% elif light_level < 51000 %} clear daylight
{% else %} direct sunlight
{% endif %}
device_class: illuminance
you shouldn’t (cant?) use both, name is the direct replacement for friendly_name
and, if its only for the frontend, you could always use template entity row
I’m subborn in my desire - I want a clean and static entity_id and a useful and dynamic friendly_name.
friendly_name may have been better titled display_name, because friendly_name leads to semantic confusion, ambiguity and misuse. a “friendly entity_id” is redundant to “entity_id” and I think this is the direction that has been taken
really I am not sure what you’re on about.
I have all my template sensors use a static entity_id (can configure those via the UI even) and yes you can have a dynamic name:
as I illustrated above.
Why not go with the new flow, instead of fight it (because it’s named differently). It’s all there. Use it.