Currently automation conditions do AND, meaning that every condition should pass before continuing to actions. I would love to use conditions but when I have little more complex automation, conditions gets very complex and unreadable.
e.g. Turn on lights when it’s dark When it’s night only motion triggers lights.
I hope i wrote it down correctly but this really twists my brain. This is just simple example. One of the condition would look something like this:
NOT night OR motion - Passes on day or when there’s motion on night.
Could we have something like choose for conditions too? I know I can just use choose in actions but using conditions would really help me clear things out there by dropping at least obvious false positive triggers off.
I don’t really see a “Choose” for conditions adding a significant boost in functionality considering the flexibility of current condition types. Can you show a mock up of how you think it might look/work with your night & motion example?
What am I missing here? There’s an “Or” condition already. There’s also a “Not” condition if you really want to do “Not” night instead of above horizon like I am.
Here’s a stub with OR. Unfortunately I did not have to finish now. I have to say that new automation UI makes it much easier. Still it’s bit tedious to handle all valid combinations.
Maybe I miss something like
“when trigger id is “motion outside” check this condition to continue” If-then condition
Or conditional trigger. e.g. trigger with id motion outside when it’s dark
Plus I’m not a fan of how when an automation doesn’t pass the condition it still makes a trace. Makes it very difficult to effectively debug some triggers that happen very frequently, like if you need to listen for the call_service or state_changed events.
Yeah but in other hand it’s nice to debug conditions in other situations . Anyhow main motivation to use conditions is to stop the logs getting cluttered.
I believe you can do that using the first variant of Trigger Variables.
The first variant allows you to define variables that will be set when the trigger fires. The variables will be able to use templates and have access to the trigger variable.
alias: example
trigger:
- id: first
platform: state
entity_id: binary_sensor.whatever
from: "off"
to: "on"
variables:
status: "{{ ... Template Condition for the first trigger ... }}"
- id: second
platform: state
entity_id: binary_sensor.whatever
from: "on"
to: "off"
variables:
status: "{{ ... Template Condition for the second trigger ... }}"
condition:
- '{{ status == true }}'
action:
... etc ...
For jollierfinbeam’s example, the two Device Triggers probably need to be converted to State Triggers because (and I may be mistaken) I don’t believe Device Triggers support Trigger Variables.
alias: Ulkovaloautomaatio
description: ""
trigger:
- platform: state
entity_id:
- binary_sensor.yo
from: "off"
to: "on"
id: Night begins
variables:
status: "{{ ... Template Condition .. }}"
- platform: state
entity_id:
- binary_sensor.yo
from: "on"
to: "off"
id: Night ends
variables:
status: "{{ ... Template Condition .. }}"
- platform: state
entity_id: binary_sensor.etuterassin_sensori_on_off
from: "on"
to: "off"
id: Motion not detected
variables:
status: "{{ ... Template Condition .. }}"
- platform: state
entity_id:
- binary_sensor.ulkona_pimeaa
from: "off"
to: "on"
id: Dark outside
variables:
status: "{{ ... Template Condition .. }}"
- platform: state
entity_id:
- scene.ulkona_pimeaa
from: "on"
to: "off"
id: Not dark in outside
variables:
status: "{{ ... Template Condition .. }}"
condition:
- '{{ status == true }}'
action:
- choose:
- conditions: []
sequence: []
mode: single
Instead of '{{ status == true }}' it can be reduced to '{{ status }}' because status contains a Boolean value (however some users might not understand that syntax).
. Anyhow main motivation to use conditions is to stop the logs getting cluttered.