Triggers, conditions, and actions explained

Separate the event that starts a rule from the checks that allow it and the work it performs.

Most automation problems become easier to reason about when you write three short sentences: when this happens, if these checks pass, do this work. Those correspond to triggers, conditions, and actions. The distinction matters because a condition does not schedule a future run. It evaluates the current situation only when execution reaches that check.

A trigger is an event

A state trigger can watch a motion sensor becoming on. A time trigger can fire at a particular clock time. A sun trigger can fire at sunset. Multiple triggers normally offer alternative ways to start the automation, rather than requiring all events to happen together. Describe the exact transition you need. Watching every state change without specifying from or to can also include changes you did not intend to act on.

A condition is a gate

Conditions restrict whether the triggered run should continue. In the example, motion is the event, while a separate helper must permit automatic lighting. Top-level conditions are normally combined with AND: each must pass. An OR condition can express alternatives, but keep its nesting clear. If the helper changes from off to on while motion remains detected, that condition changing alone will not start this automation. Add a suitable trigger if that transition should matter.

A starting-point automation

Every entity ID below is an example. Replace it with your actual entity ID and review all settings before use.

alias: Motion light when enabled
description: React to motion only while the automatic lighting helper is enabled.
triggers:
  - trigger: state
    entity_id: binary_sensor.hall_motion
    to: "on"
conditions:
  - condition: state
    entity_id: input_boolean.automatic_lighting
    state: "on"
actions:
  - action: light.turn_on
    target:
      entity_id: light.hall
mode: single

Actions are an ordered sequence

Actions can call integrations, introduce a delay, wait for an event, or choose a branch. A condition placed in the action sequence stops that sequence if it fails. A choose block selects a matching sequence and can provide a default. Actions run in order unless you deliberately introduce parallel behavior. Consider what happens if a device is unavailable halfway through, especially when later steps assume an earlier change actually happened.

Use trigger IDs for distinct cases

One automation can react to motion and to a clear interval by assigning each trigger an id. A condition of type trigger inside choose then selects the appropriate branch. That keeps related logic together while preserving the difference between the cases. Avoid adding a top-level condition that only makes sense for one branch; it may unintentionally block another branch, such as turning the same light off after daylight arrives.

Pick a mode that matches overlap

Single ignores a new run while another is active. Restart replaces the running sequence with a new run. Queued retains qualifying runs in order, while parallel allows overlapping runs. A short light action often needs only single. A timed sequence that should restart on fresh activity may need restart. A queue of old lighting commands can feel surprising when the room has already changed, so choose the mode from the intended behavior rather than habit.

Debug the stages separately

If there is no trace, investigate whether the trigger happened and whether the automation was enabled. If a trace stops at a condition, compare the actual state with the expected raw value. If it reaches an action, verify that action and its target independently. Testing actions manually does not prove the trigger works. Write down a few scenarios, including a failing condition and a repeated trigger, then observe each before considering the automation finished.

Write scenarios before adding branches

Try a simple table on paper with the incoming event, relevant current states, and expected result. Include one normal run, one blocked run, and one event that arrives while an earlier action is waiting. If two scenarios imply different outcomes but have identical triggers and conditions, the automation needs another explicit signal or helper. This exercise often reveals a missing manual override or an ambiguous presence assumption before you spend time writing a more elaborate choose block.

Further reference: official Home Assistant documentation.