You definitely can. Although I think chucking templates in tends to make it easier.
Again, you definitely could, but it would ruin my OCD. That said it equally ruins my OCD to use several automations for one function.
To me, an automation should cater for a situation. The only reason I have 3 instead of one (in the examples I was talking about above) is for maintenance purposes, and I only do that in very specific circumstances. Even then, as soon as blueprints were announced I knew they were getting merged
By design blueprints end up being more complex for the person writing them than the equivalent automation would be.
I agree that it makes it easier for the end user to implement the blueprint in the automation (even if that end user will be the author using it for different entities/details).
Have you seen the large amount of code that goes into a blueprint to define the metadata that the blueprint exposes to an automation? And then after the blueprint is properly commented and described to make it understandable to the end user (who didn’t write it) it’s ridiculously huge.
I honestly couldn’t imagine trying to combine all of those automations that you have now into one automation then try to translate that into a single blueprint. Even if the blueprint had the ability to have multiple different trigger/condition/action sections to incorporate many different automations into one huge blueprint (I think I realized that is what you are asking) the resulting blueprint would be unreadable and almost impossible to maintain.
You still have to dexscribe every single entity, trigger, condition, action, setting, option etc just like you do in an automation in the blueprint. And the add more to it. I can’t see how it makes it more simple.
That’s the reason why the response on discord is to use more than one automation - “It’s easier to write and troubleshoot two automations.” It would be exactly the same (only more so) for blueprints just due to their nature.
In the two years I have been helping people fix their automations, this early batch of blueprints is revealing some of the most eyebrow-raising examples I’ve ever seen.
I’ve stated elsewhere that blueprints are proving to be the fastest way to distribute an unoptimized automation.
Now I see a request to allow a single blueprint to deliver multiple unoptimized automations.
Perhaps the focus should be on refinement prior to distribution.
Hi there! I’m experimenting with blueprints for the first time, and also have encountered this desire – I’d love to have multiple automations generated by a single blueprint. I’m sure @anon43302295 will tell me I’m wrong to want this, but let me describe my needs so I can get shot down.
I have 13 rooms in my home with motion sensors. I want their lights to turn on dimly if motion is sensed at night, and be able to turn the lights on and off with the wall switches at any time.
I’m using the Vantage Infusion custom component, and fully realize my code is useless to anyone else. So I have no intention of sharing my blueprint, or “optimizing my code” for sharing. My #1 goal is ease of maintenance.
Right now I’ve generated a template for my motion sensor automation, and have made 13 copies of that template and specialized each one by hand for each room. Each room has 5 automations in a single file.
Which means if I want to change it, I have to make the change 13 times. Annoying!
I’ve been tempted to use GNU m4 or the like, but have not gone that far yet.
I figured blueprints should be perfect! But they don’t seem to support my template with multiple automations per room. And if I create 5 blueprints per room, the code is almost as awkward as what I already have.
Given the comments above about optimizing blueprints and combining automations into single mega-automations, I’m guessing my use case (“make code maintenance for my own code easier”) is not the goal use case for blueprints. Instead, the goal is to make it easy to share easy-to-use blueprints with others, at the cost of making blueprint creation somewhat more complex. Is this correct?
If it is helpful, here is my template which I specialize for each room:
- alias: '%NAME% lights button or off button pressed'
trigger:
- platform: event
event_data:
button: %BUTTON1%
event_type: vantage_button_pressed
- platform: event
event_data:
button: %BUTTON2%
event_type: vantage_button_pressed
- platform: event
event_data:
button: %BUTTON3%
event_type: vantage_button_pressed
action:
# Suppress motion sensing for 10 seconds so the lights don't immediately
# turn on just after I turn them off.
- service: timer.start
data:
entity_id: timer.%LNAME%_nightlights_suppress_motion
duration: '00:00:10'
- alias: '%NAME% motion sensor triggered, lights currently off'
trigger:
- platform: state
entity_id: sensor.%MOTION%_motion
to: Violated
condition:
- condition: state
entity_id: sensor.%BSTATE%_lights_button_state
state: '1.0' # Off
# Only trigger at night:
- condition: template
value_template: '{{ state_attr("sun.sun", "elevation") < -2 }}'
- condition: state
entity_id: timer.%LNAME%_nightlights_suppress_motion
state: idle
action:
# Potential race condition: what if the lights are turned on just as this
# motion event arrives (a.k.a. the two automations are run in parallel)?
# Unlikely to happen, but possible.
# Turn the lights on dimly:
- service: light.turn_on
data:
entity_id: light.%DIMLIGHTS%
transition: 1
brightness_pct: %PCT%
# Set button to blue:
- service: vantage.set_variable_vid
data:
vid: %VID% # A.k.a. sensor.%BSTATE%_lights_button_state
value: 3 # Dimly lit
- alias: '%NAME% motion sensor no longer triggered'
trigger:
# Trigger once we've been in dim mode for 2 minutes, at least 2 minutes
# after the last motion event.
- platform: state
entity_id: sensor.%MOTION%_motion
to: Normal
for: "00:02:00"
- platform: state
entity_id: sensor.%BSTATE%_lights_button_state
to: '3.0' # Dimly lit
for: "00:02:00"
condition:
- condition: state
entity_id: sensor.%MOTION%_motion
state: Normal
for: "00:02:00"
- condition: state
entity_id: sensor.%BSTATE%_lights_button_state
state: '3.0' # Dimly lit
for: "00:02:00"
action:
# Another potential (but unlikely) race conditon: what if this condition
# becomes true just as someone turns on the lights?
# Turn off the lights
- service: light.turn_off
data:
entity_id: light.%DIMLIGHTS%
transition: 1
# Set button to green:
- service: vantage.set_variable_vid
data:
vid: %VID% # A.k.a. sensor.%BSTATE%_lights_button_state
value: 1 # Off
- alias: '%NAME% empty, turn off lights'
trigger:
# Trigger once we haven't had motion for a long time:
- platform: state
entity_id: sensor.%MOTION%_motion
to: Normal
for: "00:15:00"
action:
# Turn off the lights
- service: light.turn_off
data:
entity_id: light.%ROOM%
transition: 1
# Set button to green:
- service: vantage.set_variable_vid
data:
vid: %VID% # A.k.a. sensor.%BSTATE%_lights_button_state
value: 1 # Off
# If someone turns off the lights manually (such as with the Home Assistant
# UI), update the button state to match:
- alias: '%NAME% light turned off manually'
trigger:
# Trigger once we haven't had motion for a long time:
- platform: state
entity_id: light.%ROOM%
to: 'off'
action:
# Set button to green:
- service: vantage.set_variable_vid
data:
vid: %VID% # A.k.a. sensor.%BSTATE%_lights_button_state
value: 1 # Off
Then you’re not looking at blueprints, and you can make as many automations to facilitate your needs as you desire.
Also, as blueprints only create automations and not timers, and several of your automation’s require timers, you’d be out of luck to blueprint them in the current state without additional work by the recipient.
However to transpose your idea in to blueprints, you don’t need a blueprint to make 5 automations, you can just make 5 blueprints. Or you can slim down your existing 5 automations into 4, 3, 2 or 1 automation(s) - ideally replacing the timer entities with better methods as you go so that whatever number you end up with are reproducible without additional configurations - and make that number of blueprints.
But nevertheless, the point is that from the very outset you don’t require blueprints. You currently have 5 automations per room, and if you blueprinted it in its current form, you would still need 5 automations per room, it’s just that they will be generated by the blueprint instead of copy and paste. If it’s not a shareable concept, then transforming them in to a blueprint is pointless.
Reducing them from 5 to any number lower than 5 will vastly improve your coding though, and you should aim for 1, for personal code-ninja glory if nothing else.
Edit - just as a simple optimisation to get you started, adding the trigger of automation 5 to automation 4, negates the need for the 5th automation before you’ve even started. And the action for automation 3 and 4 are exactly the same, so they’re clearly mergeable - so in less than 10 minutes, in spite of it being way past my bedtime, half of the work to reduce this to 1 automation is already done
Thanks for confirming – it sounds like blueprints were not designed for my use case (of reducing redundant code).
I have to admit, in my career as a software engineer, I’ve never aimed for “personal code-ninja glory”. I aim for the opposite – easy to understand, easy to maintain, simple code. Of course, I don’t always achieve that.
I would disagree that having those 5 automations are ‘easy to maintain’ and ‘simple’, given that 3 of the 5 are basically repetition. 3 times the code == 3 times the chances of a mistake creeping in.
Would also love this functionality of multiple automations in 1 blueprint. Sure, I can cram everything in 1 automation, but the purpose of my automations are readability, which is not the same as writing things optimally …
I’ve read through the comments here and I’d like to chime in -
I’ve got blueprints that consist of multiple parts that, while working towards a common goal, aren’t easily combined using choose.
For example: I have remotes that I want to script to do certain things on keypresses. In my case, cycle through a set of input_selects, etc depending on which button is pressed. That is easily abstracted into a single action with conditions. That already reduces complexity in the configuration massively, so a win!
But then there’s the backend and support functions: actions that trigger when a certain state has been set, timers, etc.
I could combine that into a single massive choose statement, but that’d be painful. I’d also imagine it’d not be very efficient, since the trigger would kick in for a lot of things that could be skipped?
The argument that this doesn’t matter because you’d only have to do the maintenance one when writing a blueprint doesn’t check out - someone has to maintain the blueprint, support it, make changes to it, or even just try to understand it. Readability always matters.
Blueprints containing multiple trigger/action combinations (in short, multiple automations) off the same metadata/inputs would make them significantly more powerful, easier to write and maintain.
I’m honestly confused by the massive resistance here to this concept, and am guessing I must be missing something?
Sorry I’m resurrecting an old post, but hear me out.
We NEED to have multiple separate automations under a single blueprint. I have a very basic case that requires two automations, since one of them should run on “restart” and the other one on “single”.
The automation triggers on a switch double-click, then runs a bathroom fan for X minutes.
The issue is that if it’s a single automation with “restart” - any new clicks just delete the running timer.
If it’s single - then you won’t be able to re-trigger it unless the timer ends.
If it’s parallel - you got a bunch of parallel timers that might expire one over another and then you go into condition hell to ensure everything works properly.
If those are two separate automations - everything works perfectly - the single/double/long press automation can run separately from the timer one, which should be in “restart” mode.
And now here is the thing. Having two automations for a single switch is fine, but I have to create two of them for each light. Even with blueprints, I have to apply two blueprints for every light that I want to control this way - one for the switch, one for the action itself.
NodeRED does exactly this. You have a single “file” with multiple start points, which at the end results in a “single” automation that is actually a couple of different ones. Now think of this as having that flexibility of NodeRED in a single blueprint.
Another case is literally creating an “app” for a group of devices. If you have multiple aquariums/animal enclosures/grow boxes or whatever, you can just create a SINGLE blueprint that has 5, 10, 15 automations and you can reuse that on every other container that you want to include.
Just think of how many things you can have in a box - multiple lights, multiple fans, multiple motors/pumps, a ton of sensors. I understand this is a very specific case, but I would love to be able to build identical vegetable grow boxes with the same electronics inside and to be able to controll all of them with a single blueprint. Just pull up the blueprint - point to the lights, fans, sensors and there you go - a full automated app for controlling a single type of plant. If you have a different plant - a different blueprint with rules specific for that.
Choose is great but when you have automations, the trigger can be something like:
- platform: state
entity_id:
- timer.laundry_room_timer
from: idle
to: active
But how do I make a chose condition for a state transition? If we had “from: to:” in the condition than I wouldn’t need multiple automations and can drink the koolaid.
Okay so forcing myself to use a single automation made this better… now I have less automations to scroll through. I am a convert and do not think I need multiple automations… and the whole reason I was looking to blueprints was to find a way to make it easier to create the 4 automations per light that I wanted on a timer…
I wanted to be able to see on my dshboard the remaining time on the timer, pause and reset it or just change the default off timer by adjusting the timer card
alias: "Sunsaver: laundry room (complete)"
description: ""
trigger:
- platform: state
entity_id:
- light.tasmota_ba4108
to: "on"
from: "off"
id: "0"
- platform: state
entity_id:
- timer.laundry_room_timer
from: idle
to: active
id: "1"
- platform: state
entity_id:
- light.tasmota_ba4108
to: "off"
id: "2"
- platform: state
entity_id:
- timer.laundry_room_timer
from: active
to: idle
id: "3"
action:
- choose:
- conditions:
- condition: and
conditions:
- condition: state
entity_id: switch.sun_saver
state: "on"
- condition: state
entity_id: timer.laundry_room_timer
state: idle
- condition: state
entity_id: light.tasmota_ba4108
state: "on"
- condition: trigger
id: "0"
sequence:
- service: timer.start
data: {}
target:
entity_id: timer.laundry_room_timer
- conditions:
- condition: and
conditions:
- condition: state
entity_id: light.tasmota_ba4108
state: "off"
- condition: trigger
id: "1"
sequence:
- service: light.turn_on
data: {}
target:
entity_id: light.tasmota_ba4108
- conditions:
- condition: and
conditions:
- condition: state
entity_id: light.tasmota_ba4108
state: "off"
- condition: trigger
id: "2"
sequence:
- service: timer.cancel
data: {}
target:
entity_id: timer.laundry_room_timer
- conditions:
- condition: and
conditions:
- condition: state
entity_id: switch.sun_saver
state: "on"
- condition: trigger
id: "3"
sequence:
- service: light.turn_off
data: {}
target:
entity_id: light.tasmota_ba4108
mode: restart
I’m not convinced. Now you have one automation that’s huge and you have to scroll through it a lot. IMHO multiple automations would be easier to reason about in many scenarios because it separates the concerns. It encapsulates different related parts of a system into modules.
I’m late to the party here but I’m on the side of people that would like a single blueprint to be able to
I have developed a custom component called dynamic (Dynamic Yaml configuration).
I use it to create timers, input_text, … that are needed for the blueprint.
It registers these in the automation startup.
I have attached my Dynamic custom component and my blueprint that use this for you to look at. config.tar
I haven’t seen it mentioned, however one thing I see a problem (or just a bunch of extra conditions you need to put in) is that with combining multiple “automations” into a single one, means you loose the ability to have different automation modes per each (i.e single, parallel, queue, reset).
And even with conditions I am not sure a queue mode can even be implemented. (I mean a single branch of the choose mode in a combined automation, to behave the same way as that would be a separate automation in queue mode)
Very complex automation that needs to be replicated per area.
Combining into a single automation to create a blueprint out of it is indeed possible with some work but it would really make the automation unreadable less maintainable. Loosing one of the benefits of BP
I too agree with the suggestions to decouple blueprints and automations and to enhanced blueprints to allow them to create/update a collection of automations to allow breaking down automation problems into simpler solutions.
As explained by many above, merging multiple automations (which are just a sequence of actions run by specific triggers) into one increases dramatically the overall complexity as 1) you have to add specific actions to determine which triggers have been triggered since they’re all triggering the same set of sequences and 2) the running mode of the automation (single/restart/parallel) has to be identical for all runs.
My use case is also to reproduce a collection of automations in multiple areas of my house. I can duplicate everything but this is harder to maintain.
What I don’t understand about this entire thread is how badly many understood/understands Blueprints…
There are Script blueprints that work almost exactly like scripts. The exception is you can save copies of the calling script with stored variables, and reuse the logic. Otherwise it does everything scripts do including the use of fields.
There are Automation blueprints, same thing. They work almost exactly like automations. The exception is you can save copies of the calling automation with stored variables.
So both can do multiples.
Trigger ID’s that were added later than most of this thread along with choose statements make the multi-step in automations possible, so that is way easy now as well.
And guess what. The automations created from Blueprints can absolutely be put into packages. The blueprint itself has to live in the same folder location, but the Automation or Script does not that is created from the Blueprint. It is just an Automation or Script. To share a blueprint with a package, instruct the user to download your package and install the blueprint in the regular way.
There are generally 2 reasons to make a blueprint.
Because you want to do the same thing multiple times, like my script blueprint to talk to my Broadlink and program buttons to turn on and off my AV equipment. I have re-used that script blueprint about a dozen times in my config.
You are doing something you think is cool and you want to share it with others.
If you are doing something only once, the blueprint only complicates things for you.
I write this now so that future us isn’t confused by Blueprints. Please don’t read 4YO Posts and think it always applies today.
