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

[e-raser]

I’m trying to use the “modern configuration” for a template sensor for the first time (according to Template - Home Assistant).

What I have:

template:
  - sensor:
      - name: Statistik Entitäten gesamt
        unique_id: statistics_entities_total
        state_class: total
        icon: mdi:numeric
        state: "{{ states | list | length }}"

What I got:

1. How do I set the entity_id?
I thought the value set for unique_id would be used for this. I don’t want (initially!) the entity_id to be based on the entity name. That has a few downsides like trash being sent to the InfluxDB, additional manual steps etc. etc…

What I found (and couldn’t imagine this really is the “new and recommended way” - really guys?!?):
I need to do this manually after creating the sensor using customization.yaml or the UI. That’s a big step back dear devs. Almost doubles the work… I tend to switch back to the old format, same situation like Mutt in Use of new (template) sensor/binary_sensor format - #13 by Mutt.

2. How to set the availability?
If - for whatever reason - the sensor value can’t be calculated (or is negative/below zero), I want the sensor to be unavailable. This is not based on another sensor value like we typically use for availability, but the sensor value itself. Do I need to repeat the state content or is there some kind of “self-reference”?
In other words: in the above example, do I need to use this or is there a smarter, less repeating way?
availability: "{{ (states | list | length) | int(0) > -1 }}"

[123 (Taras)]

@e-raser

I thought the value set for unique_id would be used for this.

It uses name to create the entity_id.

@e-raser

How to set the availability?

All it requires is a template that, after evaluation, reports either true or false. Whatever you put in the template simply has to adhere to that requirement.

Whereas an automation has a this state object, with various properties, it doesn’t exist in Template entities

[e-raser]

So to sum up:

• with the new style of creating a template sensor it is impossible to set the initial entity_id (or even - if not using a unique_id - impossible to set it at all)
• for the availability / availability_template the code doubles when it has the same content/check as state / value_template because there is no this object or even variables (please vote for Support Variables in Template Sensors)

Great step forward, really

[123 (Taras)]

Your first statement is false and your second statement is moot because it reflects the status quo (i.e it also applies to legacy Template entities).

@e-raser

Great step forward, really

I would agree with you if you weren’t being sarcastic.

[petro]

Add a unique_id, name, and friendly_name (in attributes) to set all 3 initially. Otherwise, use customize or set name (for entitiy_id) & unique_id, then change the name in yaml, then reload.

[e-raser]

@123

Your first statement is false

That is with the new style of creating a template sensor it is impossible to set the initial entity_id. Proof me wrong. I could not find a way.

@petro

Otherwise, use customize or set name (for entitiy_id) & unique_id, then change the name in yaml, then reload.

That’s exactly what I meant by saying ‘Where’s the big improvement here?’. There’re (still) additional tasks required. Compared to the legacy method those are just other tasks, but not less…

@petro

Add a unique_id, name, and friendly_name (in attributes) to set all 3 initially.

I tried that, but what do you mean by “in attributes”? I don’t know how to do this. Using it regularly “the oldschool way” gives an error

Invalid config for [template]: [friendly_name] is an invalid option for [template].

Now I’m really excited to see how to solve this. I’m not an expert, a plug’n’play yaml code snippet would shorten things a lot. I’m not the first (that’s probably Use of new (template) sensor/binary_sensor format) and for sure not the last one looking for a solution for this.

[petro]

@e-raser

That is with the new style of creating a template sensor it is impossible to set the initial entity_id. Proof me wrong. I could not find a way

Lets say I want the entity_id to be sensor.livingroom

template:
- sensor:
  - name: LivingRoom
    ...

I think you’re blowing this out of proportion… relax and just try to solve your problem by asking questions. No need to complain on top of it.

@e-raser

That’s exactly what I meant by saying ‘Where’s the big improvement here?’. There’re (still) additional tasks required. Compared to the legacy method those are just other tasks, but not le

The improvement is that you can now use triggers to update template sensors, which many people wanted. You can still use the old template style. You don’t have to use the ‘suggested way’.

@e-raser

Invalid config for [template]: [friendly_name] is an invalid option for [template].

It has to go inside attributes.

template:
- sensor:
  - name: ...
    unique_id: ...
    attributes:
      friendly_name: ...

[CO_4X4 (Colorado Four Wheeler)]

You know, when I switched from the “old” method to the “new” method I struggled with this as well. The entity ID always comes up as whatever the name of the sensor is, but parsed to be properly formatted (i.e., Bedroom Motion Sensor becomes sensor_binary.bedroom_motion_sensor).

At first it was annoying because I didn’t see it as a direct replacement, then I considered that any other device added to HA, such as Insteon, Z-Wave and others, force you to rename the entity in the UI if you want it some other way anyway. So, when you think of it, template entity_id’s were outside of the norm when they were implemented, the new format brings it back in line with other entities.

In the end, I just switched everything over to the new format, making notes of the old entity ID’s then went in and edited those sensors to set the entity ID to whatever I wanted to.

In the end, you could also stick with the old method instead. I’m not sure when that goes away forever, but you can still use the old instead of the new.

[petro]

@CO_4X4

I’m not sure when that goes away forever, but you can still use the old instead of the new.

No plans to remove it.

[e-raser]

@petro

It has to go inside attributes.

Still does not work.

Input:

      - name: statistics_entities_automations_power_percentage
        unique_id: statistics_entities_automations_power_percentage
        attributes:
          friendly_name: Statistik Entitäten Automatisierungen Power anteilig

Output:

Up to now I thought I just don’t know how to. Meanwhile I think it’s not possible. Too bad cause I need to create a lot of template sensors and every additional step after the initial configuration in .yaml is a bit of a pain tbh.

[petro]

Was that created from scratch or was it existing? If it’s existing you have to edit it from the UI.

[CO_4X4 (Colorado Four Wheeler)]

And the old entity probably still exists but is not available. I had to delete my old ones in the Entities UI before I could set the new templates to have the same entity ID.

Here’s an example of how I went from old to new:

internet_down_sensor_homekit:
  unique_id: internet_down_sensor_homekit
  device_class: opening
  friendly_name: "Internet Down"
  value_template: "{{ 'off' if is_state('binary_sensor.internet', 'on') else 'on' }}"

binary_sensor:
  # LEGACY ENTITY: internet_down_sensor_homekit
  - name: "Internet Down"
    unique_id: c1bfea3a-f13b-4797-befc-547aae9c3ba5
    icon: mdi:web
    state: >-
      {{ 'off' if is_state('binary_sensor.internet', 'on') else 'on' }}

[e-raser]

Completely new. First time created in something.yaml, reloaded template sensors, and that’s the output.

Mission impossible.

To be very precise: I do not convert existing sensors from legacy to new template sensor definition method. I create a new template sensor for the first time. It never existed before.

[petro]

If you create the new templates properly, then can takeover the old template entity. I forget how I did it, but it’s possible.

[petro]

Then use the old format , no one is forcing you to switch.

[CO_4X4 (Colorado Four Wheeler)]

@e-raser

To be very precise: I do not convert existing sensors from legacy to new template sensor definition method. I create a new template sensor for the first time. It never existed before.

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.

[petro]

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.

[CO_4X4 (Colorado Four Wheeler)]

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.

[e-raser]

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.

1. create template sensor in something.yaml
2. 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:

1. setting entity_id → which is always set by modern name: tag. So what I was really looking for is the friendly_name.
2. a question related to availability which 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).

[123 (Taras)]

@e-raser

it is impossible to set the initial entity_id. Proof me wrong. I could not find a way.

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.