I really like the newly added ‘Blueprint’ feature. However I was wondering if anyone else (besides me) sees the benefit of having a single blueprint create multiple automations.
I’m on mobile right now so I will have to add my specific automation use-case later, but to clarify my suggestion a bit:
I have 4 automations for each area where I control light via motion sensors. I use a ‘start’, ‘cancel’, ‘restart’ and ‘finish’ automation. Basically when a user manually operates a light in the area the ‘start’ and ‘restart’ automations get disabled. The ‘start’ automation starts a timer and the ‘finish’ automation triggers when the timer expires. These automations basically enable a smarter scenario than just the basic ‘when motion, light on’ of which there is already a default blueprint.
I would really like to be able to create a blueprint (to share with the community) for these automations, but it would only make sense to me if a single blueprint was able to create the 4 automations needed.
I realise that this is currently not possible, but I’m hoping that this will be added to the new blueprint feature.
Would anyone else see the benefit of creating multiple (>1) automations using a single blueprint?
Edit: I noticed some community members question the benefit of having blueprints next to automations. I feel that the ability to generate multiple automations from a single blueprint would really make blueprints an even more ‘standout’ feature than it already is.
It is my understanding that the only purpose of a blueprint is that it allows you to re-use code in an automation by just editing the automation details to select the entities as used in the blueprint.
The blueprint doesn’t, in and of itself, “generate” an automation. You create the automation using the blueprint as the base.
@anon43302295 Blueprints (as far as I understand) create a single automation; I’m inquiring about the possibility of having a blueprint create several automations using a single blueprint.
@QNimbus I have been wondering the same. I have two seperated automations for turning heating on and of. I’d like to include both of them in one blueprint. I think this is what you ment.
In addition I’d like to create some input_booleans and input_numbers for the frontend in the same blueprint, but that’s a diferent story.
You should create a blueprint that does both functions, either with templates or chooses, and either specify what helpers are required in the instructions or offer a pre-built, reproducible package containing what you need for your blueprint to work correctly.
I think OPs problem is that he wants a blueprint that creates multiple automations instead of just one, where one of the automations disables/enables the other automation on user interaction. @OP can you exactly describe/post your current automations, I assume there’s a way to combine these into one with the help of some input booleans and then you wouldn’t need a blueprint that creates multiple automations.
@anon43302295 I have read the documentation for blueprints (obviously) and the only current domain supported for blueprints is/are automations. A blueprint has a one-to-one relationship with the domain (in this case an automation). What I’m asking is whether the community sees a benefit in having a single blueprint (for the automation domain) resulting in multiple automations instead of just the one.
If you think I misunderstood the purpose of blueprints in general, please enlighten me as I’m keen to learn.
See my post above. What you’re asking for doesn’t make sense.
You’re either asking for someone who fills in a blueprint to generate several automations that are geared towards the same thing, which should just be one automation.
Or you’re asking for someone who fills in a blueprint to generate multiple automations that aren’t linked, and if they’re not linked they should be separate blueprints.
@anon43302295 I agree with you that I could create separate blueprints for the 4 specific automations that I’m referring to, bit since they are tightly coupled (and co-dependant) it would make more sense (to me) to have a single blueprint produce the 4 automations. I will try to post the automations I’m referring to tomorrow to maybe further clarify what I intend to accomplish.
If I understand the OP correctly, imaging these automations:
- alias: "turn the fan on when hot"
trigger:
- platform: numeric_state
entity_id: sensor.temperature
above: 70
action:
- service: switch.turn_on
entity_id: switch.fan
- alias: "turn the fan off when cool"
trigger:
- platform: numeric_state
entity_id: sensor.temperature
below: 68
action:
- service: switch.turn_off
entity_id: switch.fan
Yes, these CAN be combined into a single automation and therefore, work well with blueprints. Additionally, two blueprints could be created and a user wanting the fan both turned on AND turned off (as most would) would just have to make two automations, one from each blueprint. However, having a SINGLE blueprint to do the work of both automations is much easier for the end user and rarely would one be used without the other.
While this simple case is fairly easy to blend together using “choose” statements, a more complicated automation gets VERY complex when choose statements have to do all the work. If you go into discord and ask “hey, should I combine these two automations into one” the general answer is “no. It’s easier to write and troubleshoot two automations.”. Yet, to use a single blueprint, we’d need a single automation.
Allowing the creation of multiple automations from a single blueprint would be ideal.
But that’s why we make a blueprint for it. So that someone who wants to do it, can use the blueprint instead of making a complicated one themselves (or make multiple automations themselves).
Pretty much spot on @swiftlyfalling, my 4 automations are indeed too complex to cram into a single automation even though they ‘logically’ should be combined since they all serve the same purpose (switching on a light after motion is detected with some additional logic)
Maybe I just misunderstood the purpose of blueprints and they should only ever be used to create a single domain entity (in this case an automation). I just figured that a single blueprint for my 4 automations would make it easier to maintain and to share with the community.
It will be when you’ve combined them into one automation. It may be complex, but it doesn’t matter because the end user of the blueprint will not have to tinker with it, they will just input their entity_ids (etc) and benefit from your work.
I too currently have things done with 3 or more automations for the purpose of ‘maintenance’ due to the complexity of combining them, but now (when I get the time!) I’ll be combining them into one and creating a blueprint, because I will not have to ‘maintain’ the complexity of the automation, I will just be able to generate the automations that work from the blueprint by feeding it the appropriate inputs.
This is one of the automation scenario’s I use in my home to automatically switch on the hallway light after motion is detected. Each of these contain 4 separate automations. I hope the comments in the code snipper are sufficient to explain the working of the automations. My Home Assistant config is also on GitHub (including the other automations)
---
# Automation. See: https://www.home-assistant.io/integrations/automation/yaml/
# Trigger. See: https://www.home-assistant.io/docs/automation/trigger/
# Conditions. See: https://www.home-assistant.io/docs/automation/condition/
# Actions. See: https://www.home-assistant.io/docs/automation/action/
# Related entities:
#
# - light.ff_hallway_dimmer_1_dimmer : Light
# - binary_sensor.ff_hallway_sensor_1_contact : Motion sensor
# - timer.evening_light_firstfloor_hallway_timer : Timer
# - input_datetime.evening_light_firstfloor_hallway_timer_setting : Timer setting
# - input_datetime.evening_light_cancel_timer_setting : Cancel timer setting
# - input_number.evening_light_firstfloor_hallway : Light setting
# - automation.aav_overloop_1e_verdieping_start
# - automation.aav_overloop_1e_verdieping_restart
# - automation.aav_overloop_1e_verdieping_cancel
# - automation.aav_overloop_1e_verdieping_finish
# Automation description:
#
# When motion is detected [start]:
# - Light is switched on to target value
# - Timer is started and runs for preset duration
# - Wait for 1 second (to prevent instant trigger of [restart] and/or [cancel])
# - Arm [restart] and [cancel] automations
# When motion is detected continiously until timer expires [restart]:
# - Restart timer
# When motion is detected during period when timer is active [restart]:
# - Restart timer
# When light is manually switched off or to another value when timer is active [cancel]:
# - Cancel timer
# - Disarm [start] and [restart]] automations
# - Wait for preset cancel duration. (e.g. 60 seconds)
# - Arm [start] and disarm [cancel] automations
# When timer expires and no motion is detected [finish]:
# - Light is switched off
# - Disarm [restart] and [cancel] automations
- alias: AAV Overloop 1e verdieping [start]
trigger:
- platform: state
entity_id: binary_sensor.ff_hallway_sensor_1_contact
from: 'off'
to: 'on'
condition:
condition: and
conditions:
- condition: state
entity_id: timer.evening_light_firstfloor_hallway_timer
state:
- 'idle'
- condition: state
entity_id: light.ff_hallway_dimmer_1_dimmer
state:
- 'off'
action:
- service: light.turn_on
data:
entity_id: light.ff_hallway_dimmer_1_dimmer
brightness_pct: >
{{
states('input_number.evening_light_firstfloor_hallway')
}}
- service: timer.start
data:
entity_id: timer.evening_light_firstfloor_hallway_timer
duration: >
{{
states('input_datetime.evening_light_firstfloor_hallway_timer_setting')
}}
- delay:
seconds: 1
- service: automation.turn_on
data:
entity_id: automation.aav_overloop_1e_verdieping_restart
- service: automation.turn_on
data:
entity_id: automation.aav_overloop_1e_verdieping_cancel
- alias: AAV Overloop 1e verdieping [restart]
initial_state: false
trigger:
- platform: state
entity_id: binary_sensor.ff_hallway_sensor_1_contact
from: 'off'
to: 'on'
- platform: event
event_type: timer.finished
event_data:
entity_id: timer.evening_light_firstfloor_hallway_timer
condition:
condition: or
conditions:
- condition: state
entity_id: timer.evening_light_firstfloor_hallway_timer
state:
- 'active'
- condition: state
entity_id: binary_sensor.ff_hallway_sensor_1_contact
state:
- 'on'
action:
- service: timer.start
data:
entity_id: timer.evening_light_firstfloor_hallway_timer
duration: >
{{
states('input_datetime.evening_light_firstfloor_hallway_timer_setting')
}}
- alias: AAV Overloop 1e verdieping [cancel]
initial_state: false
trigger:
- platform: event
event_type: state_changed
event_data:
entity_id: light.ff_hallway_dimmer_1_dimmer
condition:
condition: state
entity_id: timer.evening_light_firstfloor_hallway_timer
state:
- 'active'
action:
- service: timer.cancel
data:
entity_id: timer.evening_light_firstfloor_hallway_timer
- service: automation.turn_off
data:
entity_id: automation.aav_overloop_1e_verdieping_start
- service: automation.turn_off
data:
entity_id: automation.aav_overloop_1e_verdieping_restart
- delay: "{{ states('input_datetime.evening_light_cancel_timer_setting') }}"
- service: automation.turn_on
data:
entity_id: automation.aav_overloop_1e_verdieping_start
- service: automation.turn_off
data:
entity_id: automation.aav_overloop_1e_verdieping_cancel
- alias: AAV Overloop 1e verdieping [finish]
trigger:
- platform: event
event_type: timer.finished
event_data:
entity_id: timer.evening_light_firstfloor_hallway_timer
condition:
- condition: state
entity_id: binary_sensor.ff_hallway_sensor_1_contact
state:
- 'off'
action:
- service: light.turn_off
data:
entity_id: light.ff_hallway_dimmer_1_dimmer
- service: automation.turn_off
data:
entity_id: automation.aav_overloop_1e_verdieping_restart
- service: automation.turn_off
data:
entity_id: automation.aav_overloop_1e_verdieping_cancel
@anon43302295 I will give your suggestion a shot and try to see if I can in fact cram all that logic into a larger (single) automation. I’m not sure if there will be a performance penalty for this, but I guess I will have to find out.
But I hope that you understand why I was asking about the possibility of have a single blueprint for multiple automations - that would at least make the process of making the blueprint a lot simpler.
