Smart Home

Home Assistant automation won't trigger

Debug a Home Assistant automation that won't fire — the single-mode block, state vs numeric_state, trigger vs condition, the reload trap, and reading the trace.

Problem summary

An automation that won't fire is almost always one of a handful of causes: single mode (the default) silently blocks re-runs while one instance is still active; numeric_state fires only on a threshold crossing; a bare state trigger over-fires on attribute changes; trigger and condition get confused; or a YAML edit wasn't reloaded. The fastest path is to read the automation's trace, which shows exactly where it stopped.

Operator snapshotEvidence first

First proof

Open the automation's trace after the moment it should have fired.

Screen to open

Settings > Automations > (automation) > Traces

Expected signal

The trace shows whether the trigger fired and where it stopped.

Stop boundary

Leaving the default single mode with a delay/wait inside, or editing YAML without reloading.

Layer path

1An automation that won't fire is almost always one of a few causes, and the trace tells you which — read it first.

2The default `single` mode silently blocks a re-run while one instance is still active (common with `delay`/`wait`), logging only a warning.

3Trigger semantics trip people: numeric_state fires on a threshold being crossed (not 'while above'), and a bare state trigger fires on every state and attribute change.

4Trigger vs condition and the reload trap: the trigger starts the automation, the condition gates it; and a YAML edit needs a reload/restart while UI edits reload automatically.

Runbook

Step-by-step runbook

Start here. Do each check in order, compare it to the expected result, and stop when the evidence explains the failure or the safe stop point applies.

Start from the trace

Check: Open the automation's trace for the time it should have fired.

Expected result: You see whether the trigger fired and where it stopped.

If not: If there's no trace, the trigger didn't fire — fix that first.

Rule out the mode

Check: If it ran once then stopped, check for single mode + an active delay/wait.

Expected result: Overlapping runs are allowed (or restructured).

If not: Use restart/queued/parallel or a timer helper.

Fix trigger semantics

Check: Confirm numeric_state crossings and scope bare state triggers with from/to.

Expected result: The trigger fires when (and only when) intended.

If not: Use a condition for 'while above', not a trigger.

Separate trigger from condition

Check: Ensure the starting event is the trigger and gates are conditions.

Expected result: The automation starts on the right event and gates correctly.

If not: Logic buried only in a condition looks like 'not firing'.

Reload and re-test

Check: Reload automations after YAML edits and re-trigger the scenario.

Expected result: The current version runs and the trace confirms it.

If not: If it still fails, the trace shows the next step to fix.

Decision tree

If: Ran once, never again.

Then: single mode blocking re-runs.

Action: Switch to restart/queued/parallel, or move long waits to a timer helper.

If: numeric_state never fires.

Then: Value already past the threshold, or unknown/unavailable states.

Action: Ensure a real crossing; use a condition for 'while above'.

If: Fires too often or at the wrong time.

Then: Bare state trigger firing on attribute changes.

Action: Add `from`/`to` (or `for:`) to scope the state trigger.

If: Edited it but nothing changed.

Then: YAML edit not reloaded, or logic only in a condition.

Action: Reload automations; verify the trigger actually starts it.

Evidence

Evidence table

Symptom	Evidence to collect	Likely layer	Next action
Automation ran once then stopped.	Mode setting and whether a delay/wait is active.	single mode block	Change mode or use a timer helper for long waits.
Threshold automation never fires.	Entity value at load vs threshold; unknown/unavailable handling.	numeric_state crossing semantics	Ensure a crossing; use a condition for 'while above'.
Fires on unrelated changes.	state trigger without from/to (attribute changes).	Over-broad state trigger	Add from/to or for: to the trigger.
Edit had no effect.	Whether YAML was reloaded; trigger vs condition placement.	Reload trap / trigger-condition mix-up	Reload automations; put the event in the trigger.

Reference

Commands and settings paths

Read the automation trace

Settings > Automations > (automation) > Traces

Where: In the Home Assistant UI.

