Using unique_id within templates to get state

Because it is not needed.

  • Name: Yours to do with as you please, does not have to be unique. Used for display in the frontend. You can either define it in YAML or change it in the UI depending on the integration.

  • Entity Id: Yours to do with as you please, does have to be unique. Used for entity selection in the backend. Most people use a naming scheme along the lines of <domain>.<location>_<function> e.g. switch.upstairs_bedroom_bedside_lamp You can either define it in YAML or change it in the UI depending on the integration.

  • Unique Id: Does have to be unique, and you can define it for YAML integrations (but not discovered ones?). Used by home assistant to keep track of things like customised entity ids.

@WallyR i know that there is a way via the UI. But im searching for a way without using the UI. I want to be able to configure everything via YAML.

@tom_l can you please give me an exampe for a YAML configuration where i can set all three (name, entity_id und unqiue_id) for a template sensor for example?

You can do this with the legacy format template sensor:

sensor:
  - platform: template:
    sensors:
      your_sensor_entity_id:
        friendly_name: "Your sensor name"
        unique_id: "Your sensor unique_id"

Alternatively, set a unique_id on a modern format template sensor then use YAML customisation to change the name.

An example of the modern template sensor format:

- name: "lounge_dehumidifier_time_remaining" # Customized as, friendly_name: Time Remaining
  icon: "mdi:timelapse"
  state: >
    {% if is_state('switch.lounge_dehumidifier_power', 'on') and (as_timestamp(states('input_datetime.lounge_dehumidifier_stop_time')) - as_timestamp(now())) > 0 %}
      {{ (as_timestamp(states('input_datetime.lounge_dehumidifier_stop_time')) - as_timestamp(now()))|timestamp_custom('%H:%M',false) }}
    {% else %}
      00:00
    {% endif %}

And in customize.yaml

sensor.lounge_dehumidifier_time_remaining:
  friendly_name: Time Remaining

I only did this because I could not be bothered changing the entity id everywhere I’d used it when converting the sensor from legacy to modern format.

I have not yet bothered with unique ids.

Thank you for the example, i’ll give it a try.

Even though the chances are very high, you cannot be 100% sure that the entity_id will become sensor.lounge_dehumidifier_time_remaining because HA has the last word and could append e.g. _2 to the entity_id.
If the unique_id configured in YAML is used for a second sensor an error at startup will be thrown and you will instantly know there is something wrong.

Besides that. I’m wondering why the friendly_name variable was removed from the new format and one has to go detour over customize.yaml?

Finally it is an architectural question wether or not the unique_id should be useable by the user or if it should be hidden from the user.

I can because I know I do not have another sensor entity with that object id. If you are unsure search Developer Tools-> States.

Not sure how you are going to specify a hidden unique id in yaml?

I meant hidden in the sense of “not usable”.

The problem here is that you cannot write yaml that defines and uses a sensor, say in a package, and be sure that it will work, because the sensor it defines might not end up with the entity_id that the yaml uses to refer to it. For example;

template:
  - sensor: 
   # Battery power output, goes negative when battery is charging.
    - uique_id: battery_power
      name: "Battery Power"
      unit_of_measurement: "W"
      device_class: "power"
      state_class: "measurement"
      state: "{{ - (states(sensor.inverter_121630067221) | float) }}"
      availability: "{{ has_value('sensor.inverter_121630067221') }}"
   # Battery power output, zero when battery is charging.
    - uique_id: battery_output_power
      name: "Battery Output Power"
      unit_of_measurement: "W"
      device_class: "power"
      state_class: "measurement"
      state: "{{ [0 ,(states(sensor.battery_power) | float)] | max) }}"
      availability: "{{ has_value('sensor.battery_power') }}"

If you just load this yaml snippet, there is no guarantee that sensor.battery_output_power will actually be based on sensor.battery_power, because there might already be a sensor.battery_power so the one defined in this yaml file might actually be sensor.battery_power_2.

And you will probably not notice this because it will silently apparently work. AFAIK there is no way you can say “use the sensor I defined just up there”.

I agree that using too generic names is part of the problem, but it’s also nasty that it’s a “silent error”. It would be nice if you got a “Error: entity already exists” failure trying to load the yaml.

I think you will get an error if the unique_id is not unique, but that’s not the identifier you use to reference the entity, so it doesn’t really help because even if unique_id is unique, the entity_id could still be automatically changed.