Blueprints are awesome but often need tons of helpers set up. Just like devices are a grouping of entities, we need applications which are groupings of helpers and automations.
Packages combine various entity domains.
Or do you want a blueprint to be able to produce a package?
There are already feature requests along these lines…
1 Like
I agree it has the same goal. But my point is we need a “type” to assign all this common stuff together with. Entities without device made organization and reasoning about stuff difficult. I think adding an “Application” will clean up the automation/helpers experience just like devices did for entities.
yes, packages were a way to do what I’m talking about that is the older yaml / no gui way. Application would be an item in a registry that is editable via the gui. Automations/helper could be grouped together in the gui via an application you can create.
No reason to stop there…
we could set up “applications” to include automations, scripts, helpers of all kinds, sensors, binary sensors, timers, counters…all kinds of things (everything even) could go in those “applications”.
And the UI could be used to create everything in those “applications”.
I have some “applications” right now that contain 1000’s of lines of code in yaml that could easily be converted to UI inputs.
That won’t get very confusing/tedious at all to need to scroll through possibly hundreds of lines of UI to find the thing you want to change.
oh, wait… 
But all joking aside, that’s exactly what packages are for.
it makes no sense to just include automations and helpers when a true “application” (aka “package”) could contain pretty much any type of entity.
And trying to keep all of those things organized thru the UI would be a nightmare.
automations that are edited thru the UI are already hard enough to keep track of (see the number of requests in the FR’s for the ability to better organize them somehow). Could you imagine trying to keep track of those 1000’s of lines of yaml equivalent code in the UI?
1 Like