家全体の制御中にHome Assistantのメタデータと履歴が増加する原因は何ですか？

Home Assistantの「メタデータの増加」は、同じインストール環境の周辺に複数の異なるデータクラスが存在するため、誤って診断しやすい問題です。デバイスレジストリとエンティティレジストリは、識別情報や設定上の関係を保持します。設定ツリーにはUIで管理される状態が保存されます。Recorderには、はるかに大容量の状態変化とイベントの時系列データが保存されます。長期統計には、未加工の履歴保持期間を超えて、選択した集計データが保存されます。

家全体の制御を導入すると、これらのレイヤーはそれぞれ異なる形で増加します。デバイスを追加するとレジストリは緩やかに増加しますが、高頻度センサーや属性の多いエンティティを追加すると、データベースは急速に大きくなる可能性があります。保持期間を変更したりファイルを削除したりする前に、実際に増加しているレイヤーを特定してください。

エンティティレジストリとデバイスレジストリは管理対象オブジェクトに応じて増加する

Home Assistantは、再起動後もエンティティの識別情報、ユーザーによるカスタマイズ、デバイスとの関係、エリアの割り当て、インテグレーションの所有関係を維持できるよう、永続的なレジストリレコードを保持します。このメタデータは、すべてのセンサー履歴サンプルと同じものではありません。

現在のデバイスレジストリモデルでは、デバイスが設定エントリや、その機能を表すエンティティとの関係をどのように維持するかが説明されています。家にインテグレーション、ブリッジ、子デバイス、エンティティを追加すると、このレジストリは自然に複雑になります。

レジストリの増加は、通常Recorderと比べれば緩やかです。1,000個のエンティティ定義は運用上重要ですが、それぞれが1,000件もの履歴レコードを生成すれば、ストレージの大部分を占める可能性があります。

Recorderの増加を左右するのはデバイス数だけでなく変化率

Recorderは状態の変化と選択されたイベントを記録します。1日に2回変化するドアセンサーは、ダッシュボード上ではどちらも1つのエンティティですが、数秒ごとにレポートする電力センサーよりも容量を消費しない場合があります。

2026年のチューニング事例では、Home Assistantのデータベースが6日間で963 MBに達しましたが、ノイズの多いエンティティを除外することで、1日の増加量が約160 MBから50 MB未満に減少しました。正確な数値はインストール環境によって異なりますが、仕組みは同じです。

全体の保持期間を短縮する前に、1日あたりのデータベース増加量を測定し、最も多くのレコードを作成しているエンティティやドメインを順位付けしてください。家庭で実際に利用している履歴は保持しましょう。

属性によって、表示される状態から想像する以上のストレージが追加されることがある

エンティティにはon、23.4、homeのような短い状態が表示されていても、デバイスの詳細、予測、リスト、座標、診断メタデータなど、はるかに大きな属性セットが含まれている場合があります。

現在のHome Assistant開発者向けガイダンスでは、状態が頻繁に変化するエンティティでは、extra_state_attributesも頻繁に変化するとデータベースが急速に増加する可能性があると明確に警告しています。推奨される対策は、重要でない属性を最小限にするか、独立したセンサーエンティティとして公開することです。

ストレージ使用量を、表示されるエンティティの状態だけから見積もらないでください。特に大規模なJSON形式に近い構造を公開するインテグレーションでは、状態の頻度と属性の変化量の両方を確認しましょう。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

統計データは、長期保持において異なる曲線を描く

未加工の履歴は通常、保持期間によって制限されますが、長期統計では、選択したセンサーの集計データをはるかに長く保持できます。これは、エネルギー、温度、光熱費などの傾向を確認する際に便利です。月単位の問いに答えるために、すべての未加工サンプルを保持する必要がなくなるからです。

つまり、古い未加工の状態を削除しても、すべての履歴データが必ず削除されるわけではありません。これは意図された動作です。最近のトラブルシューティング用履歴と、長期的な分析用履歴は、別々の保持対象として扱いましょう。

ZimaSpaceのセンサー保持モデルは、サンプル頻度、インデックス、ロールアップ、バックアップ世代を、センサーあたりのバイト数だけに単純化せず、それぞれ個別に測定する必要がある理由を示しています。

バックアップは、ライブシステムが保持するデータ量をさらに増幅する

Recorderデータベースが大きくなると、バックアップサイズと復元時間も増加します。保持するバックアップが複数ある場合、特に各アーカイブが完全なコピーを含むと、現在稼働中のデータベース以上の容量を消費する可能性があります。

コミュニティのRecorderガイドでは、更新頻度の高いエンティティと大きな属性が、Home Assistantデータベースが増え続ける一般的な原因であると説明されています。

ライブ履歴とバックアップの両方に保持期間を設定してください。稼働中のデータベースを小さくしても、古い変更不能なバックアップアーカイブは、そのバックアップの有効期限が切れるまで容量を解放しません。

何かを削除する前にデータの役割を監査する

次の4つを別々に確認してください。古いデバイスレコードやエンティティレコードが蓄積していないか。未加工のRecorderデータで最も多くの変化を生み出しているエンティティはどれか。どのセンサーに長期統計が本当に必要か。そして、完全なバックアップ世代がいくつあり、ライブデータの容量を何倍にしているかです。

有用なデバイス、履歴、分析データに対応し、計画したメンテナンスと復旧の範囲内に収まっているなら、データの増加は健全です。一方、少数のノイズの多いエンティティ、古いレジストリ、不要なバックアップ世代が容量の大半を消費している場合は問題になります。

FAQ

Home AssistantのメタデータはRecorderの履歴と同じですか？

いいえ。レジストリと設定メタデータは、デバイス、エンティティ、インテグレーション、UIで管理される状態を記述します。Recorderの履歴は状態変化とイベントの時系列データで、通常はこちらのほうがはるかに大きなストレージレイヤーです。

デバイスを追加すると、必ずデータベースが急速に大きくなりますか？

いいえ。デバイス数だけでなく、変化率がより重要です。少数の高頻度エンティティや属性の多いエンティティが、多数の低活動のスイッチや接触センサーより多くの履歴を生成する場合があります。