Debugging Automations: Trace, History, Logbook, and States

An automation that silently doesn't fire is genuinely one of the most frustrating experiences in this entire course, precisely because nothing visibly went wrong at all, something simply didn't happen. This lesson hands you four genuinely reliable tools for turning that silence into a clear, calm, followable story.

Developer tools: States, the fastest first check

Settings, Developer tools, States shows every single entity's current value at this exact moment, and it's genuinely the fastest place to confirm whether a sensor's state is what you actually expect it to be right now. If a motion sensor's state reads "off" when you're standing directly in front of it, waving your arms, the automation was never genuinely going to fire, no matter how carefully the trigger and action were configured.

Entity history: what genuinely happened earlier

Every entity's history page, reachable directly from its more-info dialog, plots exactly how its state changed over time, letting you genuinely confirm whether a sensor actually reported motion at the moment you expected it to. This view is considerably more useful than developer tools' current-state snapshot whenever you're investigating something that already happened in the past rather than checking on right now.

The logbook: your home's diary of events

The logbook reads considerably more like plain English than the raw history graph, "Hallway Motion detected motion," "Hallway LED turned on by automation," listed in genuine chronological order. It's often the very fastest way to confirm whether an automation actually ran at all, and if it did, exactly what triggered it and precisely what it changed as a direct result.

Trace: one automation's complete run, step by step

Open any automation and its Traces tab shows every single recent run as a genuinely detailed, step-by-step timeline, exactly which trigger fired, exactly which conditions passed or failed, and exactly which actions actually executed, each with its own real timestamp. When a logbook entry alone doesn't fully answer why something happened, trace is almost always where the full, genuinely complete answer actually lives, waiting to be read.

Reading a trace result: a beginner's glossary

A green checkmark on a condition genuinely means it passed, a red mark means it failed and the automation stopped right there immediately without continuing any further. The trigger box at the very top shows exactly what data arrived, including the entity and its old and new state, while each action box below shows exactly what was sent to which entity, in the exact order it actually ran.

A worked scenario: motion doesn't turn the LED on

Start with developer tools' States to genuinely confirm the motion sensor itself is reporting correctly right now. If it is, check the logbook to see whether the automation even attempted to run at all. If it never even appears there at all, the trigger itself likely never fired in the first place, if it does appear but clearly stopped early, open its trace and look carefully for exactly which condition genuinely failed and why.

Matching a symptom to the right first tool

"Is this sensor even working correctly right now" genuinely points to States. "Did this already happen earlier today, before now" points to history. "Did my automation actually run at all" points to the logbook. "Why exactly did my automation do what it did" points directly to trace. Learning this simple mapping saves considerably more time overall than randomly clicking through every single tool hoping one of them happens to reveal the answer.

Never change three things at once

When an automation genuinely isn't behaving as expected, the single most valuable debugging discipline is changing exactly one thing at a time, then testing again immediately, rather than adjusting the trigger, a condition, and the delay all together and hoping the combined result happens to work. Changing three things at once and somehow getting a working result still leaves you genuinely unsure which single change actually mattered and which two were entirely irrelevant.

The right order: fastest tool first, deepest tool last

Check States first, it takes only seconds. Check the logbook second, it's still genuinely fast and tells you whether anything ran at all. Reach for entity history when you need a broader picture over time. Save trace, the deepest and most detailed of the four, for genuinely stubborn problems the first three simpler tools couldn't already fully explain on their own.

Real examples of what these tools reveal

A trace showing a condition failing every single time often reveals a typo in an entity ID, easy to miss by eye but genuinely obvious once trace shows the condition comparing against an entity that doesn't actually exist. A logbook with no automation entry at all despite a clearly firing sensor often reveals the automation was disabled, quietly and without any obvious notice, at some earlier point you'd genuinely forgotten about entirely.

Trace and this module's earlier lessons, connected

Everything this module has built so far, conditions, modes, delays, becomes genuinely visible inside trace, a skipped condition shows clearly as a red mark, a restarted delay shows as a new trace entirely rather than a continuation of the old one, and a queued run shows its actual wait time before execution. Trace isn't a brand new concept, it's simply a window onto concepts you've already genuinely learned.

A hands-on exercise for this lesson

