Use target for trigger in blueprint?

Configuration Blueprints
1

I want create a blueprint for alarm when I could select multiple motion sensor as trigger.

Any way to use target as selector and use in trigger?

I see that I can set in automation multitples entity_id, but, I don’t know how use the variable in blueprint.

1 Like
2

Same question! Two motion sensors should turn on / off the light…

1 Like
3

Someone? Any trick to emulate it?

4

It’s a bit sketchy but should work:

blueprint:
  name: Test blueprint
  description: Test multiple trigger selection
  domain: automation

  input:
    input_target:
      name: Entity state triggers
      selector:
        target:

mode: restart
max_exceeded: warning

variables:
  var_targets: !input input_target

trigger:
    - platform: event
      event_type: state_changed
    
condition:
  - condition: template
    value_template: "{{ trigger.event.data is defined }}"

  - condition: template
    value_template: "{{ trigger.event.data.entity_id in var_targets.entity_id }}"
  
action:
  - alias: "Log to logbook"
    service: logbook.log
    data:
      name: Triggered
      message: >
        Triggered by -> {{ trigger.event.data.entity_id }} 
        targets {{ var_targets.entity_id | to_json }}
2 Likes
5

This works for me for multiple triggers including motion, but all three inputs need to be selected. In the event that you have less than three motion sensors you can select the same sensor twice or three times and it still works.

OPTIONAL/default: for the last two triggers indicating that they’re optional is a hangover. The blueprint/automoation will fail unless all are selected.

Should work for all binaries, but I’ve only experimented with two - motion and switch.

  input:
    trigger_entity_1:
      name: Trigger Entity No. 1
      selector:
        entity: {}
    trigger_entity_2:
      name: (OPTIONAL) Trigger Entity No. 2
      default:
      selector:
        entity: {}
    trigger_entity_3:
      name: (OPTIONAL) Trigger Entity No. 3
      default:
      selector:
        entity: {}

trigger:
  - platform: state
    entity_id:
      - !input 'trigger_entity_1'
      - !input 'trigger_entity_2'
      - !input 'trigger_entity_3'
    to: 'on'
3 Likes
6

Have you had any issues with the automation being triggered multiple times for one sensor change in the event that you specify the same sensor multiple times? If not, and there are no performance issues, that seems like a good workaround.

From what I’ve observed, variables defined in the variables: section aren’t accessible in the trigger: section, so doing things like template triggers that reference the contents of those variables aren’t possible. If we either get target support for triggers or variable access in the trigger: block, that would simplify things.

7

I personally haven’t noticed it, but depending on how your blueprint works then reusing the trigger may have side effects. I’ve also create dummy sensors, which will never be triggered, to use when I don’t have sufficient trigger entities.

8

I used your suggestion in my blueprints where I have one trigger in some implementations and multiple triggers in others - I created multiple blueprint inputs and just assigned them all to the same entity in cases where I didn’t need all the inputs.

That worked great until I started adding some more compled features to my blueprints. It turns out that if you use code like:

trigger:
- platform: state
  entity_id: !input remote
- platform: state
  entity_id: !input remote_2

and then assign remote and remote_2 to the same entity, the automation will get triggered twice whenever the entity changes state. In many cases, that may be ok. However, in one of my blueprints, there is a side-effect action of incrementing a counter, and using a blueprint this way would results in double-counting state changes.

The solution is using dummy/fake/mock sensors as you described. That seems to work well for now.

Here’s an example of a fake door sensor that’s always open:

- platform: template
  sensors:
    fake_binary_sensor_door_always_open:
      friendly_name: 'Fake Binary Sensor - Door - Always Open'
      value_template: "{{ true }}"
      icon_template: hass:door-open
      device_class: door
2 Likes
9

As of 2021.3, you can now use variables in triggers, so you can have optional trigger entities without having to resort to fake sensors or other workarounds. This isn’t as clean as the target functionality for services, but IMHO it’s better than what we had before…

So your inputs can look something like this:

    door_entity_1:
      name: 'Door Sensor 1'
      selector:
        entity:
          domain: binary_sensor
          device_class: door

    door_entity_2:
      name: '[OPTIONAL] Door Sensor 2'
      default:
      selector:
        entity:
          domain: binary_sensor
          device_class: door

and then you can add variables to use within triggers like this:

trigger_variables:
  door_entity_1: !input door_entity_1
  door_entity_2: !input door_entity_2

and then the trigger section looks like this:

trigger:
- platform: template
  value_template: >-
     {{ is_state(door_entity_1, 'on') }}
- platform: template
  value_template: >-
     {{ is_state(door_entity_1, 'off') }}
- platform: template
  value_template: >-
     {{ door_entity_2 != none and is_state(door_entity_2, 'on') }}
- platform: template
  value_template: >-
     {{ door_entity_2 != none and is_state(door_entity_2, 'off') }}
1 Like
10

Yes! They just added this in 2022.4! I was struggling with the same issue, and like 3 days later, they add it!

The entity selector shows an entity finder that can pick a single entity or a list of entities based on the selector configuration. The value of the input will contain the entity ID, or list of entity IDs, based on if multiple is set to true.
1 Like