If you create the new templates properly, then can takeover the old template entity. I forget how I did it, but it’s possible.
1 Like
Then use the old format 
, no one is forcing you to switch.
1 Like
Perhaps this is the problem. I believe that both cannot exist at the same time, it’s all or nothing. You either do all old method or all new, if you mix them you end up with old and usually no new ones. At least that was my experience when I tried to have both side-by-side.
You can mix and match, as long as the unique_id’s are unique. Everything is converted to the new format and pushed through the same code.
1 Like
Then I must have messed something up, I had lots of problems until I just converted every sensor/binary sensor to the new format and wiped out the old stuff.
OK. I was assuming this simple thing is possible with the new method - and it was looking good with your friendly_name inside the attributes. But as it does not work… I need to live with additional steps.
- create template sensor in something.yaml
- go to UI / settings / entities and change the
entity_id.
This way is not perfect but at least I can use the new format which might bring some pro’s in the future.
I will update the topic name as I focussed on two main things:
- setting entity_id → which is always set by modern
name:tag. So what I was really looking for is thefriendly_name. - a question related to
availabilitywhich is independent of legacy/modern style.
What I was hoping for is some kind of variable, which there isn’t currently. For this I hope for Support Variables in Template Sensors. E. g. the automation trigger IDs introduced mid of last year improved things a lot (complete new level of creating automations), I hope to see some similar thing for the template sensors too some day (aiming at reducing redundant parts of code).
The entity_id is derived from the name option, just like I explained in my first post.
If name is “Kitchen Temperature” that’s what will become the sensor’s friendly_name and it will become the basis for the sensor’s entity_id like this: sensor.kitchen_temperature (just like CO_4X4 explained). That’s how it’s possible to set the initial entity_id.
What you seem to be struggling with is making the sensor’s friendly_name and entity_id very different. That’s done via customization, like for most other integrations (also explained by CO_4X4). For example, I didn’t care for the entity_ids the Hue integration produced for dimmer switches so I changed them via customization.
1st: Not very different, only different. Just think about languages and the very reduced set of allowed characters for the entity_id for example.
2nd: Some care about their entities a bit more, some less. I was hoping HA is flexible enough to provide a way of sensor creation which initially sets everything, without the need to change something afterwards.
3rd:
Yes, that’s exactly the automatism which forces me to do a second step. I give friendly_name and entity_id. The entity_id I receive is not the same I put in. As simple as that.
So fact is: template sensor definition can’t handle that, you need to go through either UI customization (if unique_id is set) or using customize.yaml afterwards (because the UI option has been removed recently). I was hoping to avoid this additional step.
I’m done with this as I (and you) spent more than enough time on it - if all the experts could not prove it, I must trust them and summarize it simply is not possible currently.
2 Likes
not really want to question your arguments, but why would you need a friendly_name:, while the new template format uses name: for that. Simply see that as its replacement which as a bonus also can be templated, (long standing FR of mine… 
)
and as been said before, you dont even need customize, you can edit all of this sensors options in the UI
there really should be no question to set a unique_id or not. Again, why would you not want to do that. It offers so many advantages
Tbh, I was surprised this isnt a required option in the first place. It guarantees correct back-end operation.
If you don’t want the entity_id that’s automatically produced from name then what you want is different. Therefore it requires you to modify it (via the UI/customization).
Except you don’t “put” an entity_id directly, you put in a name. The entity_id that’s produced is almost identical to it. Not perfectly identical because it must be converted to a slug (which means whitespace and non-ASCII characters are replaced by underscores or their nearest ASCII equivalent).
If what you want is to enter both the name and entity_id in the sensor’s configuration then, no, very obviously that’s not possible for the simply reason only one of the two options exists (but that’s plainly visible in the documentation).
The only way to avoid it is to enter a value in name that represents both the friendly_name and entity_id you want. If you want them to be different (beyond what conversion to a slug normally does) then you will need to perform the additional step.
If you perceive all of this to be terribly onerous, then use the legacy method for configuring Template sensors. However, be advised that if you need a sensor to have a state_class then that option isn’t directly supported by the legacy format (it must be entered via customization). However, it is directly supported by the modern format.
1 Like
I think there’s a lot of good information in this thread that isn’t spelled out in the documentation. As a relatively new user, I’ve read and re-read this page multiple times and struggled to figure out what was spelled out above Template - Home Assistant
Seriously, just saying the words in the post above this somewhere on that page would really, truly help.
4 Likes
FWIW, writing YAML is a form of writing code. I do most of this in VSCode using GitHub as my repo and have pipelines to deploy to HA. Entity IDs are the fundamental linkage between definitions and usage (like automation, Lovelace screens, etc.). Hence it is very useful to be able to search in VScode for an entity ID and find its definition and usages. By not allowing specification of entity id and performing magic on the name to produce the entity Id, this direct linkage is now broken. While I can cross reference through the core entity storage file this is not ideal. However, as a workaround and convention I just write the name as my entity Id with underscores.
In YAML we should have full control of every aspect of the config - no magic please!
6 Likes
I am struggling with this too. Migrated all my “old style” sensors to the modern way in a templates.yaml, but really miss the possibility to add a friendly_name.
I created a naming convention for all my entities like
<room>_<domain>_<position in the room>
but that is seldom a friendly name.
For instance, the entity_ID could be “livingroom_light_couch”, but the friendly name would be “Couch lamp”.
I cannot add the friendly name to the entity in the generated entity afterwards, so I am stuck here. 🤷🏼
4 Likes
I think that if you put a unique ID on the definition - which is allowed, that then you can set the name in the UI, or if you want to do it programmatically via the hass-cli command line tool.
1 Like
Well, adding a unique id might be a possibility, but it feels like a workaround to me. I’m curious what the reason is behind not making it possible to add a friendly name.
3 Likes
setting attributes of a single object in different places of the system is very inefficient approach.
Historically HA provides separate customization of entities, like setting icons. I never understood why it was invented this way. Maybe because back in time integrations were inconsistent so it was easier to program a feature overriding attributes, instead of extending all entities with such options (which should be easy task considering use of OOP though). But OK, it was long ago.
But why recently invented features scatters their settings across various places not allowing to set them in single file, using single method? Really the need of editing name using UI or calling api methods just after editing config files misses the mark.
I understand a need to have option to change name from UI. but it’s not against an option of being able to initialize this name in yaml config
1 Like
I’m on the same boat and struggling with deficient diverse object_id / entity_id / unique_id and name / friendly_name relation implementation.
I find the arguments exposed against the Op’s requirement very scarce. Four wheels doesn’t make enough for a Ferrari. The same way, having the ability of getting an entity name in the interface (any name) does not make for a complete solution but the scarce.
I’m trying to build a package for advanced PV management, and I want to share it with my channel and group friends. I think that’s packages are for. I’m not building an integration or component.
So if I want that this package doesn’t interfere with anything that the installers already has on their systems, I must plan an entity_id (I name it like this bc that’s what gui shows).
The package has lots, lots of mqtt entities. And those end as:
- platform: mqtt
#name: 'Battery SoC'
name: energy_battery_soc
unique_id: energy_battery_soc
state_topic: "storage/battery"
value_template: "{{ value_json['soc'] }}"
unit_of_measurement: "%"
device_class: battery
state_class: measurement
So, the entity id I decided is <package>_<device / section>_<measurement>.
- Name has to be like this or weird things happen. I’ve tried all combinations.
- Unique_id is useless (for me) but I must reiterate or the entity can’t have a human name.
- And then I must rely in the user to know what I’m talking about and write the “friendly name” for himself.
I’m also developer, and with the experience I know this is a fault.
If I put “Battery soc” as a name and don’t look back, the user could be squinting the eyes to get this one over a possibly large list of battery entities. I still don’t know how the included automations would function if the user has a phone battery entity.
Manual customizations are out of the equation if you want to share something or store something for rapid deployment.
Plus platform: mqtt is Pita compared to other entities. Someone talked about doing template entities instead, but I still haven’t found how to write an mqtt template entity. Just to replace the above one, for example. Or even better, to build a battery device that has all it’s measurements in child entities.
The package also has automations and helpers. Input selects, numbers… those are really ok.
The question is: Why all other entities, specially mqtt or modbus, are not defined like helpers? What are the wrong / obsolete one’s?
Please don’t take it badly. I have no intention to offend. Only give feedback and a defined field application where this is a problem.
Edit:
If unique_id is automatically calculated from the name, why isn’t automatically populated for the gui not complaining about not having an unique_id? Why it does exist (in yaml) in the first place?
Wouldn’t be better to have something like this for all yaml entities? (id + name)
platform_mqtt:
energy_battery_soc:
name: 'Battery SoC'
icon: mdi:battery-charging
state_topic: "storage/battery"
value_template: "{{ value_json['soc'] }}"
unit_of_measurement: "%"
device_class: battery
state_class: measurement
Or like gui elements:
platform: mqtt
energy_battery_soc:
...
All entities that follow the unique_id and name paradigm have this design flow, everything is shifting this direction.
If you’re using packages, you can simply setup customized entities in your package to set the friendly name. I.e.
sensor:
- platform: mqtt
name: energy_battery_soc
unique_id: energy_battery_soc
...
homeassistant:
customize:
sensor.energy_battery_soc:
friendly_name: Battery SoC
2 Likes
using the new MQTT format, why wouldn’t you use:
mqtt:
sensor:
- unique_id: energy_battery_soc # or some_other_unique_id_whichisofnofurtherconsequence
name: Battery SoC
state_topic: etc etc
the entity_id would be editable in the UI, and no need for customization