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.
Same question! Two motion sensors should turn on / off the light…
Someone? Any trick to emulate it?
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 }}
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'
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.
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.
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
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') }}