Allow integration template: in packages

Feature Requests
1

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 template.yaml

but obviously isn’t the same.

Please consider. thanks.

2

Well I can’t really imagine putting all my templates into one file as that file would be enormous. I think the alternative right now for those of us with complicated enough configs to use packages would be:

template: !include_dir_merge_list templates/

Then you could break apart the massive list of templates into logical groupings by file. But these files still can’t be grouped with my packages so it leaves me with a headache whenever I want to find the thing I’m trying to change. My packages would contain all functionality except the template sensors (which are numerous in almost all of them).

I definitely support this feature request. If rejected that’s honestly probably the end of packages for me, I’ll have to go looking for another organization method. Will also make it a lot harder to share functionality on the forum.

2 Likes
3

A good summary here

The new integration is for me like integration python_script that is not splitting

On the other hand, I would like both to be supported in the packages method.

:yum:

4

The problem is that ‘legacy templates’ are not recommended according to the docs.

5

That’s why this FR is here !

But it is very pleasant to see that it is possible to always use old method.

1 Like
6

FWIW, Petro examined the underlying code and reported it converts legacy format into modern format.

I guess that’s why it’s been labeled “legacy”. It continues to be accepted but the system does everything in ‘modern’ format so if it encounters the old format it converts it to the new one.

7

to be clear, it’s just an incoming config conversion. I.e. The system sees the old config and changes it to the new config and passes it to the method that creates the sensor. All the more reason to keep the legacy configuration if it works.

8

Good to know. It actually loads config at startup so at that point it doesn’t care anymore about packages anyway.

9

I’d like to see this as well… I use packages for my config, but can’t create new sensors with the new format… unless I migrate my entire config to using the new format, “all at once”. I have a lot of sensors that still use the old format, and while I can add more that way, the new format is useless for me until this can be done.

10

that is not exactly true. you can leave your current sensors, (you are not forced to migrate those at all, and the config wont be taken out, as Balloob has stated) and create sensors in the template: integration. What you can not do is create those in the packages.

11

Fair enough. I did realize that is a possibility. I keep my config organized by packages, so that method would lead to quite a bit of disorganization, which I think is kind of the point of this post.

1 Like
12

Is anyone aware of a workaround that at least permits splitting template sensors into separate files, even if they cannot be included with the packages? In other words, is there any way to have more than one file, each with a bunch of template trigger-based and state-based sensors and binary sensors? I suspect not but would welcome ideas.

If there really is no way, I think the modern template sensor syntax is basically unusable for an installation of any complexity, and this should be reflected in the documentation.

13

yes, see post 2: Allow integration template: in packages - #2 by CentralCommand

14

I’m not sure that works for typical use cases, though. include_dir_merge_list requires the files to contain basically top-level lists. What if I have a state-based sensor that I want in one file, and a state-based sensor and binary sensor in another file? In a single file, they would look like:

template:
  - sensor:
      - name: Sensor for file 1
        state: "Testing"
      - name: Sensor for file 2
        state: "Testing"
    binary_sensor:
      - name: Binary sensor for file 2
        state: "on"

Not sure how this would work.

15

you should take out the integration itself there, because thats already in you configuration.yaml

so no template:

you should be able to do like the example, just above Template - Home Assistant

# Example configuration.yaml entry with two sections
template:
  # Define state-based template entities
  - sensor:
      ...
    binary_sensor:
      ...

  # Define trigger-based template entities
  - trigger:
      ...
    sensor:
      ...
    binary_sensor:
      ...

except for the top level template:, and do so in all files you need, organized according to your personal preferences.

Still no packages of course, unfortunately, but for now this comes closest

16

Does anyone know if this is on the roadmap? My entire config is in Packages.

17

as far as discussions have been going, not yet I am afraid… so the more people upvote this here, the better, and maybe some extra Discord attention…

18

Searching for a solution to the “Package my_results setup failed. Component template cannot be merged. Expected a dict.” stumbled onto his topic and voted it up!

Having template sensors in a different file completely does away with the Packages system.
Strange not more people have flagged this.

19

Works in 2021.8.2.

My setup is as follows-

  1. configuration.yaml in /config 
homeassistant:
  packages: !include_dir_named integrations
  1. template.yaml in /config/integrations 
template: !include_dir_list ../entities/templates
20

with 2021.8.2 Balloob fixed it, this is HUGE.
we can close this FR now. @petro, will you do the honors?

7 Likes