Home Assistantにおけるランタイム状態と永続状態:再起動後も維持すべきものは?

エヴァ・ウォンテクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

Home Assistantの「状態」は一つではありません。実行中のプロセスには、各エンティティが現在報告している内容を表すインメモリのState Machineが存在します。一方、永続的な設定とレジストリは、再起動後に何が存在すべきかを識別します。Recorderは過去の観測結果を保持し、選択されたエンティティプラットフォームは、後で値を復元できるように特定の値を保存できます。

したがって、信頼性の高いデプロイでは、メモリ上の一時的なオブジェクトをすべてシリアライズしようとはしません。永続的な真実の情報源を保持し、新しいプロセスがインテグレーション、レジストリ、復元された値、新たにデバイスから報告された情報からライブ状態を再構築できるようにします。

State Machineは現在の世界を実行時に表示するビュー

Home Assistant Coreは、State Machineで現在のエンティティ状態を保持し、それらの状態が変化したときにイベントを発行します。この現在のビューは、実行中のCoreプロセスに属します。

Coreアーキテクチャのドキュメントでは、State Machineを、現在の状態を追跡し、state_changedイベントを発生させるコンポーネントと説明しています。Event Bus、Service Registry、Timerは、その周囲で動作する実行時コンポーネントです。

再起動後、State Machineには再び状態が登録されます。そのため、デバイスがまだ再接続していない場合、過去の観測結果がRecorderに安全に保存されていても、そのデバイスは利用不可になることがあります。

エンティティレジストリが保持するのはライブなデバイス情報ではなく識別情報

Home Assistantは、インテグレーションが再接続するたびにユーザーのカスタマイズ、エンティティID、名前、エリア、その他の設定が消えないよう、再起動後も同じエンティティを認識する必要があります。

エンティティレジストリが存在するのは、Home Assistantがカスタマイズを保持し、既知のエンティティを追跡するために、再起動後も永続的なエンティティ識別情報を必要とするからです。ただし、レジストリのエントリがあるからといって、起動後の現在のセンサー値まで自動的に最新になるわけではありません。

識別情報とライブ値は別の記録だと考えてください。レジストリが答えるのは「これはどのエンティティか?」であり、インテグレーションが答えるのは「現在何を報告しているか?」です。

一部のエンティティ値は意図的に保存され、復元される

特にヘルパーや状態を持つソフトウェアエンティティなど、一部のエンティティは、新しい外部観測値が得られる前に以前の値を復元できると便利です。Home Assistantには、それらのエンティティ専用の永続状態チェックポイントがあります。

現在の永続状態を保存アクションの説明では、一部のエンティティは再起動後に最後の値を復元し、Home Assistantは通常、起動時、15分ごと、シャットダウン時にそれらの値をチェックポイントとして保存するとされています

これは選択的な永続化です。すべての物理デバイスの状態を永遠に正しい情報として扱うこととは異なります。復元された値は起動中に役立ちますが、利用可能になった時点でインテグレーションは新しいデバイスの真の状態に収束する必要があります。

Recorderの履歴が保持するのは実行中のプロセスではなく観測結果

Recorderは、履歴表示、分析、統計のために状態変更とイベントを保存します。そのデータベースは、Home Assistantの再起動を何度も経ても存続できますが、実行時のState Machineは再起動のたびに再作成されます。

「午後3時の気温はいくつだったか?」という履歴クエリは、履歴の永続化に属します。一方、「ドアは今開いているか?」と尋ねるライブオートメーションは、現在の実行時状態とインテグレーションの経路に依存します。

この違いにより、Recorderを削除または破損させると履歴が失われる可能性はありますが、必ずしもオートメーション、ユーザー、インテグレーション設定まで消えるわけではありません。一方、設定ディレクトリを失うと、古い履歴データベースが残っていても、識別情報やセットアップが失われる可能性があります。

デプロイでは、これらのレイヤーを再作成するファイルを永続化する必要がある

コンテナ化されたHome Assistantでは、もう一つ境界が加わります。実行時イメージは置き換えられる一方、設定マウントと外部依存関係はコンテナの外部で保持する必要があります。マウントには、Home Assistantの設定、レジストリストレージ、シークレットの参照、Recorderをローカルで使用している場合はデータベースも保持できるようにします。

Home Assistantの永続データの役割に関するZimaSpaceの記事では、復旧範囲について説明しています。実行時データと永続データの違いから、これらのファイルが重要な理由が分かります。これらは、次のプロセスが家庭内環境を再構築するための入力だからです。

状態の役割に合った永続化レイヤーを使う

状態の役割 保存場所 再起動後の動作
現在のエンティティ状態 実行時のState Machine インテグレーションや復元機能から再構築
エンティティの識別情報・カスタマイズ 永続レジストリ・設定 再度読み込まれる
復元対象として選択された値 永続状態チェックポイント 更新されるまで復元された状態が保持される
履歴・統計 Recorderデータベース 履歴データとして残る
インテグレーション接続・実行時オブジェクト プロセスメモリ 再作成され、再接続される
コンテナイメージ・実行環境 置き換え可能なデプロイレイヤー 永続データを中心に再作成できる

安全なルールは、識別情報、設定、復旧データ、そしてHome Assistantが意図的に永続的なものとして扱う状態を保存することです。一時的な実行時状態は再構築に任せます。そうすることで、メモリ上のすべての値が変更されずに存続すべきだと考えるよりも、再起動を明確にモデル化できます。

テック&AIハブ

もっと読む

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.