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

Configuration
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.

41
42

Petro

It’s only shifting this direction because most people want to edit entities in the UI, including yaml entities. Just do a simple search for “This entity does not have a unique ID” and you’ll fine 100s of threads about adding unique_id to yaml or how to customize yaml only entities. When you add unique_id to an integration, this is the trade off that you get. The unique_id / name convention builds the entity_id off one of those 2 fields and automatically increments it if there’s a confliction. If you want to generate an entity_id and a differing friendly name, then you have to use customize. Otherwise just use name alone and be done with it.

2 Likes
43

Unfortunately didn’t work. If I’ve not messed it. I mean keeping the chosen id convention, for use in automations.

mqtt:
  sensor:
    - unique_id: energy_battery_voltage
      name: 'Battery voltage'
      icon: mdi:battery-charging
      state_topic: "storage/battery"
      value_template: "{{ value_json['voltage'] }}"
      unit_of_measurement: "V"
      device_class: voltage
      state_class: measurement

imagen
imagen771×197 10.2 KB

Perhaps it was so nice to be true. (Customization still required)

EDIT:
The following is the combination that works. It allows for a fixed id, specifies a Friendly name and allows edition (Friendly name translation)

mqtt:
  sensor:
    - unique_id: energy_battery_voltage
      name: energy_battery_voltage
      #name: 'Battery voltage'
    #- name: energy_battery_voltage
      icon: mdi:battery-charging
      state_topic: "storage/battery"
      value_template: "{{ value_json['voltage'] }}"
      unit_of_measurement: "V"
      device_class: voltage
      state_class: measurement 
 
homeassistant:
  customize:
    sensor.energy_battery_voltage:
      friendly_name: 'Battery voltage'
44

I might have used a too strong a word, no offence intended. Saw a couple of times where someone said UI edit is out of the question, that’s why I was left with this feeling.
Will have to read that thread.

I don’t think we will be able to get away without customization in the future, if old style yaml templates become unsupported (I’ll have some lovely days of HA offline then).

1 Like
46

Ofc! None taken.
Was kidding.

1 Like
47

I’ve read about this shifting towards UI configuration across many topics here and have still no clue why it should be necessary to reduce YAML configuration options along the way. Why can’t there be both ways?!?
Maybe new users (I’m new to HA too) find it pleasant to take their first steps in the UI. But soon your instance grows and creating/editing entities via UI gets repetitive and error prone.
So you have to turn to YAML configuration to keep track of your programming (not to mention lovelace).
Prohibiting the possibility to set entity_id and friendly_name in YAML is a design flaw evoked by ideology (like the trend towards vast numbers of sensors instead of one sensor with attributes).

3 Likes
48

I would love to stay on the old model, since I have ~30 template binary sensors setup (my alarm system.)

Can we attach unique_id’s in the old format? I want to start placing these sensors into my Zones.

49

yep

1 Like
50

now that would hardly be a reason not to migrate… 30 sensors wouldn’t take 30 minutes… and you’d be all set

51

When all the template stuff is exposed in the UI, I can remove the remainder of my entries from config and forget about any disparity. I don’t use the config because it’s “faster” or “convenient” or anything like that. My config contains manually entered bits because they aren’t available in the UI yet. That’s it. YAML otherwise sucks, it’s in contention for being one of the worst scripting languages to ever be created. It’s handy to be able to tweak fine details of an entity, but having to do it in YAML is like going to a dentist appointment to put air in my tires. I’d rather be writing PHP, Python, Perl, BASIC 2.0 honestly.

1 Like