Using multiple trigger inputs in blueprint

Configuration Blueprints
1

I’ve been trying to figure out if it’s possible to use multiple trigger inputs in a blueprint. Below is working code for a single trigger. I cannot find a way to use the second trigger since reading a trigger input puts the trigger dict it into a list. I have tried using templates to extract the dict and make a list with both triggers but I haven’t been able to get it to work - I believe due to the restricted templates in triggers. Is it possible to use multiple input triggers in a blueprint?

blueprint:
  name: example multi-trigger
  domain: automation 
    
  input:
    on_button_trigger:
      name: On Button Trigger
      selector:
        trigger:
    off_button_trigger:
      name: On Button Trigger
      selector:
        trigger:

trigger: !input on_button_trigger

action:
2

If you wait there is a new feature added for next month that allows for this:

You will be able to write:

trigger:
  - triggers:  !input on_button_trigger
  - triggers:  !input off_button_trigger
1 Like
3

It would be the other way around, right?

triggers:
  - trigger: !input on_button_trigger
  - trigger: !input off_button_trigger

triggers and trigger switched around

4

I don’t think it’s backwards.

The two in the list should definitely be triggers, as they are a collection of possibly multiple triggers, not a single trigger.

Perhaps the very root key could be trigger: or triggers: , I haven’t kept up exactly with what’s the latest there or which one is deprecated. You may be right.

5

thanks for clarifying!

that would result in something like this - is that correct?

blueprint:

triggers:
  - trigger: time
    at: !input trigger_time
  - triggers: !input custom_triggers

resulting automation:

triggers:
  - trigger: time
    at: "06:30:00"
  - triggers:
      - trigger: state
        entity_id:
          - zone.home

does that seem plausible or am I doing something wrong? feels odd to have nested triggers

6

Why does that seem odd? That is the correct syntax. In practice the lists of triggers are folded into one list, or at least that is how I’ve seen it described by whomever wrote the patch. There (at least currently) would be no point to keeping triggers within some sort of hierarchical tree.

7

Good to know, thanks. I don’t know - just not the way I’m used to seeing it, to be honest ^^