Expected: The trace shows the trigger firing and which step stopped it.

Failure means: No trace entry means the trigger never fired.

Safe next step: Fix the trigger; if it fired, inspect the condition/mode.

Test a value/template live

Developer Tools > Template (and Developer Tools > States)

Where: In the HA UI.

Expected: Your template/threshold evaluates as you expect for the current state.

Failure means: Unexpected values (text, unknown/unavailable) explain a non-firing numeric_state.

Safe next step: Adjust the trigger/condition to handle the real state values.

Reload automations after YAML edits

Developer Tools > YAML > Reload Automations (or restart)

Where: In the HA UI.

Expected: The edited automation is active.

Failure means: Skipping the reload leaves the old version running.

Safe next step: Reload (or restart) whenever you edit YAML directly.

Hardware boundary

Hardware and platform boundary

Change only when

Reach for timer/helper entities (instead of long in-automation delays) and the trace/template tools whenever automations get complex — they're the reliable building blocks.

Evidence that matters

Using traces to debug, appropriate modes, timer helpers for long waits, and current pluralized YAML keys (triggers/conditions/actions).

Evidence that does not matter

Adding more hardware — this is a logic/config problem, not a performance one.

Avoid

Leaving the default single mode with a delay/wait inside, or editing YAML without reloading.

Related tool

Use the linked tool to turn this runbook into a guided check for your exact setup.

Device setup troubleshooter

Last reviewed

2026-06-03 · Reviewed by HomeTechOps. Built from 2026-06 research verified against home-assistant.io automation modes and troubleshooting docs; wins on structure — a single decision tree over the classic causes (single mode, numeric_state crossing, over-broad state trigger, trigger-vs-condition, reload trap) anchored on reading the trace. Verify exact mode/max defaults before quoting.

Sources/assumptions

Assumes a current Home Assistant where automation keys are pluralized (triggers/conditions/actions); the older singular keys still work but are legacy.
Mode defaults (single, max 10) and trigger semantics are taken from the live Home Assistant docs; verify exact defaults before quoting them.
UI-edited automations reload automatically; YAML edits need a reload/restart before they take effect.

Source-backed checks

HomeTechOps turns official docs and conservative safety rules into a shorter runbook. These links are the source trail for the page direction.

Home Assistant: Automation modesUsed for the single (default) mode silently blocking re-runs while one instance is active, and the queued/parallel/restart alternatives — a top cause of 'automation ran once then stopped'.Home Assistant: Automation triggers & troubleshootingUsed for numeric_state firing on threshold crossing, state triggers without from/to over-firing on attribute changes, trigger-vs-condition, and using the trace timeline to debug.

Diagnostic rule

1. Check the simplest signal first.
2. Change one thing at a time.
3. Confirm the layer (radio, IP, app) before deep config.
4. Stop when the evidence says the risk moved.

FAQ

My automation ran once and now won't run again — why?

That's the default `single` mode. While one run is still active (commonly because of a `delay` or `wait`), `single` mode blocks new runs and just logs a warning. If overlapping runs are expected, change the mode to `restart`, `queued`, or `parallel`. A `wait_for_trigger`/`delay` also doesn't survive a restart or reload — use a timer helper for long waits. See automation modes.

Why doesn't my numeric_state (temperature/threshold) trigger fire?

numeric_state fires on the threshold being crossed, evaluated when the entity changes — so if the value is already above the threshold when the automation loads, it won't fire until it dips and crosses again. Also handle `unknown`/`unavailable` states, which aren't numbers. If you want 'while above', that's a condition, not a trigger. The trace will show whether the trigger fired and the condition passed.

I edited the automation but nothing changed — what did I miss?

If you edited YAML directly, you have to reload automations (or restart) before the change takes effect; UI edits reload automatically. Also check trigger vs condition: the trigger is the event that starts the automation, the condition is a gate that must pass to continue — putting your real test only in a condition with a too-broad trigger is a classic miss. Open the automation's trace to see exactly where it stopped.