Say what may happen, and what must not

A condition tests now; it does not wait

Conditions are an optional part of an automation that prevent an action from firing if they are not met. The critical property is timing: a condition evaluates the current state at the moment the automation runs. It does not wait for a state to become true, and it does not remember what was true a minute ago.

This trips people up constantly. “When the door opens and someone is home” works. “When the door opens and then someone comes home” does not — that is two events, and it needs either a second trigger or an explicit wait in the actions.

Say every rule aloud before building it. If the sentence contains “and then”, you probably need a second trigger. If it contains “while” or “if it is currently”, a condition is right.

And, or, not — and building blocks you can test

Multiple conditions listed together must all pass. When you need alternatives, use an explicit or building block; when you need to exclude a case, use not. Making the intent explicit matters more than saving a line, because a future reader — including you — must be able to tell “all of these” from “any of these” at a glance.

The editor rewards this structure. The documentation describes testing a building block such as an and condition, which reports whether the whole block registers as true or false, and you can also test individual conditions inside the block. A deeply nested tangle of implicit logic cannot be inspected that way; a clean block can.

conditions:
  # All of these must pass
  - condition: state
    entity_id: binary_sensor.someone_home
    state: "on"
  - condition: sun.is_set

  # Any one of these is enough
  - condition: or
    conditions:
      - condition: state
        entity_id: input_boolean.guest_mode
        state: "off"
      - condition: numeric_state
        entity_id: sensor.hallway_illuminance
        below: 30

  # And this must not be true
  - condition: not
    conditions:
      - condition: state
        entity_id: media_player.living_room_tv
        state: "playing"

Branch on which trigger fired

When one automation serves several entry points, trigger IDs are the clean mechanism. All triggers can be assigned an optional id; if omitted, it is set to the index of the trigger, and the ID can be referenced from trigger conditions and actions. IDs do not have to be unique, which lets you deliberately group several different triggers that should produce the same result.

That grouping is the underused half of the feature. Three ways of saying “we are going to bed” — a button, a voice command and a time — can share one ID and one branch, while a fourth trigger with a different ID takes a different path.

alias: "Evening routine — several entry points"
triggers:
  - trigger: state
    entity_id: binary_sensor.bedside_button
    to: "on"
    id: "bedtime"
  - trigger: conversation
    command:
      - "good night"
    id: "bedtime"
  - trigger: time
    at: "23:30:00"
    id: "fallback"
actions:
  - choose:
      - conditions:
          - condition: trigger
            id: "bedtime"
        sequence:
          - action: scene.turn_on
            target:
              entity_id: scene.bedtime
      - conditions:
          - condition: trigger
            id: "fallback"
        sequence:
          - action: light.turn_off
            target:
              entity_id: light.downstairs
    default:
      - action: persistent_notification.create
        data:
          message: "Evening routine ran with no matching branch."
mode: single

Note the default branch. A choose block with no default silently does nothing when no branch matches, which is indistinguishable from a broken automation when you are reading a trace at speed. A default that records what happened costs one block and saves an hour.

Handle unknown and unavailable explicitly

The most common silent failure in branching logic is treating a missing value as a meaningful one. An entity that is unavailable is not reporting “off”; it is reporting nothing. A condition written as “is not on” will happily pass for an entity that has dropped off the network entirely, and the automation will proceed on evidence it does not have.

Write conditions positively where the consequence matters. “Proceed only if the sensor is on” fails safe when the sensor is unavailable; “proceed unless the sensor is on” fails open. For anything consequential — heating, locks, water, notifications that will wake somebody — make the positive form the rule.

Where a branch depends on a value that may go missing, add an explicit branch for that case rather than folding it into the default. A trace that shows “took the sensor-unavailable branch” is diagnostic. A trace that shows nothing happened is not.

Disable parts instead of deleting them

When narrowing down misbehaviour, every individual trigger in an automation can be disabled without removing it by adding enabled: false. This is far better than commenting things out or deleting them, because the structure — and your intent — survives.

Triggers can also be disabled based on limited templates or blueprint inputs, which are evaluated once when the automation is loaded. That is how a blueprint can offer optional behaviour without shipping two versions of itself.

Apply the same discipline to branches. Keeping a branch present but inert, with a comment explaining why, means the next person to read the automation learns something. Deleting it means they rediscover the same problem from scratch.

Test each condition and each branch

The automation editor shows a condition's state as soon as you add it: hover the state indicator circle on the left of the condition row to see Condition passes, Condition did not pass, Invalid condition configuration, or Condition state unknown. Verification is automatic and continuous, so editing an option updates the reported state immediately.

Each condition can also be tested individually from the three dots menu on the condition row, and each action can be run individually with Run action, which reports Action ran successfully or Error running action with a dialog for details. The documentation notes the limit: complex automations that depend on previous blocks — trigger IDs, variables in templates, or action calls returning data for later steps — cannot be tested this way.

So test what can be tested in isolation, then exercise the whole thing with real triggers and read the trace. Both halves are necessary; neither is sufficient.