Home Assistant Automation Not Working? A Step-by-Step Diagnosis

When an automation fails, resist changing the device, schedule, conditions, and network at the same time. Even if that makes it work again, you may not know which change mattered or whether the original problem remains.

Start with one failed attempt. Record what should have happened, what actually happened, and the time. Then collect enough evidence to decide which part to investigate next.

This guide is for an existing Home Assistant automation. It provides a diagnostic process, not a universal repair for every device integration. Choose a harmless routine, such as a nonessential lamp, for hands-on tests.

Know what a manual test proves

Home Assistant's Run actions control skips the automation's triggers and conditions. It therefore tests a different path from the real event. The documentation also describes traces, which show the route a run took, and individual action or condition tests. Tests relying on trigger data or earlier steps require care because isolated execution may lack that context. Home Assistant: Testing and troubleshooting automations

Treat “it works when I press Run actions” as useful evidence about that test, not confirmation that the complete automation is fixed.

1. Write a reproducible failure statement

Replace “the lights are broken” with a specific observation. For example: “At 20:05, I used the bedside button. The reading lamp stayed off. The same lamp responded to a direct dashboard command at 20:07.”

That statement does not establish the cause. It gives you a starting point that someone else can understand and repeat.

Diagnostic note	What to record
Automation	Exact name
Intended event	Button press, time, state change, or other event
Expected result	Target and desired state
Observed result	What physically happened
Time	Local time and date
Recent change	Renaming, editing, update, or unknown
Manual comparison	Action attempted and outcome

Do not assume that an update caused the problem merely because it happened recently. Record it as a possible lead until a comparison supports the connection.

2. Check the evidence for the failed attempt

Open the automation and inspect the trace corresponding to the time you recorded. In the current documentation, Traces is available from the editor or the automation list's menu. Trace details include the steps and timing of a run. Home Assistant troubleshooting documentation

First confirm that you are examining the relevant attempt. A successful earlier run can make a later failure look mysterious if the timestamps are overlooked. If you cannot find matching evidence, write “no matching trace located,” rather than deciding immediately that the device failed.

3. Choose the next test from the evidence

Use this table to form a testable question. It is a triage aid, not a list of guaranteed diagnoses.

Observation	Next question
No matching run found	Am I examining the correct enabled automation and event?
A run stops before the intended action	Which decision prevented that action?
A recorded action reports an error	What is the exact error and target?
The run completes but nothing visible changes	Was the expected target and state actually requested?
The light changes and immediately changes back	What other activity occurred at that time?

Keep “observed” separate from “suspected.” For instance, “no visible lamp change” is an observation; “the Wi-Fi is unreliable” is a theory that needs its own evidence.

4. Make one controlled change

Save a note of the original setting. Change the smallest relevant item, repeat the same test, and record the outcome. If you alter the target, timing, and condition together, the comparison becomes difficult to interpret.

Consider this hypothetical case: a routine targets an old lamp name after equipment was reorganized. Your test is not “rebuild the smart home.” It is “verify the intended target, correct that one reference if needed, and repeat the original event.” If the problem persists, preserve that result and move to the next evidence-supported question.

Do not erase a condition merely because it blocked the action. It may be doing its intended job. Compare the value at the failed attempt with the behavior you wanted before deciding whether the condition itself is wrong.

5. Retest the ordinary event and the exception

Once the action succeeds, repeat the event that originally failed. Then test one situation where the routine should intentionally do nothing. A nighttime light routine should be checked in both an allowed and an excluded situation, using a safe test setup.

Use a compact test record:

Test	Expected	Observed	Result
Direct action comparison	Named target changes as requested
Original initiating event	Complete routine produces the intended result
Excluded situation	No unwanted action
Repeat event	Agreed repeat behavior

Call the issue resolved only as far as these observations support. One successful attempt may justify “worked in this test,” while a failure that appeared only overnight needs another relevant observation period.

6. Prepare a useful support report

If you still need help, include the failure statement, relevant configuration, software and integration versions, timestamps, exact error, and changes already tested. Remove passwords, access tokens, setup codes, precise home location, and other private information from anything shared publicly.

Ask a narrow question: “Why did this condition reject the 20:05 event when this value was present?” is more actionable than “Why does Home Assistant never work?” A clear record also lets you stop troubleshooting and resume later without repeating the same unsuccessful experiments.

Related guides

• 5 Simple Smart Home Automations with Clear Stop Rules
• Local vs Cloud Smart Home Control: A Practical Comparison

Sources and method

Interface behavior and test limitations were checked against Home Assistant's official troubleshooting documentation on 21 September 2026. Menu wording can change. The diagnostic tables and hypothetical lamp example are HomeTechPulse editorial tools; they do not represent a test performed on the reader's installation.