Home Assistantで温湿度、電力、在宅、照明、通知の履歴を見られるようにしていくと、ダッシュボードは賑やかになります。一方で、データベースとバックアップは静かに重くなっていきます。「とりあえず全部残しておけば安心」という設計のまま運用していると、ストレージ消費が増え、バックアップが肥大化し、いざ復元というときの再開が遅くなる方向に進みがちです。
この記事は、センサーや機器を追加する前に、何を記録し、何を除外し、何日残すかという保持設計を先に決めるための判断材料を整理するものです。便利なダッシュボードの作り方ではなく、後で判断に使う履歴と、残しても読まない履歴を分ける考え方を扱います。
Home Assistantの履歴は全部残すほど安全、とは限りません
Home Assistantで履歴を支えているのはRecorder統合です。Recorderはイベントと状態(state)の履歴をデータベースに保存する役割を持ちます。History統合などの履歴表示は、このRecorderが保存したデータに依存しています。つまり「履歴を見られる」状態は、裏側で「履歴を書き続けている」状態でもあります。
ここで重要なのは、Recorderには既定で古いデータを自動的に整理(パージ)する仕組みがあるという点です。保持期間は設定オプション purge_keep_days で指定し、既定値は10日です。既定のままなら、10日より古い状態履歴は保持対象から外れ、定期的に削除されていきます。
なお、自動パージが実行される具体的な時刻などの細部は、お使いのバージョンによって挙動が異なる場合があるため、運用前に公式ドキュメントの最新記述で確認することをおすすめします。
この「既定10日」という値は、たいていの読者がイメージする「履歴」よりも短いはずです。だからこそ、増やす前に「自分は何日分を、何のために見たいのか」を決めておく価値があります。
Recorderは何を記録し、何を除外できるのか
Recorderは include / exclude によって記録対象を絞り込めます。指定できるのはドメイン、個別エンティティ、entity_globs(パターン指定)、イベントタイプです。
includeは「記録するものだけを限定する」方向の指定です。excludeは「記録対象から外す」方向の指定です。
どちらを主軸にするかは設計思想の違いです。最初に記録したいものが明確なら include で絞る、まず全体を記録しつつ不要なものを落としていくなら exclude で削る、という使い分けになります。
除外候補にしやすいのは、頻繁に値が変わるのに、後から見返す目的が薄いエンティティです。たとえば短い間隔で更新され続ける一方で、長期の比較に使う予定がない種類のものです。ただし、何が不要かは読者の分析目的によって変わるため、ここで一律に「このエンティティは外すべき」と断定はしません。判断軸は「後で見るか」「比較に使うか」です。
通常の履歴と長期統計(long-term statistics)は別物
もう一つ押さえておきたいのが、通常の状態履歴と長期統計(long-term statistics)の違いです。
Home Assistantは、適切な state_class を持つセンサーについて長期統計を保持します。これは通常の状態履歴とは別に扱われ、Recorderの履歴パージ(purge_keep_days)では削除されず、長期的に保持される性質があります。
これは設計上ありがたい挙動です。温度や電力量のように「細かい1回ごとの値は数日分でよいが、傾向は長く見たい」データは、短期の状態履歴を短めの保持期間で軽く保ちつつ、長期統計側で傾向を追える可能性があります。
ただし、短期統計(細かい粒度の集計)の保持挙動や、長期統計へ集約されるタイミングの厳密な日数は、お使いのバージョンで差が出ることがあります。長期グラフを前提に保持期間を短くする設計を採る場合は、Recorder/Statistics の公式ドキュメントの最新版で、対象センサーが本当に長期統計の対象になっているかを必ず確認してください。
保持期間とバックアップ・復元の関係
保持設計はストレージだけの話ではありません。Home Assistantのバックアップには、設定とともにデータベースが含まれ得ます。つまり、記録される履歴データの量は、バックアップのサイズや扱いに影響します。
履歴を全部・長期間残す運用は、データベースが大きくなりやすく、その分バックアップも大きくなりやすい方向です。一般論として、データベースが大きいほど復元時の再開も時間がかかりやすいと想定されます。
ただし、センサー数や更新頻度ごとに「データベースが何MB増えるか」「復元に何分かかるか」といった数値は環境に強く依存するため、本記事では具体的な数値を断定しません。これらは実測で把握すべき項目です。重要なのは、「保持期間と記録対象を決めること=バックアップと復元のしやすさを決めること」だと理解しておくことです。
3つの運用パターンを目的別に比較する
保持設計の選択肢は、おおまかに次の3パターンに整理できます。読者の「後で何を見たいか」によって適した形が変わります。
| 運用パターン | 向いている目的 | 保持・記録の考え方 | ストレージ/バックアップ傾向 | 注意点 |
|---|---|---|---|---|
| 全エンティティを記録 | まだ何を見たいか決まっておらず、取りこぼしを避けたい | 既定に近い形で広く記録 | 大きくなりやすい | データベース・バックアップ肥大化、復元の遅さに注意 |
| 重要センサーだけ長めに残す | 残すデータと目的が見えている | include/exclude で対象を絞り、必要なものは保持を確保 | 中程度に抑えやすい | 後から「やはり見たい」が出たとき、過去分は遡れない |
| 短期はHA・長期は別系統 | 長期の傾向分析をしっかり行いたい | HA側は短めに、傾向は長期統計や外部に寄せる | HA側は軽く保てる | 設計と運用がやや複雑、対象が長期統計の対象か要確認 |
なお、Recorderの既定データベースはHome Assistant設定ディレクトリ内のSQLiteファイル(home-assistant_v2.db)ですが、MariaDB/MySQLやPostgreSQLなど外部データベースへ変更することもできます。長期・大量の履歴を扱う場合は、データベースの置き場所も選択肢に入ります。
センサーを増やす前に決めておくこと(チェックリスト)
- このエンティティの履歴は「後で見るか」「比較に使うか」を一言で言えるか。
purge_keep_daysを既定の10日のままにするか、目的に合わせて変えるか。- include で絞るか、exclude で削るか、設計の主軸を決めたか。
- 長く傾向を見たいセンサーは、長期統計の対象になっているか(最新ドキュメントで確認)。
- 現状のデータベースサイズとバックアップサイズを把握しているか(数値は自環境で実測)。
まとめ
Home Assistantの履歴は、増やすほど安全になるわけではありません。Recorderは既定で10日を超えた状態履歴を自動的に整理し、include/exclude で記録対象を絞れます。通常履歴と長期統計は別扱いで、長期統計はパージの対象外として保持される性質があります。そして記録量はバックアップと復元のしやすさに直結します。
ですので、答えは「全部残す」でも「とにかく消す」でもありません。後で判断に使う履歴を見極め、記録対象と保持期間を先に決める——センサーを追加するのは、その設計を決めてからで十分間に合います。容量や復元時間の数値、パージの実行時刻、統計の厳密な保持日数は環境とバージョンに依存するため、実際の運用では自環境での実測と公式ドキュメントの最新版での確認を併用してください。
