The current implementation of a blueprint automation stores the ‘reference’ automation within the blueprint. All automations instantiated by the blueprint (the ‘clones’) simply contain input data; internally they all refer back to the blueprint’s ‘reference’ automation. The same principle would apply to a ‘blueprint package’.
Anyway, if you look at balloob’s roadmap for blueprints, we are very far away from blueprint packages.
The big difference with using blueprints to deploy something that looks like packages is the ability for the user to customize the result at deploy time. Packages are a fixed quantity, it’d be great if we could mix the benefits of both solutions together to allow the user some control over exactly what’s happening when the solution is instantiated.
Exactly… Right now I’m just finalising my first blueprint. But I have to create three helpers for each use of it. Those helpers should be embedded in the Blueprint, the same if there were script dependencies.
I think it would also make sense to hide them from the main views as they will likely not work on their own and will break the automation if they were deleted by accident.
I developed the HASwitchPlate project around the use of packages and while they work great, they’re really hard for the end user to digest and obviously require the user to understand YAML. Any modifications require the user to dig deep into an increasingly hard-to-understand collection of automations to figure out where to make a change. Blueprints could radically simplify this approach with the ability to add multiple automations along with associated “helper” components.
Your request as outlined in the OP is spot-on for what I’m looking for and it would be a game changer for HASP users. Packages don’t solve the problem in a way your suggestion would.
To expand on that a bit - currently, when a user deploys a HASP with the deployment script they get a set of 140 automations created for them which, along with a bunch of helper entities, rolls out a fully-configured device. The base package, without examples, totals over 3200 lines of YAML across 13 files.
What would be far better for my users would be something like a base package which includes some core functionality that users don’t really need to customize. Then, allow the user to select from a list of blueprints that allow the user to define functionality on a per-screen or per-button basis.
So, for example, on page 1 there is a set of 4 buttons. Currently, there is a set of automations which put labels on those buttons at device connect or Home Assistant start, some which handle button state, some which push out font and color information, and one which picks up a specific button press and triggers a scene in response. Of those, the only thing the user really would care about is the label being applied and the scene being triggered when the user presses the button.
With a package-based approach to blueprints, I could hide all that other complexity in the blueprint YAML. The user would only have to select the button, enter the text, and decide which scene is being triggered as a result. If I have a repository of blueprints to choose from, I could make a bunch that perform various functions and the user could select them from a list.
So, page 1 top button selects a scene. Button 2 shows me the outside temperature. Button 3 locks the front door, etc. Blueprints are so close to offering me a way to give HASP users a menu-driven UI to customize their device.
The idea put forward in the OP would take it to that place.
My use case is to have a blueprint that has automations to send a notification with actions and handle all the callbacks for those actions.
One doesn’t make sense without the other so it would be great if I didn’t have to define two or three extra automations independently each time I used the blueprint.
The idea of including helpers is also interesting. I implemented my own thermostat for my IR-controllable heat pump with automations, temperature sensors, and a bunch of helper entities.
Then I had to duplicate the entire thing for my downstairs. The ability to blueprint it to avoid this duplication would be fantastic!
I’ll note an addendum to my post above - I was able to make the concept work using the existing blueprint system. Getting multiple automations bundled into a single blueprint was a matter of triggering on all of the combined ways one could trigger any of the set of automations I previously used, then utilizing choose to select the desired sequence of actions depending on the trigger.
Helpers are more difficult. In my case I can rely on MQTT being available, so I make use of publishing persistent MQTT discovery messages and then leveraging the created entity as a helper. It’s not a great solution but it can work.
Still, having the ability to define helper objects in the blueprint would be a huge benefit.
I thought about exactly this solution, but stopped short of actually implementing it. It seems like more of a hack to me and could lead to fairly unmaintanable automations.
Ultimately I would luv what the original poster proposed.
I have a much simpler use case.
I must instantiate a Blueprint and a Timer for each instance of the Blueprint, and then using the input select the timer.
In this case the timer is really just a helper instance entity used only as part of the blueprint instance.
I am new to Home Assistant … is there a way to dynamically create entities like a timer ?
In thinking about blueprints I want to build I quickly came to realize that this is a necessary feature for maintainable and easy to use blueprints. I hope we see something like this soon!
and here I am 5 days later, frustrated that I can’t make anything more than trivial automations using blueprints due to the limitations. The concept of blueprints is great but the current version is just too limited to do much beyond simple things.
If I’m understanding this correctly, the Lovelace part would fit my current needs nicely. I have a layout card with a button on the left and a schedule on the right, so the wife can change schedules for her lights from the mobile app. I have gone through a few iterations and every time I get a new layout that I like, I have to copy it several times. It would be nice to define the YAML once and place it on my dashboard several times, only selecting the entity for each instance.
It turns out the “decluttering-card” available in HACS does exactly what I wanted. Yea! Custom cards for the win.
That said, I do still see the benefit in what was described in this thread. In a previous iteration, I created a blueprint (well, I modified someone else’s blueprint) to create schedules for multiple devices, but I had to separately create datetime helpers and boolean helpers for each instance of the blueprint. It would have been great if they all could have been defined in one place, including the card to show them in Lovelace.
@SteveDinn not sure if you are a software engineer, but the concept I am proposing is based on object oriented principles. Localising helpers could see them completely hidden (private) or exposed to allow the user of the blueprint to change them based on the helper type.
Each instance of the blueprint would hold its own copy of those helpers and therefore how they are set in one, would not impact how they are set in another.
