In my opinion, the template integration is really powerful & useful. I already described a lot in this feature request to add templates properly to the frontend. To quote the most part for this:
But, the templates advanced “automation”-like features combined with the ability to blueprint them makes them way more powerful than automations. Because they can introduce button, select or other entities to create “virtual devices”. These entities can define a clear interfaces for other arbitrary users/automations/templates to interact with them. And with their automation-like features directly inside that template, the virtual entities can be made to behave like users expect them to.
And this with the clear advantage that everything is nicely grouped to make it easy for users to manage them. And because they can even blueprinted, really complex automations can be packed into a single blueprint, easy to import & configure.
As an example why I think this is so powerful: I think the generic thermostat functionality, which is currently built into the core, could be replicated by a single template blueprint. (Assuming a template thermostat would be available, it could even provide a thermostat template entity for better UX.) But this does not (just) mean that the generic thermostat implementation of the core is no longer required to be in the core, this rather means that users could easily customize that thermostat implementation in case they need some functionality, without resorting to custom integrations.
I have not found my ideas & thoughts in the forum here or in the discussions tab of the UI, so I am writing this.
To emphasize my point: I think blueprint templates are able to replace some currently built-in integrations. With some (hopefully lightweight) modifications, even more would be possible. For example (I sadly cannot link to their to those because I am a “new user” to the forum, use their quoted names to find them in the integrations list):
- “Mold Indicator” gets three sensors and a static value assigned, and derives one binary sensor with some math.
- This should already be replaceable by a template blueprint.
- “Generic Hygrostat” generate some control entities and automatically controls a device based on one sensor value and some cleverly combined but basically simple logic.
- I am unsure what type of entities this one exposes as the documentation is a little bit unclear, but the basic automatic functionality should be already replaceable.
- “Generic Thermostat” presents & simulates a virtual thermostat by combining rather dumb sensors and heating/cooling devices.
- The functionality can be replicated, but templates sadly lack the ability to provide thermostat entities themselves. But I think adding this should be worth it.
- “Presence-based lights” controls lights based on the state of some sensors.
- “Threshold” observes one sensor to derive a binary sensor from it.
- “Filter”, “Derivative” etc. take one sensor value and uses complex math to convert it into another sensor value.
- I know those are rather limping example, as to represent the math in a template is rather hard. Also I am unsure whether templates can (easily) access historic sensor values.
- But it is something which would be really useful to be packed into a blueprint template, e.g. to build a smarter behaving thermostat, which can then be shared across the community.
To make my point clear, I do like that Home-Assistant already comes with such simple, but useful “automations” built-in, so esp. new or non-techy users have an easy start into the ecosystem. I do not want them to be removed because the template integration can replace those.
But I want to propose for Home-Assistant’s core & frontend development to integrate that functionality based on the “templates” integration rather than building an “integration” for each of those small parts.
This could be realized by:
- adding UI to add “template” entities with the full functionality available via YAML (see here)
- providing UI for template blueprints similar to automation blueprints, allowing users to easily create template entities backed by triggers & actions, without needing to understand their internals
- convert such simple internal integrations into template blueprints, which are shipped with the core
- for the UX, clearly separate “integrations” and “automating stuff”
- then “integrations” can be limited to the aspect of making stuff outside of HAss available to it
- and “automations” or “templates” would then be even more the place to go for automating stuff like light/thermostat control etc.
- looking a little bit further in a possible future: a more user-friendlier hub to share “template blueprints” would be way more useful than e.g. for today’s “automation blueprints”.
I see following advantages for this:
- from the HAss dev side, this should make it easier to maintain such simple functionality
- as they are now based on Home-Assistants automation/template logic rather being full blown integrations
- so it should become easier to ship more of such functionality as blueprints with the core
- I find it kind of weird that built-in “automating stuff” like light/thermostat control is not available in the “Automations & scenes” page, but in the “Devices & services”. Even more irritating is that those “helpers” are documented “integrations”.
- I understand that this reflects the technical implementation side. I want to emphasize this discrepancy between the current UX and my intuition.
- As more experienced Home-Assistant users might already be familiar with the HAss automations, “template blueprints” would allow them to inspect what that e.g. the generic thermostat does. And it would allow them to modify it, if e.g. they need it to behave just a little bit different. All from the UI, without needing to dig into custom integrations.
- Some existing custom integrations, which only are custom integrations because the current automation system does not suffice, might be converted into blueprints, making it easier to use them as a user. And maybe this makes developing & providing some custom integrations of today easier in the future.
I am sadly not able to help to implement my ideas here into Home-Assistant, at least now. But I want to share them to hear what you think about that and so you can implement that, if you share my idea. I would like to hear what you think.