In this article
A smart-home mystery often begins with a vague question: Why did that light turn on? Home Assistant can help, but no single screen tells the whole story. A useful investigation has three layers:
- Timeline: What changed, and when?
- Execution: Why did an automation follow that path?
- State: How did an entity’s value change around the event?
Home Assistant maps those layers to Activity, automation traces, and History. Used together, they can turn an unexplained event into a sequence of recorded changes, automation decisions, and entity states.
Scope: This is a documentation-based explanation of Home Assistant 2026.9, not a hands-on test. It makes no measured claims about accuracy, completeness, latency, storage use, or usability.
Choose the view that matches the question
| Question | Start with | What it shows |
|---|---|---|
| What changed around a particular time? | Activity | A reverse-chronological timeline of recorded changes |
| Why did an automation choose a branch or stop? | Trace | The trigger, conditions, actions, and execution path for one run |
| How did a state or measurement change over time? | History | Recorded values for selected entities, devices, or areas |
| Do I need offline analysis? | History export | Selected data exported as CSV |
A practical order is Activity → trace → History: locate the event, inspect any automation involved, and then examine relevant values around that time. If you already know which automation misbehaved, you can start directly with its traces.
Activity: establish the timeline
Activity is the interface previously known as the logbook. It presents changes across the home in reverse chronological order, making it the natural starting point when you know approximately when something occurred but not what Home Assistant recorded around it (Activity integration).
This function is not new to Home Assistant 2026.9. Home Assistant 2026.7 rebuilt the existing logbook as Activity, with a top-to-bottom feed grouped by day (Home Assistant 2026.7 release notes).
Suppose a kitchen light switched on overnight. Activity may show an occupancy change, an automation run, and the light changing to on. That sequence gives you a lead, but chronology alone does not prove that the occupancy event caused the light to change.
When the timeline includes an automation entry, selecting it can open the corresponding trace (automation troubleshooting documentation). That creates a direct bridge from the household timeline to the automation’s internal execution. Other Activity entries—including ordinary entity changes and custom annotations—do not necessarily have traces.
Traces: inspect automation execution
A trace records an automation run step by step. It shows what triggered the automation, which conditions were checked, what its actions did, and which path it followed. The trace appears as an interactive graph whose nodes can be selected for details (automation troubleshooting documentation).
For the kitchen-light example, a trace could answer:
- Which trigger fired?
- Did time, illuminance, or household-mode conditions pass?
- Which branch of a
chooseaction ran? - Did an action complete or fail?
- Which automation configuration was active for that run?
A trace preserves the full YAML configuration from the time of the run and can show activity related to that trace (automation troubleshooting documentation). The preserved configuration is particularly valuable after an automation has been edited, although the documentation does not claim that “related activity” includes every causally connected event.
Retention is the main catch. Home Assistant stores the last five traces for each automation by default; the count can be changed with stored_traces (automation troubleshooting documentation). If an automation runs frequently, the trace for an older incident may already be gone.
Traces also stop at the boundary of automation execution. A trace may establish that a motion trigger fired, but it may not explain why the physical sensor produced that signal.
History: examine state over time
History is better suited to questions about changing states and measurements. You can select areas, devices, or entities, choose a time frame, and export the selected data as CSV (History integration).
For the unexpected light, you might compare the light state with occupancy, illuminance, device availability, and any helper used as a condition. A time-series view can expose context such as repeated threshold crossings that is difficult to spot in a chronological event feed.
This matters because sensors assigned units of measurement are automatically excluded from Activity: Home Assistant assumes they change frequently (Activity integration). History is therefore usually the more useful view for recorded temperature, humidity, power, or illuminance values.
The History documentation says Recorder stores detailed sensor data for 10 days by default. Longer ranges can use long-term statistics for sensors whose state_class is measurement, total, or total_increasing. Those statistics are sampled and averaged hourly, so older values may differ from recent, full-resolution readings and may not preserve brief changes (History integration). Recorder retention can be extended, potentially requiring more storage.
Recorder and filters define the blind spots
Activity and History both depend on Recorder and use its configured database. If Recorder uses MySQL or PostgreSQL, for example, Activity does not maintain a separate SQLite store (Activity integration).
Activity follows Recorder’s filter by default, but Activity-specific include and exclude filters can narrow what appears in its timeline (Activity integration). Excluding an entity only from Activity does not save database space; the underlying data still occupies storage. Excluding it from Recorder may avoid that storage, but History will then contain no data for the entity (Activity integration; History integration).
That distinction suggests two different choices:
- Filter Activity to reduce timeline noise while retaining data elsewhere.
- Filter Recorder only when losing that entity’s recorded history is acceptable.
Add useful landmarks
The logbook.log action can add custom entries to Activity, such as “Guest mode enabled” or “Ventilation boost requested” (Activity integration). These landmarks can provide useful context, but they are declarations made by an automation—not independent confirmation that a physical event occurred.
Filtering matters here too. If logbook.log is called without a domain or entity ID, its entry uses the logbook domain; filtering out that domain prevents the entry from appearing in Activity (Activity integration).
A compact diagnostic workflow
- Find the event and surrounding sequence in Activity.
- Open the trace if an automation entry is available.
- Inspect its trigger, conditions, branches, actions, and saved configuration.
- Use History to compare relevant states and measurements.
- Check Activity filters, Recorder exclusions, and retention when evidence is missing.
Activity explains the sequence Home Assistant recorded. Traces explain the internal path of retained automation runs. History shows how recorded states developed over time. Together they provide a strong diagnostic chain—but none can reconstruct events Home Assistant did not observe, store, or retain.
No comments yet