A Home Assistant numeric state trigger fires when a value crosses a threshold, not while it stays on one side. If it stays silent, check whether the value crossed after arming: a value already past the threshold produces no crossing event.
The Short Answer: A Crossing, Not A Continuous Check
Home Assistant's Numeric state crossed threshold reference describes above: 30 as running when a temperature moves from 30 or below to above 30, rather than repeatedly while the value stays past the line.
If the value was already past the threshold before the automation was enabled, edited, or reloaded, no crossing event is generated; an already-in-range state does not create a retroactive event.
above and below are strict: below: 20 fires only when the value moves from 20 or above to strictly under 20; above mirrors that. Together they define entering a range, not a single edge.
Symptom Checks Before You Edit YAML
What you see | Check first | Why it matters |
|---|---|---|
Value changes, no new trace | Automation enabled | Disabled automations ignore triggers |
Trace starts, no action | Conditions | A failed condition stops the run first |
Trace finishes, nothing changes | Target and device response | A finished trace is not proof the device acted |
Already past the threshold | Crossing | An in-range value generates no new event |
The official Troubleshooting automations page lists the already-past-the-threshold case as a known numeric-state symptom and shows how to read the trace: whether the trigger fired, whether a condition stopped the run ("Stopped because a condition failed"), or whether the action list ran. A trace that reaches the end is not proof of the device outcome.
A manual Run actions click exercises the actions, not the trigger, so it says nothing about a real crossing. Give each trigger an id: trigger ids make the trace say which branch fired.
Trigger Or Condition
A numeric_state trigger waits for a crossing; a numeric_state condition only reports whether the value passes its test at the moment that condition is evaluated. A condition in the top-level condition: block is evaluated when the run starts, but a condition later in an action sequence is evaluated later, after the earlier steps have finished. If the value appears in both places, a failed condition can hide a trigger that worked.
If a crossing appears to go missing, check the automation's actual mode and the trace or log instead of assuming every mode drops triggers. In single mode, a new run is not started while the existing run is still active. The other modes handle an already-running automation differently: restart stops the active run and starts a new one, queued lets the new run wait until earlier runs finish, and parallel starts it alongside. A run that is in progress, for example one sitting in a delay, can interact with a new crossing depending on the mode, but a delay by itself does not universally suppress crossings.
Entity, Attribute, And Numeric Value
- Attribute: the trigger watches the main state unless you set
attribute; select it when the number lives in an attribute. - Numeric state: each watched entity must provide a numeric state, or a numeric value in the attribute you choose.
- Entity-valued thresholds: when
aboveorbelownames another entity, the comparison re-evaluates when the watched entity updates, so a threshold change alone does not trigger it. - Units: raw numeric_state compares numbers as they are and does not convert units, unlike named measurement triggers, which handle compatible units automatically.
- Unavailable or unknown values: don't guess transition rules; check whether the watched entity produced a numeric state, and let the trace or log distinguish a skipped target from a device or integration action error.
For At Least, Restarts, And Reloads
Adding for means the value must stay within the threshold for that long before the trigger fires. The numeric state reference notes this timer resets if Home Assistant restarts or automations reload, so a crossing followed by a restart or reload can pass unnoticed.
A Safe Test You Can Repeat
No real sensor or device is involved. Create a dedicated input_number helper (for example input_number.threshold_watch), then add this automation, which only watches that helper and writes a notification:
alias: "Threshold crossing test"
triggers:
- trigger: numeric_state
entity_id: input_number.threshold_watch
below: 20
actions:
- action: persistent_notification.create
data:
title: "Numeric state trigger fired"
message: "The watched value crossed below 20."This example is proposed and has not been live tested here; it writes a notification and nothing else, so it cannot switch a heater or alter a real sensor reading.
To exercise it, change only the helper's value by hand through these sequences, in order:
Value sequence | Crossing | Expected result |
|---|---|---|
25 to 19 | From at or above 20 to below 20 | One trigger run |
19 to 18 | Stays below 20 | No new trigger run |
20 to 19 | 20 counts as outside, because below is strict | One run when freshly armed outside |
The sequences are illustrative, not benchmarks; read the trace and entity history after each change, and arm the automation while the helper is outside the threshold for the third row.
When The Value Is Already Past The Threshold
An in-range value does not generate a retroactive event, so the next useful event is a genuine crossing. Wait for one, or treat startup checking as a separate design choice rather than a drop-in universal fix.
A time condition crossing midnight, such as after 22:00 and before 06:00, behaves differently from what many expect; see time conditions across midnight for the boundary cases.
Final Checks
Keep the list short: enabled automation, genuine crossing after arming, then the trace.



