Modern template sensor definition style: how to initially set entity_id and friendly_name (and what about availability variables)?

Configuration
21

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
22

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… :wink: )

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.

23

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
24

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
25

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
26

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
27

You have the power to implement those changes or just make a suggestion to.

image
image698×135 8.78 KB

28

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
29

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
30

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
31

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:
...
32

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
33

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

34

Well that’s very nice, thanks for that solution.
But that everything being steering that direction, in my opinion are bad news. Perhaps in a while would have a richer “new way”…

@petro Do you know anything about the possibility to group mqtt entities in a “device” or write them as a template?

35

Marius, that’s a proposal or it’s already available? Because I like it.

36

its available now as of 2022.6

37

The new way is to manage entities through the UI. If you want this to be all yaml, then you have to use customize. I don’t see this every changing and there’s no reason to use unique_id at that point either.

There have been talks, currently this can only be done through discovery.

38

You keep insisting on editing things in the UI :slight_smile: but the main idea is that UI editing is what most of the people complaining here really do not want to do.
I, myself is one of them. I like having everything in YAML and be able to restore to a new HASS instance without then spending hours editing things in UI.

True, Petro’s above solution with YAML customization works and can be acceptable. But having shifting to this direction only adds more complication instead of reducing it.

2 Likes
39

sure, I have all I YAML too. No problem there with my config suggestion. It allows for editing in the UI if you add a unique_id, it doesnt force you to.

Why would you say I

?
Merely suggesting… also because of 2022.6: Gaining new insights! - #356 by Mariusthvdb

40

Is there documentation for me to read? Thank you.
Edit: I’m still on 2022.5.5 … updating :wink:

@clau-bucur That add’s version control. It’s so useful on large/proper implementations.
But it’s not completely true that advanced users don’t like using the ui. I’m myself waiting with hopes of being able to edit “included” files in the gui.