Decide Which Home Assistant History Is Worth Keeping

Home Assistant does not need a year of detailed household events to show a year of useful temperature trends. Its recorder keeps recent history, while eligible numeric sensors can also produce long-term statistical summaries. Decide which question needs answering before extending retention: an hourly trend cannot reconstruct every change, and a current sensor reading does not prove that historical evidence exists.

This distinction matters on a small home server sharing storage with other self-hosted services. More retained detail has a storage cost; excluding too much removes the evidence needed to understand a smart home. The useful target is enough detail for diagnosis and enough summary data for comparison, not the biggest possible database.

Start with the question the household needs answered

Consider a room that feels cold. There are at least two different investigations: whether its temperature has declined across several weeks, and what happened around one particular heating cycle. The first can often use hourly summaries. The second may need the timing of temperature changes, heating activity, and other relevant entities during a much narrower window.

Write the intended question beside each important entity before choosing a retention policy:

• Seasonal comparison: preserve suitable numeric statistics and understand their resolution.
• Recent fault investigation: keep enough detailed history to cover the usual delay before someone notices a problem.
• An exact old event: do not assume that an aggregate can reconstruct the original sequence.
• A reading with no historical purpose: consider whether recording it provides useful evidence at all.

These are different evidence requirements, even when they concern the same room or device.

Recent detail has a retention boundary

The recorder documentation defines purge_keep_days as the history retained after a purge, with a default of 10 days. That default is a starting point, not a promise that every older chart will be empty. History can draw on another type of stored data after detailed records age out.

Retaining detail for longer is reasonable when troubleshooting regularly starts late. It is less compelling when the only requirement is comparing monthly temperature patterns. The recorder continually writes data, so the decision belongs in the home server's storage and maintenance budget, not just in a dashboard preference. Do not assume every installation still uses the default: an existing configuration may already change it.

Older trends are a different record, not a hidden replay

According to the History documentation, longer time ranges can use long-term statistics rather than the recent detailed samples. Those statistics are hourly aggregates, so older portions of a graph can look different from recent portions. That change in appearance alone is not evidence of a broken sensor or network connection.

An aggregate is useful precisely because it reduces detail. It is not a substitute for the original sequence when the question is which event happened first. A seasonal temperature chart and a second-by-second account of a heating failure should therefore have different expectations. Extending retention later also cannot reconstruct samples that have already been removed.

A sensor must actually qualify for the summary

The sensor documentation explains that state class describes the kind of numeric value and is used for long-term statistics. An entity without a state class does not have those statistics. A text status or timestamp is not automatically a long-term numeric series just because it appears beside a temperature graph.

The supplying integration usually sets the state class. Do not relabel an unrelated value merely to make a chart persist: temperature, instantaneous power, and an accumulating energy meter represent different measurements. The expected result is a meaningful statistical series for an eligible sensor, not an everlasting history for every entity in the house. Ordinary retention purges do not remove long-term statistics, but that is not a backup or a guarantee against manual deletion and storage failure.

Excluding data and hiding it are different decisions

History depends on the recorder. If an entity is excluded from recording, its future history is not available through that mechanism. Filtering the Activity display, by contrast, is not the same as deciding what gets stored. The recorder documentation explicitly distinguishes those purposes.

This is both a usefulness and a privacy question. A tidy activity panel does not prove that a household event was never recorded. Conversely, a broad recorder exclusion can discard evidence another view needs. For sensitive entities, define the retention requirement deliberately; do not treat a cosmetic filter as an erasure policy or assume an exclusion removes records already stored.

Choose the evidence before replacing the database

SQLite is the recorder's default and recommended database engine. Moving to a separate database is not a prerequisite for useful long-term trends, and the official recorder documentation warns that migration of existing history between database engines is unsupported. A backend change can therefore threaten the very history it is meant to improve.

A read-only review is the safer first decision: compare a recent and an older range in History for a known numeric sensor, check whether that entity has the expected state class, and note the configured retention and exclusions. No configuration write permission is needed merely to read an accessible chart; inspecting protected configuration requires the appropriate administrator access. Older interfaces and integrations can differ, so use the documentation matching the installed release before making changes.

If the chart lacks older data, separate ineligible sensors, recording exclusions, and a genuinely missing statistical series before buying storage. Any subsequent retention or database change needs a current backup and a recovery plan. Reverting a setting can change future behavior; it cannot undo data already purged. Keep the decision tied to the question that must remain answerable.