I will say this again as I’ve said in other threads that this has been discussed…
I think you are completely missing the point of what a blueprint does.
A blueprint gives you a reusable framework so that you can create an automation based on that framework by substituting the desired entities for the variables (or “placeholders”) created in the blueprint.
the example that you gave makes no sense in that respect.
Both of those automations are exactly the same except for the placeholders.
THe way this is supposed to work is that you create the blueprint (from your example):
blueprint:
name: Example
description: Example
domain: automation
input:
motion:
name: Motion Sensor
selector:
entity:
domain: binary_sensor
device_class: motion
automation:
trigger:
platform: state
entity_id: !input motion
from: "off"
to: "on"
action:
- service: tts.google_say
data:
entity_id: media_player.home_mini
message: 'Motion 1 detected'
mode: single
max_exceeded: silent
then YOU create two automations from the same blueprint (example taken from the docs):
automation example 1:
use_blueprint:
path: example.yaml
input:
motion: binary_sensor.kitchen
automation example 2:
use_blueprint:
path: example.yaml
input:
motion: binary_sensor.den
I am assuming this is the syntax for creating multiple automations from the same blueprint since the docs for actually using blueprints thru yaml are woefully lacking. But at least it gives you the idea.
THere is no reason to combine the two automations in your example into one blueprint since the two automations (or 100, or 1000 other identical automations to the two I posted) can be created from the same blueprint base code just by changing the “motion” placeholder.
Cannot like the post above this one enough. Really worries me about the state of some people’s configuration that this even needs to be explained once, let alone the several times this week in various guises.
I have just posted an alternative view of this. I agree this is a poor example, but there is a need.
Compex Automations rarely operate on their own. Ther are usually other supporting entities: Helpers, Scripts and other Automations. A Blueprint needs to consider the entirety of what is being acheived.
I do think having multiple automations could have an added value. Example sun up/down as light trigger. Having it in one automation makes it more complex and for other examples could be much more difficult.
blueprint:
name: wake light off sunup
description: Light off when sun down
domain: automation
input:
light_entity:
name: Light
selector:
entity:
domain: light
automations:
- trigger:
platform: state
entity_id: sun.sun
from: 'below_horizon'
to: 'above_horizon'
variables:
light_entity: !input light_entity
action:
service: light.turn_off
data:
entity_id: light_entity
- trigger:
platform: state
entity_id: sun.sun
from: 'above_horizon'
to: 'below_horizon'
variables:
light_entity: !input light_entity
action:
service: light.turn_on
data:
entity_id: light_entity
i currently use a package for it but it has more functionality currently no sure how to implement it via blueprints. (the light only turns off when it was turned on by the sundown event.)
As we can do everything using templates in trigger/conditions/service section why keeping the other other platforms. For my current try’s with blueprints i’m using the choose option.
This automation i’m currently using, it has more lines of code , and needs to execute more stuff during up/down events = my interpretation is more complex
But maybe it can be shorter ?
blueprint:
name: wake light
description: Set light when sun down/sun up
domain: automation
input:
light_entity:
name: light
selector:
entity:
domain: light
trigger:
- platform: state
entity_id: sun.sun
from: 'above_horizon'
to: 'below_horizon'
- platform: state
entity_id: sun.sun
from: 'below_horizon'
to: 'above_horizon'
variables:
light_entity: !input light_entity
action:
- choose:
- conditions:
- condition: state
entity_id: sun.sun
state: 'above_horizon'
sequence:
- service: light.turn_off
data:
entity_id: light_entity
- conditions:
- condition: state
entity_id: sun.sun
state: 'below_horizon'
sequence:
- service: light.turn_on
data:
entity_id: light_entity
Sure, but it’s getting a bit ridiculous having to keep ‘fixing’ these just to illustrate a point…
blueprint:
name: wake light off sunup
description: Light off when sun down
domain: automation
input:
light_entity:
name: Light
selector:
entity:
domain: light
trigger:
platform: state
entity_id: sun.sun
action:
service: "light.turn_{{ 'on' if trigger.to_state.state 'below_horizon' else 'off' }}"
entity_id: !input light_entity
Where to start?
yours uses variables, but there is absolutely no reason and therefore is added complication with zero benefit
yours is 39 lines of code, mine is 16.
Aside from the obvious efficiency savings, there are fewer moving parts, therefore fewer things to go wrong
In the unlikely event that there is a mistake, 16 lines is far easier to go through than 39.
mine is neater, and therefore far easier to discern what it does.
splitting this into two serves no purpose other than creating more code and more room for error.
Many blueprint automations that I have seen share the same deficiency: bloat. They contain so many unnecessary lines of code it’s like they were being paid by the line.
