Adding another trigger/condition to an automation that is running from a blueprint?

Configuration Blueprints
1

I know it’s a new feature, but I couldn’t find information on something and thought I’d see if someone knows the answer rather than bugger about experimenting in the middle of the night.

For example let’s say I make a blueprint that handles motion events for 5 lights in the house, and it works great, but on only one of the lights I would like to add a second trigger - is this possible on the automation side?

So say my living room light and 3 others worked exactly as I wanted just off the blueprint, but I need my kitchen light to act differently, but ONLY in the respect of it having a second trigger, could I do this:

automation:
- alias: Living Room works just off blueprint
  description: ''
  use_blueprint:
    path: amazing_blueprint.yaml
    input:
      motion: sensor.motion_livingroom
      light:
        entity_id: light.livingroom

- alias: Kitchen is the only light of 5 that needs a second trigger
  description: ''
  trigger:
    - platform: state
      entity_id: sensor.motion_conservatory
  use_blueprint:
    path: amazing_blueprint.yaml
    input:
      motion: sensor.motion_kitchen
      light:
        entity_id: light.kitchen

(For clarity the above code would be in automations.yaml or equivalent)

So this way, both sensor.motion_kitchen and sensor.motion_conservatory would trigger the automation, but the conservatory sensor would not be tagged to !input motion in the blueprint.

Of course, if anything else in the blueprint relied on the state of !input motion I would get erroneous results, but if I was happy it wouldn’t cause any clashes - can this be done?

Or once use_blueprint: is in the automation will it ignore any extra triggers I provide?

Before anyone says: “You could just add the second motion sensor to the inputs…”, it might not always be a motion sensor, it might be an additional condition for one light or whatever, this example is just a proof of concept so I don’t have to get in to the much more complicated example that I actually have here if it’s basically never going to work because of how it’s designed.

Thoughts from devs or anyone who has experimented on this specific appreciated.

Thanks.

2

I just did a quick test using the included ‘motion light’ blueprint and my first impression leads me to believe the answer is no.

There appears to be no automation code generated by the blueprint that, in your case, you could customize one of the five instances to add a second trigger. All five are tightly bound to the blueprint automation.

I guess one way to look at it as that there’s only one automation that can be executed using five different sets of values.

But, I may be wrong. :wink:.

3

I think you misinterpreted what I was saying. In order to use the blueprint one has to generate an automation to feed it the !input entity_ids etc. You can create multiple automations with different !inputs for the same blueprint.

I’m saying in one/some of those automations can I add an extra trigger and what are the consequences of doing so.

The code in my post is from ‘automations.yaml’ if you like, edited with the automation: key at the top to clarify.

4

What I should have said is I think use_blueprint may override anything else you may add there (like the extra trigger ) … but I haven’t tested it. Does it pass Check Configuration and Reload Automations?

5

I don’t know, it’s 7am here so I’ve not been happy to mess around with ‘extra testing’ through the night with the family in bed. I’ve happily generated a few blueprints for some other situations and they work well, but I was hoping a dev might come along who would know the answer, espescially as even when the family is all off to school/work, the next bulk of automations that I could blueprint are quite complicated, and I’d rather know in advance whether I can add extra triggers/conditions to the automations that will be using the blueprint because it will affect how I approach building the blueprint in the first place.

If I have to experiment myself at some point I will, but was hoping someone who was either involved in coding it, involved in beta testing it, or whatever has already thought about this scenario and could give me a tip :slight_smile:

6

Good news! I was wrong! :man_facepalming: :slightly_smiling_face:

Just added a State Trigger to the blueprinted automation (an input_boolean to on) and it passed Check Configuration, Reload Automations didn’t complain and, best of all, the automation triggered when the input_boolean was turned on. Cool.

Just can’t test the original blueprint’s trigger (to confirm it’s still functional) because it’s too late here for that. I’ll let you know tomorrow morning (unless you try it first).

7

Ace :sunglasses:

That’s made things a bit simpler.

It threw me because you can add dynamic actions in the blueprint so people can add their own to the end, but trying to add triggers in this way doesn’t work, but if adding them to the automation manually works that’s fine by me. More refactoring to come at chateau mf_social throughout the day!

Cheers :slight_smile:

8

Doesn’t that defeat the purpose of using blueprints, tho?