Deliberately break one of your existing automations, change a condition's threshold to something genuinely impossible to satisfy, trigger it, and then walk through all four tools in order, States, logbook, history, trace, confirming what each one shows you about the failure. This safe, deliberate exercise builds genuine muscle memory for the day a real automation actually breaks unexpectedly.

Adding a debugging column to your notebook

Record which tool genuinely solved each problem you encounter going forward, over time this builds a genuinely personal reference showing which symptoms in your specific home tend to map to which tool, considerably faster than relearning the general mapping from scratch every single time something goes wrong.

Filtering and searching the logbook effectively

The logbook page lets you filter by a specific entity or a specific automation, which genuinely matters once your smart home has grown busy enough that the unfiltered, all-entity view scrolls by faster than anyone could reasonably read it. Narrowing the logbook down to just your hallway motion sensor and its associated automation, for instance, turns a noisy wall of unrelated events into a considerably cleaner, genuinely readable timeline focused squarely on exactly the one problem you're actually trying to solve right now.

Trace history: comparing today's run against yesterday's

Trace keeps a genuine history of an automation's recent runs, not just the very latest one, accessible from a small dropdown near the top of the trace view showing timestamps for each stored execution. This lets you directly compare a run from this morning that behaved oddly against a run from yesterday that worked perfectly fine, often revealing the exact single difference, a changed condition value, a subtly different trigger source, that explains the entire discrepancy at a glance without further guesswork.

When the trigger never even appears in trace

If an automation has no trace entries at all for the period you're genuinely investigating, the trigger itself never fired, which points your attention away from conditions and actions entirely and back toward the trigger's own configuration, or toward whether the underlying device or sensor was actually reporting anything at all during that window. This is a genuinely important distinction, a missing trace and a failing condition look similar from a distance but point to completely different fixes.

Common entity ID typos and how trace exposes them

A remarkably common source of genuinely silent automation failures is a simple entity ID typo, sensor.hallway_motion typed instead of the actual binary_sensor.hallway_motion, referencing an entity that Home Assistant quietly treats as permanently unavailable rather than throwing an obvious error you'd immediately notice. Trace reveals this instantly and clearly, a condition or action referencing a genuinely nonexistent entity shows plainly as unavailable or unknown rather than the specific value you actually expected to see there.

Keeping a calm mindset while debugging

It's genuinely easy to feel frustrated and stuck when an automation you were sure was correct simply refuses to behave as expected, but these four tools exist precisely so that frustration doesn't need to turn into random, hopeful guessing. Approach every debugging session the same deliberate way, check States, check the logbook, check history if needed, and only then dive into trace, and nearly every mystery in this module resolves itself considerably faster than it would through trial and error alone.

Conditions that fail silently versus loudly

Some condition failures are genuinely obvious the moment you look at trace, a numeric comparison simply came up false. Others are considerably more subtle and harder to spot at a glance, a time-based condition failing because your Home Assistant server's clock and timezone weren't configured the way you originally assumed back in Module 5, or a state condition comparing against a value written with a single stray capital letter that will never actually match no matter how many times you rerun it. Trace treats both kinds of failure identically, a plain red mark, which is exactly why reading the specific values shown inside that condition box matters so much more than simply noticing that it failed at all.

Sharing a trace when you genuinely need help

Home Assistant's community forums, and similar communities elsewhere, are considerably more likely to help quickly if you paste the actual trigger, condition, and action data straight from a trace rather than simply describing the problem loosely in your own words from memory. A trace already contains exactly the timestamps, entity IDs, and state values another person genuinely needs to diagnose the issue, saving both of you an entire, often lengthy round of back-and-forth questions before the real troubleshooting can even properly begin.

Building genuine confidence, one solved mystery at a time

The very first time you trace a stubborn automation all the way down to one specific failed condition, a small but genuinely real shift happens, debugging stops feeling like guessing in the dark and starts feeling like following a trail that was there all along. Every automation you troubleshoot this way afterward gets noticeably faster, not because the tools themselves changed in any way, but because you've genuinely learned exactly where to look first, calmly and confidently, every single time.

Key takeaways

What's next

With triggers, conditions, actions, modes, delays, and now debugging tools all genuinely in place, the next lesson combines every single one of them into one complete mini project spanning a hallway and an office, your first real, genuinely satisfying taste of layered smart home logic working together as a whole.