再起動後にHome Assistantの安定したローカル制御が失われるのはなぜですか？

エヴァ・ウォン

IceWhale author

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

Why Does Home Assistant Lose Reliable Local Control After a Restart? - Zima Store Online

再起動後にHome Assistantが「起動している」ように見えても、信頼できるローカル制御がまだ完全に復旧していないことがあります。すべてのインテグレーション、無線通信、オートメーション、ヘルパー、データベースパス、デバイス接続が使用可能な状態に戻る前に、Webインターフェースが読み込まれる場合があります。

再起動を1つの出来事としてではなく、一連の流れとして診断しましょう。Home Assistantが実行状態に到達したことを確認し、まだ読み込み中または利用できないインテグレーションを特定し、永続状態が正しく復元されたことを確認してから、ローカルのセンサーからアクションまでの経路を1つテストします。同じオートメーションが手動で再読み込みした後や2回目の再起動後に動作する場合、恒久的な設定不良よりも、起動順序や依存関係の準備完了が原因である可能性が高くなります。

起動が実際に完了したことを確認する

まず、すべてのオートメーションをすぐに切り替えるのではなく、ログとインテグレーションの状態を確認します。コンテナのプロセスが実行中でも、Home Assistantがエンティティを復元中だったり、インテグレーションに接続中だったり、Recorderを開いていたり、無線コーディネーターを待機していたりすることがあります。

最近のHome Assistantの起動問題では、ZHAインテグレーションによってブートストラップが遅延し、再起動後もYAMLオートメーションのエンティティが利用できない状態になりました。これはZHA全般が安全でないという意味ではありません。「UIが開いた」ことだけでは、オートメーション実行環境全体の準備が整った証拠にならないことを示しています。

Home Assistantが通常動作を報告した最初の時刻を記録し、重要なエンティティが利用可能になった時刻と比較します。特定のインテグレーションが常に最後に復旧する依存関係であるなら、関係のないオートメーションロジックを変更する前に、まずそこを調査してください。

オートメーションが実際に必要とする依存関係を待つ

モーションライトのオートメーションには、モーションセンサーのインテグレーション、対象のライトのインテグレーション、ローカルネットワークまたは無線コーディネーター、条件で使用するヘルパーエンティティなどが必要になる場合があります。依存関係が1つでも利用できないと、Home Assistant Coreが正常でも、オートメーションが不安定に見えることがあります。

このタイミングの境界は、標準のオートメーションエンジン以外の実際のインテグレーションにも見られます。Home Assistantコミュニティの議論では、WebSocketクライアントがHome Assistantの完全な起動前に接続できるため、実行状態になるまで待つことで、エンティティの読み込み中にコマンドを送信することを避けられると説明されています。

これを解決するために、あらゆる場所へ30秒や60秒の任意の遅延を追加しないでください。まずどの依存関係が遅れているのかを確認し、準備完了を本当に必要とする起動ワークフローだけを制御します。

オートメーションの状態とデバイスの状態を分けて考える

Home Assistantは再起動後も多くの状態を復元しますが、エンティティに復元された値が、物理デバイスから新たに確認された状態と同じとは限りません。インテグレーションが再接続中でも、スイッチに一時的に以前の値が表示されることがあります。

再起動後にエンティティがunavailableになる場合、問題の経路が判明する前にエンティティを削除したり再ペアリングしたりしないでください。最新のトラブルシューティングガイドでは、デバイスをリセットする前に、到達性、アドレス設定、検出、ブローカー、無線通信、インテグレーションのログを確認することが推奨されています。これにより、再起動の問題がより大きな再設定の問題へ発展するのを防げます。

重要なオートメーションごとに、再起動後のトリガーエンティティが復元済み、未知、利用不可、または再起動後に新しく更新された状態のどれなのかを記録します。この違いから、失敗が状態の復元、インテグレーションの再接続、オートメーション自体のどこで発生しているかが分かります。

Featured

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

ZimaCube2

WANなしでローカル制御経路をテストする

起動中にローカルDNS、MQTT、Wi-Fi、リバースプロキシ、またはベンダークラウドのインテグレーションも状態を変えると、再起動の問題がインターネットの問題と混同されることがあります。パブリックインターネットに依存しない、シンプルなローカル制御テストを1つ用意しておきましょう。

たとえば、Zigbeeモーションセンサーでローカルライトを点灯させる経路や、ローカルボタンでリレーを切り替える経路を使います。その経路が動作する一方でクラウド接続のデバイスが動作しない場合、Home Assistantのローカル制御は機能しており、残りの問題はリモート依存関係にあります。

オプションのインターネットサービスから重要な家庭内経路を分離するうえで、ローカル制御と復旧の境界を明確にしたローカルオートメーションハブの構築に関するZimaSpaceガイドが参考になります。

繰り返し推測する代わりに、再起動受け入れテストを使う

確認項目	合格条件	考えられる原因箇所
Coreの起動	継続的なセットアップエラーなしでシステムが実行状態に到達する	Core、設定、カスタムインテグレーション
重要なインテグレーション	必要なエンティティが利用可能になる	無線通信、デバイス、LAN、インテグレーション
状態の復元	ヘルパーと期待される永続状態が正しく戻る	状態の復元、ストレージ、シャットダウンの品質
ローカルオートメーション	既知のトリガーによって期待どおりのローカルアクションが実行される	オートメーション経路または依存関係
2回目の再起動	手動で切り替えなくても同じテストに再度合格する	一貫しない場合は起動順序

失敗した最小の層を修正します。エンティティが見つからない場合は1つのインテグレーションを再読み込みまたは修復し、復元された値が間違っている場合は状態またはストレージを修復し、依存関係が明らかに遅れている場合にのみ起動順序を変更します。永続設定が信頼でき、失敗が1つの起動経路で再現するなら、Home Assistantを再構築する必要はありません。