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
