Migrating legacy templates to the new template section

Configuration
48

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.

2 Likes
49

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

@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… :frowning: So I’m looking for a way to declutter it. Seems the new template “feature” doesn’t make it any easier… :rofl:

ha_210507_packages

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… :smiley:

50

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.

image

2 Likes
51

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.

52

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.

53

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

54

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

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.

1 Like
55

No, thats not what I referred to. I was comparing the new config with the now legacy config, where name: didn’t exist as a config variable (so what you state is not correct), and we only had the optional friendly_name:. Of course the sensor_name created the slug, so thats not new

yes, too bad really, and Ive never understood that, but I wasn’t talking about friendly_name_template, but about friendly_name. I do see we now can have friendly_name_template, but, considering Balloob heavy position against that, I sincerely hope the feature is here to stay, and not an oversight on his part.

If only we could use packages…But thats a another FR closed, though the discussion hasn’t stopped

56

@CentralCommand , can you provide an example of how to got this to work in your tamplate.yaml file? I’ve got all of my configuration broken down like this using the !include xxxxx.yaml files to keep everything organized. When I try to do this with a template.yaml file it’s not working. I get the following:

Invalid config for [template]: [binary_sensor] is an invalid option for [template]. Check: template->binary_sensor.

57

use this in configuration.yaml

template: !include_dir_merge_list template

Then create a directory named template inside your config directory.

Then create yaml files with any name, the name doesn’t matter.

Inside the files use the following configuration:

- binary_sensor:
  - name: a
    state: ...
  - name: b
    state: ...
  sensor:
  - name: a
    state: ...
  - name: b
    state: ...
2 Likes
58

If what you say is true, then great. But it goes against what the docs say:

image
image1482×740 151 KB

image
image1652×1002 187 KB

Making a template dir is a work around, it’s not the equivalent as simply allowing them to be merged form a single package file which appears to be the expectation from more users than not

2 Likes
59

Do either of those messages say that it’s being removed? Do either of those messages say it’s deprecated? Do any of the blogs say that they are deprecated? No.

60

No, it’s inherently implied by the fact that you’re recommending people not use it. If it was so star spangle bannered, you would continue to recommend it a way forward.

1 Like
61

Do what you want, I’m done here.

62

I organize mine this way as well, with everything related to a particular “feature” (like my Roomba or Frigate, for example) in its own package file, including any sensors, input helpers, automations, etc…

So using the new template format (or trigger templates in general) would completely break my organization.

63

I found this thread because I was also trying to replace some of my ‘legacy’ sensors in a package with the ‘modern’ sensor.
I was actually trying to get the new Statistics Graph Card to work but a sensor was not showing up. Apparently, specifying “device_class: temperature” was not enough; it also needed “state_class: measurement”. But that’s not available in the legacy.
Does anyone have any insight into how to add a “state_class: measurement” to a legacy template sensor?

- platform: template
  sensors:
    temperature_raw:
      device_class: temperature
      unit_of_measurement: °F
      value_template: >
        {{ state_attr('sensor.28_FF2F0DC01701_temperature', 'raw_value')  *1.8 +32 }}

And I hope there’s a way to keep the ‘modern’ sensors in packages for organization…

64

Until the new template sensors will be available in packages (if they ever will be), you can cjstomize the entity to add the attribute, e.g. from my system:

homeassistant:
  customize:
    sensor.energy_daily_lights:
      last_reset: "2021-07-30T00:00:00+00:00"
      state_class: measurement
1 Like
65

From a purely objective point of view I really don’t see any rational argument for them not being.

Clearly there may be very good technical reasons but that would then just beg the question how did they ever get past any kind of architectural discussion?

I’d be interested to know what percentage of HA users use packages.

66

There are probably some (major) technical difficulties, otherwise I don’t see a reason why it shouldn’t be possible from the beginning.

67

@klogg and @Burningstone

Take a look here and vote, if it fits your needs. :wink:

1 Like