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.
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.
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.
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.
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.
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.
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.
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.
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"
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.