Solutions often consist of multiple parts to solve a problem. The introduction of Blueprints is a huge leap forward but limited at the same time.
Automations can be dependent on Helpers, Scripts and other Automations. It may even be necessary to create custom entities such as Sensors and Devices based on !inputs to utilise the platforms true capabilities.
I’m seeing the Blueprint as more of a class definition that can describe attributes and methods locally. Each use_blueprint: is creating an instance of that class and the elements within are unique/local to it.
This would make importing a Blueprint much more straightforward. Blueprint providers/developers would not have to issue multiple parts to their solution, nor describe how consumers would need to create/manage custom entities.
Adding Lovelace cards would allow the Blueprint to provide a default UI to work from that could be used by reference or duplicated into a View for modification.
Even if not shared, having a more complete/substantial Blueprint will allow for more efficient local reusability.
Pseudo Blueprint - don’t judge my YAML or it’s validity. It’s the concept I’m highlighting here.
blueprint:
name: Blueprint as a Solution
domain: automation
input:
motion_entity:
name: Motion Sensor
selector:
entity:
domain: binary_sensor
device_class: motion
helpers:
input_boolean:
name: helper_name
initial: on
icon: mdi:iconname
input_select:
name: helper_state
options:
- Option A
- Option B
- Option C
- Option D
initial: Option A
icon: mdi:iconname
sensors:
basedoninput:
friendly_name: 'Based On Input'
value_template: >
{{ something(using(the(!input motion_entity))) }}
icon_template: mdi:iconname
scripts:
- first_script:
alias: 'Turn Off'
sequence:
- condition: state
attribute: current
entity_id: !local helper_name
state: 'on'
- service: light.turn_off
entity_id: !input light_target
- second_script:
alias: 'Turn On'
sequence:
- condition: state
attribute: current
entity_id: !local helper_name
state: 'off'
- service: light.turn_on
entity_id: !input light_target
automations:
- first_automation:
trigger:
platform: state
entity_id: !input motion_entity
from: "off"
to: "on"
action:
- service: light.turn_on
target: !input light_target
- wait_for_trigger:
platform: state
entity_id: !input motion_entity
from: "on"
to: "off"
- delay: !input no_motion_wait
- service: light.turn_off
target: !input light_target
mode: single
- second_automation:
trigger:
platform: state
entity_id: !input motion_entity
from: "on"
to: "off"
action:
- service: light.turn_off
target: !input light_target
- wait_for_trigger:
platform: state
entity_id: !input motion_entity
from: "off"
to: "on"
- delay: !input no_motion_wait
- service: light.turn_on
target: !input light_target
mode: single
cards:
- type: grid
cards:
- type: button
tap_action:
action: call-service
service: !local script.first_script
entity: !input light_target
- type: button
tap_action:
action: call-service
service: !local script.second_script
entity: !input light_target
The one unspoken word in your description is “packages”.
A solution that relies on a combination of resources, such as various integrations, automations, scripts, etc, can be distributed as a package. However, the current distribution method is ‘copy-paste’ with manual customization (in YAML).
Your Feature Request is effectively asking for a ‘blueprint package’, namely a means to easily distribute and configure a package. That would be a significant enhancement because it would allow authors to easily distribute complete solutions (consisting of more than a single automation).
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.
