Migrating legacy templates to the new template section

[123 (Taras)]

I think the long and short of it is that this new arrangement won’t please everyone. What I hope will happen is that those who are short-changed by it will ask for improvements (and hope the development team adopts them). I won’t be part of that effort, because the new way satisfies my needs, but I encourage others to voice their suggestions for improvement.

Way back, when entity_id was eliminated from Template Sensor, we adamantly defended its need. Although it was never restored, bdraco heard us and did refine the new system to be even more efficient. It was still not as fine-grained as what entity_id allowed but pretty darn close (with a few notable exceptions). Fast forward several months and now the Trigger-based Template Sensor gives us even more fine-grained control than entity_id ever did.

[petro]

Then stop perpetuating things by saying things like:

@Mariusthvdb

he assured me that wouldn’t be the case.

but, we all know that happened before,

You’re welcome to be upset at me all you want. But my comments are a direct response to your actions which brought another individual saying the exact same thing. All of which, is untrue. Do you want these responses from me to stop? Then stop all this what-if-isms.

[Mariusthvdb (Marius)]

Are you saying then that ‘legacy’ is something else than ‘deprecated’? because earlier today you said this about that.

btw:

[petro]

Yes it is. It even explains it in your definition. Deprecated and legacy have 2 different meanings.

Edit: to clarify:

Deprecated: will ultimately get removed
Legacy: no plans for removal but not the current way of doing things.

[CentralCommand (Mike)]

@Mariusthvdb

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

Damn. This has now really put a damper on the whole release for me. Template sensors are probably a majority of my YAML config so lack of support for their modern config in packages is a real problem. Now I have these crappy choices:

1. Move them all to modern config and don’t use trigger template sensors at all. This is where I am now but its not great, I wanted to make some trigger template sensors
2. Leave all my packages using the legacy config for sensors and binary sensors. Remove the ones that should be trigger template sensors out of their corresponding packages and put them somewhere else. This will work but it will frustrate me when I can’t find them where they are supposed to be later.
3. Refactor my entire config to stop using packages and figure out a new organization system.

#3 is not what I was planning to do this weekend but I guess here we are. Packages don’t serve much purpose if they can’t encapsulate functionality. Bummer that it looks like they’re becoming legacy config too.

[Mariusthvdb (Marius)]

just for the sake of being complete, I wrote this FR, which you could add to and support:

Allow integration template: in packages

the new top level integration template: offers great new functionality (much appreciated trigger based template sensors). However, unfortunately we can not configure these in our packages. There’s been some discussion on this, eg see: and it would be appreciated very much if the new integration template: could be configured in packages, just like any other top level integration can be. This way we can keep all relevant config sections together. I am aware we can do: template: !include …

[Mariusthvdb (Marius)]

there’s a stop gap you could use (and no, I understand this is not the same, but it allows you to keep at least these new config entries together):

template: !include template.yaml

[petro]

if you want to break it up, treat it like automations:

template: !include_dir_merge_list template

Then create a template folder in the root config directory.

Then create as many files as you want with as many sensors as you want.

[CentralCommand (Mike)]

Yea I know, just put the same on the feature request. I mean that’s fine it just means I have to re-organize. Packages provided a nice mechanism of encapsulating the config for specific functionality. That made it easy for me to find what I’m looking for when I needed to change something. But all of my packages have numerous template sensors so if those get ripped out then the whole thing becomes kind of pointless and I’ll need to re-organize.

Also I raised this on the feature request but this makes sharing functionality a lot tougher. I mean yea blueprints are nice but you can only blueprint up one automation or one script. A package could include multiple automations/scripts as well as any supporting infrastructure required (like template, commandline or utility sensors). Now there’s a huge chunk of functionality that can’t be put into packages and easily shared as one self-contained bit of config.

[petro]

Yeah I just was trying to offer up a solution to your troubles up here

Migrating legacy templates to the new template section

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.

[CentralCommand (Mike)]

Thanks! Yea I mean there’s fine alternatives. I’m not like mad or anything just a little bummed.

Honestly I was actually really hoping someday there’d be blueprints of packages. So you could make some complete functionality, package up the entire thing (automations and all the supporting infrastructure) and users could use it by just filling in a few pre-defined inputs. But now it seems like packages might be on their way out instead

I’m probably reading too much into it though. I’ll continue to hold out hope

[paddy0174 (Patrick)]

