Home Assistantコンテナを再起動すると、永続的な設定が完全に保持されていても、システムの表示が一時的に変わることがあります。これは、実行中のインスタンスがディスク上の永続状態と、メモリ内の一時的な実行時状態の両方を保持しているためです。コンテナを再起動すると後者が破棄され、インテグレーションは状態を再構築する必要があります。
そのため、エンティティが一時的にunknownやunavailableになったり、保持メッセージが届くとMQTTデバイスがすぐに再表示されたり、再試行が成功するまで外部サービスが見つからない状態になったりします。再起動とは、同じメモリ内プロセスを単に一時停止して再開するのではなく、状態を再構築するイベントなのです。
コンテナの実行環境は置き換え可能であり、/configが永続的な境界となる
Home Assistant Containerは通常、設定のマウントを維持したままコンテナイメージを再作成して運用します。永続パスが正しく接続されていれば、イメージの更新、実行環境の変更、プロセスの再起動を行っても、家庭内の環境を最初から構築し直す必要はありません。
バージョンを変更する際は、現在のHome Assistant Containerの手順で、コンテナを明示的に再作成します。このモデルが機能するのは、アプリケーションの状態が使い捨ての実行環境の外部に保存されることを前提としているためです。
プロセスメモリにしか存在しないものは、再起動時にすべて失われます。次のプロセスは、同じライブ表示を再構築する前に、設定、レジストリ、データベース、インテグレーションの入力を読み直す必要があります。
Coreは新しい実行時ステートマシンを開始する
起動するたびに、Home Assistantは新しいイベントループ、ステートマシン、サービス、タイマー、インテグレーションの実行時オブジェクトを備えた新しいCoreプロセスを構築します。エンティティレジストリによって既知のエンティティを識別できますが、物理デバイスの現在値は、復元、取得、または報告される必要があります。
Recorderも、Home Assistantが起動するたびに新しいRecorderの実行を開始します。過去のデータベース行は保持されますが、現在のプロセスは以前の実行の継続ではなく、新しい実行時区間です。
この違いは、再起動前後のログやデータベースのタイムスタンプを比較する際に重要です。履歴レコードは、Home Assistantが以前に観測した内容を示しますが、新しいプロセスがライブデバイスへの接続をすでに再確立したことを自動的に証明するものではありません。
インテグレーションは異なる速度で実行時状態を再構築する
ローカルデバイスにすぐ再接続するインテグレーションもあれば、DNS、ブローカー、クラウドAPI、無線ブリッジ、別のコンテナなどを待つものもあります。そのため、Home Assistant Core自体がすでに起動していても、エンティティが利用可能になるタイミングは異なります。
Home Assistantの現在のセットアップ失敗モデルでは、一時的に利用できないインテグレーションは、デバイスやサービスが到達可能になったときに復旧できるよう、再試行経路に入る必要があります。そのため、再起動後の表示状態が数分にわたって変化しても、永続データが変更されたことを意味するとは限りません。
すべての依存先がすでに稼働している状態で2回目の再起動を行うと、ネットワーク、ブローカー、データベース、デバイスが同時に状態を収束させる必要がないため、スタック全体の再起動よりもはるかに高速に見えることがあります。
MQTTでは状態の再構築が特にわかりやすい
MQTTが適した例となるのは、ブローカーがHome Assistantプロセスとは独立して、ディスカバリーメッセージや状態メッセージを保持できるためです。Home Assistantが再接続すると、保持データが再送され、エンティティは最後に報告された値をすぐに取り戻せる場合があります。
MQTTインテグレーションのドキュメントでは、検出されたエンティティは、再起動後にディスカバリー処理が完了するまで利用できない一方、保持されたディスカバリーや状態のメッセージは、サブスクリプションの再構築に伴って再送される可能性があると説明されています。Home AssistantはBirthメッセージも送信し、デバイスはそれを利用してディスカバリー情報や最新の状態を再送できます。
保持値はあくまで最後に確認された報告値であり、物理デバイスが現在到達可能であることを証明するものではありません。可用性トピックと最新のテレメトリは、別々に評価する必要があります。
再起動時の動作は、情報源がどこにあるかによって異なる
- 永続的な設定とレジストリ: Home Assistantの永続ストレージから読み直されます。
- 現在のデバイス状態: 多くの場合、インテグレーションによって再取得または再報告されます。
- MQTTの状態: 保持メッセージまたは新たなパブリッシュによって再構築される場合があります。
- クラウド依存の状態: リモートAPIへの接続と認証情報に左右されます。
- 過去の状態: Recorderに保持されますが、ライブ状態とは異なります。
- 純粋な実行時オブジェクト: 新しいHome Assistantプロセスによって再作成されます。
ZimaSpaceの再起動後のMQTT状態に関する解説では、具体的な再構築経路の1つを紹介しています。より一般的な原則として、再起動時の動作は、各コンポーネントの情報源がどこに存在するかによって決まります。
よくある質問
Home Assistantコンテナを再起動すると履歴は削除されますか?
永続的な設定とRecorderデータベースが正しくマウントされていれば、削除されません。再起動によって置き換えられるのは実行時プロセスであり、過去のデータは永続データベースに残ります。
再起動直後にエンティティが以前の値を表示することがあるのはなぜですか?
その値は、Home Assistantの復元機能、インテグレーションのキャッシュ、保持されたMQTT状態、またはデバイスへの即時ポーリングから取得された可能性があります。表示された値を物理デバイスからの最新の読み取り値とみなす前に、インテグレーションと可用性の経路を確認してください。
テック&AIハブ
もっと読む

Home Assistantにおけるランタイム状態と永続状態:再起動後も維持すべきものは?
Home Assistantはすべてのライブ値を永続化するわけではありません。設定、レジストリ、選択された復元状態、履歴、デプロイデータは、再起動時にそれぞれ異なる役割を果たします。

Home Assistantはローカルセッションとリモートセッションをどのように認証しますか?
ローカルおよびリモートのHome Assistantセッションでは、同じサーバー側のIDモデルを使用します。リモートアクセスによって変わるのは経路とTLSの境界であり、トークンフローの中核ではありません。

Recorderデータが増えると、なぜHome Assistantの履歴クエリは遅くなるのですか?
レコーダーの成長に伴い、要求された範囲に含まれる行数が増えたり、キャッシュミスが増加したり、ストレージやインデックス処理が遅くなったりすると、履歴クエリのコストが上昇する可能性があります。

