You set up an automation: when motion is detected AND it is after sunset AND the door is closed, turn on the porch light. The trigger fires repeatedly but the action never runs. You verify motion is detected. You verify it is after sunset. You verify the door is closed. The condition should be met. But the automation does not run.
Why this happens
The most common cause is the engine’s condition evaluation timing. The engine evaluates conditions at the moment the trigger fires, not at the moment you check them. If conditions are evaluated in a different order, with different freshness, or with different value normalization than what you see in the app, mismatches occur.
The stale state problem
Conditions are evaluated using the engine’s cached device state. If the cache is stale (the device’s actual state changed but the cache has not updated), the condition uses outdated information.
Common scenarios:
- You closed the door 5 seconds ago. The hub cache still shows it as open.
- The thermostat reads 72 on the device but 70 in the hub cache due to slow reporting.
- The light bulb actual state is on but the hub thinks it is off because the bulb did not report back.
Fix: minimize the gap between state change and condition evaluation. If your automation evaluates state immediately after another action sets it, add a brief delay (3-5 seconds) so the state can be reported back.
The condition order issue
Some engines evaluate conditions in the order they are listed. Others short-circuit at the first failed condition. If your most reliable condition is listed last, the engine may give up on the others before reaching it.
Reorder conditions so the most reliable are first. This is not strictly necessary in well-designed engines but helps with debugging because you can see which condition fails first.
Time conditions and seconds
Conditions like “after sunset” or “between 6 PM and 11 PM” are evaluated to the second. If your trigger fires at 6:00:00 PM and the engine evaluates the condition at 5:59:58 PM (just before the trigger was processed), the condition fails.
Add a small buffer to time conditions. “After 5:59 PM” rather than “after 6:00 PM” gives the trigger one minute of slack.
The string versus numeric condition
If your condition compares a device value to a number, but the device reports the value as a string, the comparison may always fail.
Example: thermostat reports temperature as the string “72”. Condition checks if temperature is greater than 70. The string “72” is not greater than the number 70 in some evaluation languages.
Fix: use the device’s correct type. If your hub does not coerce types automatically, use a comparison that handles both (“temperature value matches 72” instead of “temperature greater than 70”).
The OR versus AND confusion
Some users intend “if motion AND door closed” but configure “if motion OR door closed”. The action then fires when either is true, which is more often than intended.
Verify the condition is AND if you mean AND, OR if you mean OR. Many automation editors default to OR when stacking conditions.
The contradictory condition
Sometimes conditions contradict each other by accident. “If light is on AND light is off” can never be true. Less obvious: “if motion was detected in the last 5 minutes AND motion was last detected more than 10 minutes ago”. Logically impossible.
Write out the conditions in plain English to check for contradictions.
The trigger versus condition distinction
Many automation engines distinguish triggers from conditions. The trigger initiates evaluation; conditions filter whether the action runs. A common mistake is putting a condition in the trigger slot or vice versa.
Example: “when motion changes AND door is closed” as a trigger fires only on the exact moment both change, which is rare. “When motion changes” as a trigger and “if door is closed” as a condition fires whenever motion changes and the door happens to be closed at that moment.
The presence condition lag
Presence-based conditions (“if anyone is home”) rely on the hub knowing each person’s presence state. Presence states are typically updated slowly to avoid false positives (a brief Wi-Fi blip should not mark you as away).
If your automation triggers shortly after a presence change, the condition may not reflect the new presence yet. Add a delay or trust the system to catch the right state on the next trigger.
The dual-condition trap
If two conditions both depend on the same device’s state in different ways, they can race. “If light is on AND brightness greater than 50” requires both to be true. If the light just turned on, its brightness may not be reported yet, and the second condition fails.
Reduce to a single composite condition where possible. “If light is on with brightness greater than 50” as a single capability check is more reliable than two separate condition checks.
Test conditions independently
To verify a condition logic, build a test automation that only checks the condition and reports the result. Set the action to a benign notification.
Trigger the condition repeatedly. Verify the notification appears when you expect it. If the test automation works but your real automation does not, the issue is in another part of the real automation.
Logging in Home Assistant
Home Assistant’s automation editor shows trace logs of every triggered automation, including the value of every condition at the moment of evaluation. This is the most powerful debugging tool for condition issues.
Open the automation, click Traces, see what conditions evaluated to and why.
The platform-specific differences
Each automation platform handles conditions differently:
- HomeKit: conditions are evaluated at the moment of the trigger, using last reported state. Limited debugging.
- SmartThings: similar, with slightly more transparent logging in the IDE.
- Hubitat: comprehensive condition evaluation with debug logging.
- Home Assistant: most powerful, includes trace history.
- Alexa: conditions are simple and limited; complex logic must be split across routines.
If your home runs complex conditional automations, the platform matters. Home Assistant and Hubitat are best for users who want full control.
The notification debug pattern
When a conditional automation refuses to fire, build a parallel debug routine with the same trigger and condition but a different action: send a phone notification with the current value of the condition variable. When the trigger fires, you see whether the condition is what you expect.
This pattern surfaces stale-state issues, type mismatches, and timing problems that are otherwise invisible. Once you find the cause, remove or disable the debug routine. The wider topic of state inconsistencies is in our device status drift guide.