Do you have that many automations that are completely identical except for the entities involved to warrant taking the time to convert them all to a blueprint? If they are no longer identical then now you just have a bunch of different automations that add the complexity of using a blueprint. Especially for ones that you already have written and working.

2 Likes
9

Not really, currently I have a number of very similar but not quite the same automations for lighting. I could condense them into one with a load of complicated templates and choose statements, but by the time that’s done it would be a bit of a mess and probably no more efficient.

Whereas now I can use the blueprint ‘backbone’, and just feed it the differences in timings etc for each light, significantly reducing the code.

The reason for this thread being that if I couldn’t modify the automations that call the blueprints with additional data, it still wouldn’t quite have been enough because I would have had to have an extra couple of automations to cover an edge case with a couple of them, but actually it looks like I can just add the edge case to the automation where appropriate.

I probably haven’t explained that very well, but give me a couple of weeks to get 100% happy with how they work and test/experiment with it and then I’ll share what I come up with and hopefully you’ll see where I’m going coming from, even if the resulting blueprint is no use to anyone but me :slightly_smiling_face:

10

No, I see what you are saying.

So far most of the blueprints I’ve seen in the examples just seem to be one-off automations that don’t really seem to benefit from being “blueprinted”. I get the suspicion that people are blueprinting things just to do it while possibly losing track of the supposed benefits of blueprints - minimizing code as you said.

I’ve seen a bunch of the blueprints that are longer and less readable than the automations that they are written to “make easier”.

I foresee a lot of “I imported this blueprint and now I can’t get it to work.” and then post a whole wall of text when asked to show the blueprint and the automation (or worse, show a bunch of UI screenshots… :roll_eyes:). Which we will then have to try to interpret and do the substitutions in our heads between the blueprint and the automations.

It doesn’t sound like a lot of fun to me.

3 Likes
11

I mentioned something similar within the first couple of days of the examples appearing.

I think it’s a really powerful tool, we’re just not necessarily going to see the power of it early on whilst people are getting used to it and experimenting.

That said, I did realise that I have a couple of ‘one off’ complicated automations that might be of use to people, and whilst they could just copy the automation and change the entity_ids etc, the blueprint would allow it to be as simple as just importing the blueprint, adding the entity_ids once and they’re away - so I think there are cases to be made for the one-offs too, but I think it’s more suited to much more complex ones than we’re currently seeing.

The only real ‘mistake’ I see with the current method of sharing is that there is no versioning - so if I write a blueprint you like and post it here, but then a week later I change it but you don’t like the change, you’ll be stuck with it. IMHO sharing them via hacs in the same way as python_scripts and appdaemon apps would be better, as you could pick the ‘release’ that suited you best.

It would also mean that if my blueprint had a bug, you could report it as an ‘issue’ on github, and someone else could drop a PR to fix it, and other such advantages.

Maybe (hopefully) that will come along in due course.

(oh, and before anyone says I’m attacking them because I used the word mistake, it’s in quotes for a reason, I’m just thinking out loud and no offence is meant)

2 Likes
12

Agree with you both. Some of the early examples of blueprints are tarnished by being based on poorly written automations and/or a shaky justification for blueprinting.

2 Likes
13

Yeah, I’m in a discussion right this moment trying to get someone who posted a blueprint that the code that are using is unnecessarily complex and doesn’t work the way they think that it does.

It works…but…

Here is the discussion if you want to follow along - Flash Lights when Alexa Timer has expired

And if I’m wrong please correct me there as well. But I don’t think that I am…

14

Jumping in to the philosofical discussion, from a newbee perspective…

I do believe that @finity is right in the short term perspective, that senior developers will be flooded by a wall of code, mainly becuse that one of the fundamental requirements are not presented to the community up-front: the intended purpose as documented in original proposal.

Wht is happening now is rather the oposite, everyone is rushing for the novelity, drummed up by the 2010.12 blog, the Youtube beginners guide by Zack and other seemingly easy-to-go examples.

So for the sake of HA, “we” need either (although possibly not XOR)

  • to beef up the documentation rather quickly and thus allow a greater majority create those “one-liners”/template blueprints they are happy with
  • a kind of service need to be established where blueprints can be requested (which for me would go against the intention of HA, being a tool for my needs wrt my IoT integrations, which always will be differnt from anyone elses)
  • speed up the deployment of Blueprints v2 and v3 as specified in the proposal

The current path will surely drain a lot of energy…