Automation Triggers - nuance question on how they are evaluated

Looking for someone who knows (no ‘I thinks’ please)… I did not find this answer after doing a few searches and reading the Wiki.

I’m not asking for help writing an automation. I want to know/understand how HA evaluates the WHEN statements.

Looking for someone who understands at the source-code level how HA evaluates the WHEN trigger section.

Question:
How does HA evaluate the WHEN conditions of an Automation if there are multiple conditions that can be True at the same time?

The YAML below shows a simple (real world) example.

I want the Automation to trigger when the Helper changes to either Stay or Sleep but NOT if the Helper changes from “Stay → Sleep” or “Sleep → Stay”>
– in those two cases, I do not want automation actions at all.

I have set it to watch for all 4 cases, and exclude the latter 2 cases based on ID, but not sure that will work as HA would need to simultaneously record and use two IDs to evaluate the Automation.

Or, does the order they are listed in matter… and in my example, since conditions I want to avoid are listed first, they will be evaluated then no-op (automation will exit without action) – but when the triggers are ‘Stay’ or ‘Sleep’ actions will properly execute?

Thank you for the help HA experts!

alias: "House Modes 1 : Selector Armed with Bypass -> Arm Panel"
description: House Mode Selector triggers Alarmo Master to be set + Bypass
triggers:
  - entity_id:
      - input_select.house_mode_selector
    trigger: state
    to: Sleep
    id: Stay to Sleep
    from: Stay
  - entity_id:
      - input_select.house_mode_selector
    trigger: state
    to: Stay
    id: Sleep to Stay
    from: Sleep
  - entity_id:
      - input_select.house_mode_selector
    trigger: state
    to: Sleep
    id: Sleep
  - entity_id:
      - input_select.house_mode_selector
    trigger: state
    to: Stay
    id: Stay
conditions:
  - condition: state
    entity_id: input_boolean.bypass_alarm_zones
    state: "on"
actions:
  - choose:
      - conditions:
          - condition: not
            conditions:
              - condition: trigger
                id:
                  - Stay to Sleep
                  - Sleep to Stay
        sequence:
          - action: envisalink_new.alarm_keypress
            metadata: {}
            data:
              keypress: NNNNN
            target:
              entity_id: alarm_control_panel.alarm_partition_1
          - delay:
              hours: 0
              minutes: 0
              seconds: 5
              milliseconds: 0
          - action: alarm_control_panel.alarm_arm_night
            metadata: {}
            data: {}
            target:
              entity_id: alarm_control_panel.alarm_partition_1
mode: single

Isn’t not_from what you are looking for?

  - entity_id:
      - input_select.house_mode_selector
    trigger: state
    to: Sleep
    not_from: Stay
    id: Sleep

1 Like

What other states does it have, and use it to change from that as what you have described will never trigger unless there is some other state.

sorry if I wasnt clear… I’m not asking people to help me write this specific automation. I want to know/understand how HA evaluates the WHEN statements

Looking for someone who understands at the source-code level how HA evaluates the WHEN trigger section.

My experience is that both will trigger unless the mode restrict and/or code does it.
Meaning if it’s in single mode and there is a slight delay only one of them will run.
If the action part is quick then they will both run.
As I remember it, it’s random which is first to trigger.
But I guess you could test that with your code here as it is and just have it send a notification or write to an excel sheet.

They are separate listeners, in separate threads. If you’re in run mode single, whatever when comes first is what actions the automation. HA is async, so there’s no guessing which one will actually be first.

Then make that a condition. If you want to account for that inside the triggers, do what @koying said.

1 Like

thank you and @petro … I didnt see not_from, thats great. Seems like something that would be great to expose in the Visual Editor