@CentralCommand

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.

Could you please explain a little more, what you mean by “within each feature-specific package”? Do you sort your packages like packages/sensor.yaml?

[jazzyisj (Jason)]

Can’t speak for @CentralCommand but my package files are organized like this. Everything is in packages. Everything related to say my alarm clock is in the alarm clock package including customizations, helpers, template sensors etc. etc.

I’m going to be super bummed if this is the beginning of the end for packages.

[CentralCommand (Mike)]

My configuration.yaml is basically just this:

homeassistant:
  auth_providers:
    - type: homeassistant
  allowlist_external_dirs:
    - /config/packages
    - /config/blueprints
    - /config/common
  packages: !include packages/packages.yaml
  customize: !include customize.yaml

My packages/packages.yaml is this:

base: !include_dir_named base
update_notifications: !include_dir_named update_notifications
room_presence: !include_dir_named room_presence
eta_tracking: !include_dir_named eta_tracking
temp_humidity_tracking: !include_dir_named temp_humidity_tracking
battery_alerts: !include_dir_named battery_alerts
host_backups_network: !include_dir_named host_backups_network
home_management: !include_dir_named home_management
weather: !include_dir_named weather
task_management: !include_dir_named task_management
recorder: !include_dir_named recorder
mobile_management: !include_dir_named mobile_management
sleep_guests: !include_dir_named sleep_guests
energy_tracking: !include_dir_named energy_tracking

Then within each one of those folders is a file per component type like sensor.yaml, binary_sensor.yaml, alert.yaml, etc. which contains definitions of that type of thing for that particular named set of functionality.

[paddy0174 (Patrick)]

@CentralCommand Thanks, that’s an interesting way to split it. Gives me another idea how to set this up.

@jazzyisj That’s the way I’m doing it right now, but the files get bigger and bigger. In three files I have more than 1000 lines, it get’s confusing more and more… So I’m looking for a way to declutter it. Seems the new template “feature” doesn’t make it any easier…

EDIT: should add, that I’m currently have to write some kind of documentation, as my wife rightly points out, what if I’m not around… So clear and easily readable packages would be very welcome…

[jazzyisj (Jason)]

I guess I left out the fact that my automations and scripts both live within their own directories with subdirectories that match the packages to keep them organized. I like to keep separate files for each automation and script (or group of small automations/script). Makes them easier to find. Most of my actual package files are quiet manageable since I’ve organized it this way.

[petro]

have you tried putting friendly_name inside the attributes section?

EDIT: No reason to check, I tried it on one of my sensors and it works.

[jazzyisj (Jason)]

I was going to try that myself but then I realized the attribute wouldn’t display where the name usually would.

I think Thomas’s template entity row plugin is a good method replace the friendly_name functionality. I only have a couple of places in my front end that are impacted though so it’s an easy fix for me.

Nvm. I’m dumb. The name attribute is still a template. All my template sensors works with the new format.

[Mariusthvdb (Marius)]

there’s a big difference between name: and friendly_name:

see a lengthy discussion Add (bring back) friendly_name to template sensors - #3 by 123 when I added my FR for bringing back friendly_name back to the default configuration variables for template:

apparently it can be done. It bewilders me though why such a core configuration variables for almost any integration in HA should be moved to hand made attributes on this new template: integration.

More flexibility ? No, because it has always be an optional variable? Confusing? yes, because by default the new default variable name: creates the object_id, which is very counter intuitive, coming from the legacy friendly_name, and which was there to do just the opposite, allow the user a friendly_name different from name/object_id…

This is still in development, so I hope the default friendly_name can be added to template:, and the documentation should be more precise and explicit, like Petro lists here: Add (bring back) friendly_name to template sensors - #10 by petro

[petro]

@Mariusthvdb

More flexibility ? No, because it has always be an optional variable? Confusing? yes, because by default the new default variable name: creates the object_id , which is very counter intuitive

That’s how name works in every other integration. This is nothing new, just new to templates.

@Mariusthvdb

This is still in development, so I hope the default friendly_name can be added to template:

It won’t. Balloob has been against it even in the old integrations, that’s why some template integrations do not have a friendly_name_template. Just use the method I listed. Friendly name is an attribute, so list it in attributes.

I don’t understand why you’re still upset. You have the ability to do what you want but you still don’t like it. Common man, it’s the same thing just configured differently.