Migrating legacy templates to the new template section

Configuration
1

To answer my own question…

ERROR (MainThread) [homeassistant.config] Invalid config for [template]: [friendly_name] is an invalid option for [template].

2

You can’t continue using the friendly_name option because, if you check the documentation, it no longer exists in the ‘modern’ format.

The name option is the replacement for friendly_name. The following configuration produces an entity called sensor.internet_connection whose friendly_name is “Internet Connection”.

template:
  - sensor:
      - name: Internet Connection
        state: "{% if is_state('binary_sensor.WAN_Check_BBC', 'off') and is_state('binary_sensor.WAN_Check_OpenDNS', 'off') %}Offline{% else %}Online{% endif %}"

In other words, name serves two purposes:

  1. Becomes the entity’s friendly_name
  2. After conversion (lowercase and certain characters replaced by an underscore) it becomes the entity’s object_id.
3

guess that finally realizes this FR.
Balloob opposed this FR heavily, as he stated name shouldn’t be templated (because he felt that we were (mis)using it as State replacement.)
Glad that developed into this now.

Otoh, if we can’t declare separate sensors names and sensor entity_id’s in the config, that will require a lot of extra customizing. many sensor entity_id’s in my setup have pre-/-suffixes, to be able to easily auto_sort them, or indicate the integration that makes them. I don’t want all that in the frontend, so use a shorter more friendly name, eh, well friendly_name…

wait. my FR still holds, (though will never see the light of day) because we need different object_ids and friendly_names… bummer.

4

Agree, I tend to keep the programming/YAML in English whilst having translated (German) descriptions in Lovelace. For this I used German friendly_names whilst keeping English names for the sensors itself. If this now needs to be done via customisations, that is a bummer.

5

Wrote up a FR for adding the configuration variable friendly_name: to the template: integration

please vote up and add with your reasoning/needs, which indeed is very valid (Dutch here, and indeed translating many English object_ids in my own language too)

6

coming to think of it: the sudden demise/deprecation/phasing_out of friendly_name: as configuration variable is a Huge breaking change not mentioned.

that should really be added to mark the occasion

( I already here the digital people say, hey it’s not deprecated in the legacy config, and this is a new integration…)

2 Likes
7

If you set a value for unique_id on your sensors then you can change the name, id and icon from the GUI. So what I’d recommend is add a unique_id to each of your sensors in the legacy format and restart HA (or reload templates) so it registers all those entities with the name and ID you picked. Then convert to the modern format and just drop the friendly_name field entirely. The friendly_name and name fields don’t matter anymore because the name and ID are just set from the UI.

2 Likes
8

It’s not a breaking change.

  1. Nothing breaks on upgrade therefore its not a breaking change
  2. There’s a mechanism to migrating to the modern format and maintaining your friendly_name and entity_id values even if they aren’t the same. Add a unique_id, restart (so it registers all the entities with the name and ID you picked), then convert to modern format. You don’t even need to specify the name field if you do that, it doesn’t do anything. The entity ID and name are editable from the GUI now.

The conversion from old to new was not intended to be free hence why the old configuration is being phased out over time and not just dropped. As long as there’s a way to maintain everything its good (and there is)

9

It’s not a breaking change… it still exists in the old method normal template sections, it doesn’t exist in the new template trigger section. You don’t have to switch to the new template trigger system.

10

adding a unique_id might be a good start to prepare for the more from yaml to UI… because that’s what this is of course.

Then again, when in Yaml mode, can we at all edit these entities? Don’t think we can, so there’s that…

All in all, I feel this is no the end of this move in the template sensor department, maybe its better to wait and see for a bit, before changing too much in the current config.

yeah, I noticed your edit, but I think your earlier text was alright. After all, even the docs now talk about ‘legacy’ configuration for templates. It is after all not a template_trigger platform, but a new template: integration, which has trigger based sensors as main new asset.

As said, will wait and see for a bit.

11

Actually looking at the doc I’m realizing its not quite this simple (although it will be most of the time). The name field accepts a template since it is a replacement for both friendly_name and friendly_name_template.

I never used friendly_name_template personally but now I’m wondering what happens if you do. Does the entity ID become the template with all special characters replaced with underscores or the initial rendering of the template with all special characters replaced with underscores? :thinking:

12

It’s not a move! It’s an addition to templates. I don’t know where you got this “move” from. This is a trigger template, it’s not the same as the template entities.

13

Very useful thank you - so from my example:

wan:
   friendly_name: "Internet Connection"
   value_template: "{% if is_state('binary_sensor.WAN_Check_BBC', 'off') and is_state('binary_sensor.WAN_Check_OpenDNS', 'off') %}Offline{% else %}Online{% endif %}"

restart with:

wan:
   unique_id: wan
   friendly_name: "Internet Connection"
   value_template: "{% if is_state('binary_sensor.WAN_Check_BBC', 'off') and is_state('binary_sensor.WAN_Check_OpenDNS', 'off') %}Offline{% else %}Online{% endif %}"

then transitions to the new format as

- name: "Internet Connection"
  unique_id: wan
  state: "{% if is_state('binary_sensor.WAN_Check_BBC', 'off') and is_state('binary_sensor.WAN_Check_OpenDNS', 'off') %}Offline{% else %}Online{% endif %}"
2 Likes
14

Sure, it is the new Template platform, which for binary sensors and regular sensors is moved to Template - Home Assistant from: Template - Home Assistant and Template - Home Assistant

and yes, its got the additional trigger section, which is cool.

15

That works although keep in mind you don’t actually see unique_id anywhere, its just a unique ID shoved into the entity registry. I would personally just generate a UUID value like wan_10de553fcd6f47569fdb75abe8e4664b. Just to eliminate any risk of accidently picking the same ID twice.

1 Like
16

I liked the changes to template, already migrated and improved existing templates with the new triggers and auto off, thanks a lot!

Templates are really powerful in HA and I think the next proper step will be to make templates similar to the Helpers (added and managed through the UI), we could even preview the result similar to how the developer tab works.

17

But now, don’t you have to remember where the individual sensors are created - are they now in the "templates.yaml’, “sensors.yaml/binary_sensors.yaml”?

Before all sensors were in sensors.yaml or binary_sensors.yaml. If I am looking for one of that type of sensor I know what section to look in whether it was a template sensor or not.

Now you can have both sensors and binary_sensors uinder the same templates.yaml. So now I have to remember if the sensor was created with a template or not in order to figure out what section to look in - templates.yaml or sensors.yaml.

If the goal was to add a trigger template sensor then it would have made more sense to just add the trigger template sensor under the existing template sensor config.

I don’t see how creating an entire new domain that mixes and matches other already existing domains under it was helpful from an organization standpoint.

2 Likes
18

There is no reason to transition… Literally keep what you already have. Ask yourself the following question:

Do I want to have a binary sensor based on a trigger or event? If yes, then use the new template integration.

It’s not a “new” format. It’s the format for the trigger templates. What everyone is referring to as “old” is not old. It’s the other type of template sensors and they are NOT going away.

They did not move. They are trigger templates not to be confused with binary_sensor and sensor templates. Please stop making it seem like it moved, you are confusing people.

2 Likes
19

and we can not use them in packages unfortunately , though I truly don’t understand what Frenck says here template sensor in package · Issue #50157 · home-assistant/core · GitHub

1 Like
20

I mean if you want this you can still do it:

template:
  - sensor: !include sensor.yaml
    binary_sensor: !include binary_sensor.yaml

Organize your YAML however you want, there’s lots of ways to split the config. Personally I prefer packages so this new mechanism is a plus to me, I can have all my template sensors in one place within each feature-specific package.