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 …
3 Likes
Hi all,
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?
8 Likes
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.
2 Likes
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.
If we could reference which trigger in a condition, that could do it…
oh… Conditions - Home Assistant
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
https://raw.githubusercontent.com/jaymemaurice/homeassistant-blueprints/main/light_timer.yaml
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
- generate multiple automations
- generate helpers (like timers)
1 Like
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)
1 Like
Old Topic. Same Problem/Scenario.
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 find the limitation dumb
1 Like
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.
Why not one step higher and have blueprintable packages? 
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.
1 Like