Right, so there are a fews ways to handle triggers vs conditions when you have more than one thing you’re looking at. This has nothing to do with this particular automation and is just in regard to automations in general.
Let’s say I want switch.a to be “on” and switch.b to be “off” in order for my action to take place.
Method 1:
- alias: method one
trigger:
- platform: state
entity_id: switch.a
to: "on"
- platform: state
entity_id: switch.b
to: "off"
condition:
- condition: state
entity_id: switch.a
state: "on"
- condition: state
entity_id: switch.b
state: "off"
action:
- service: whatever
This is the safest, cleanest, easiest to read version. If switch.a goes “off” or switch.b goes “on” this will trigger. The conditions are then evaluated (this makes sure that, just because switch.a went “on” switch.b may not be “off”, so we check with the conditions.
Method 2
- alias: method two
trigger:
- platform: state
entity_id: switch.a
to: "on"
- platform: state
entity_id: switch.b
to: "off"
condition:
- condition: template
value_template: >-
{{ is_state('switch.a','on') and is_state('switch.b', 'off') }}
action:
- service: whatever
This works exactly the same as method 1. However, the condition is less verbose. The downside is, the format of the condition is totally different than that of the trigger, so when you change something, you might have a bit more typing to do.
Method 3
- alias: method three
trigger:
- platform: template
value_template: >-
{{ is_state('switch.a','on') and is_state('switch.b', 'off') }}
action:
- service: whatever
This is the least verbose of them all. The downside is that every time the switch changes it’ll be re-evaluated and the actions will run again. For this small, two entity example, with only two states they can each be in, it makes almost no difference. It’s when you get into “or” situations that it can get messy. Let’s add a third entity, switch.c, and let’s say we want the action to happen when a is on, and either b OR c is off.
- alias: method three take two
trigger:
- platform: template
value_template: >-
{{ is_state('switch.a','on') and (is_state('switch.b', 'off') or is_state('switch.c', 'off')) }}
action:
- service: whatever
So, now with three entities… let’s say a is on, b is on, and c is on. Our trigger doesn’t fire. Easy. Now b changes to off which means the template evaluates to true and our action is performed. Now c changes to off. Since another thing changed, the template is evaluated again, it’s still true, so our action fires again. And maybe we don’t want that. For something like turning on a light, it’s not usually a big deal if you turn it on again. However, if your action starts a light fading slowly from 1% brightness to 100%, the fade would potentially start over again, and that’s probably not what you want.
So, to be safe, for things like this, you implement everything as a trigger AND as a condition. If you know it doesn’t matter, you can save some typing and just implement the trigger with a template.