なぜMQTTメッセージは再起動後にスマートホームサーバーの状態を変えるのですか？

エヴァ・ウォン

IceWhale author

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

Why Do MQTT Messages Change Smart Home Server State After Reboot? - Zima Store Online

MQTTメッセージは、再起動後にスマートホームサーバーの状態を変えることがあります。これは、再接続したサブスクライバーが保持されたメッセージ、キューに入ったメッセージ、ディスカバリー、可用性の更新を受け取るためです。

この変化は通常、デバイスがランダムに動作しているわけではありません。再起動はオートメーションクライアントを再起動し、サブスクリプションを再構築し、ローカルデータベースを復元し、トピック状態やオフラインメッセージを保持している可能性のあるブローカーに再接続します。デバイスやゲートウェイも、サーバーの復帰に反応してディスカバリーレコード、オンライン状態、新しいセンサー値を公開することがあります。以下のセクションでは、これらのメッセージ経路を分けて説明し、起動直後にスイッチ、センサー、または可用性フラグが異なって見える理由を理解できるようにしています。

再起動は新しいサブスクリプションのタイムラインを作成する

再起動前、スマートホームサーバーはすでにアクティブなMQTTサブスクリプションとデバイス状態のインメモリビューを持っています。シャットダウン中、そのライブ接続は消え、サーバーは一時的にMQTTエンティティを利用不可とマークしたり、自身のデータベースから復元した状態にフォールバックしたりします。

起動後、クライアントは新しいブローカー接続を作成し、サブスクリプションを復元または再作成し、再びメッセージの受信を開始します。データベースの復元、統合セットアップ、サブスクリプション、デバイスの公開が完了する順序によって、最初に表示される状態が決まります。

つまり、起動時の状態は一つの権威あるスナップショットから読み取られるのではなく、複数のソースから組み立てられます。データベースの値が一時的に表示され、その後ブローカーのメッセージに置き換えられ、さらに物理デバイスがライブ更新を公開すると再度変わることがあります。

保持メッセージはトピックの最後の値を再生する

保持された公開は、ブローカーにそのトピックの最新の保持ペイロードを保持するよう指示します。再起動したスマートホームサーバーが再度サブスクライブすると、ブローカーはデバイスの次の通常の更新を待つことなく、そのペイロードを即座に配信できます。

これらの保持メッセージは、ゆっくり変化するセンサーや可用性トピックに便利ですが、保持された最後の値を示すものであり、再起動後に物理的な状態が検証された証明ではありません。古い保持コマンドやセンサー値が、より慎重に復元された状態を上書きすることがあります。

Home Assistantも、状態トピックの保持ペイロードはサブスクリプション後に再生され、エンティティ状態を復元できると文書化しています。保持トピックが有効なままであれば、この目に見える変化は期待されるプロトコルの動作です。

永続セッションはオフライン中に見逃した更新を配信できる

保持状態とセッションの永続性は異なる問題を解決します。保持トピックは一致するサブスクライバーに対して最後の値を一つ保存しますが、永続セッションは特定のクライアントのサブスクリプションを保持し、切断中に該当するメッセージをキューに入れます。

永続セッションでは、再起動期間中に公開されたQoS 1または2の更新がサーバー復帰時に配信されることがあります。再起動したオートメーションプラットフォームは、トピックの最終保持値だけでなく、オフライン中に発生したイベントも処理できます。

これにより、起動後に短時間の状態変化の連続が発生することがあります。もしオートメーションが回復したすべてのイベントをライブトリガーとして扱うと、ペイロードにタイムスタンプ、シーケンス番号、または有効期限ルールが含まれていない限り、もはや有用でないアクションを再生してしまうかもしれません。

MQTT 5のセッションおよびメッセージの有効期限設定は、キューや保持データの有効期間を制限できます。アプリケーションレベルの鮮度チェックがなければ、信頼性の高い配信は古いイベントを現在のものと同様に保持してしまう可能性があります。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

ディスカバリー、バース、ウィルトピックは可用性を再構築する

一部のMQTT統合はセンサー値の復元以上のことを行います。ディスカバリーメッセージを使ってエンティティ構成を再作成し、バースや可用性の公開でオートメーションサーバー、ゲートウェイ、またはデバイスがオンラインかどうかを通知します。

Home AssistantのMQTTディスカバリーは、再起動後に保持された構成および状態トピックを再生できます。デバイスはサーバーのバースメッセージを検知すると構成を再公開し、エンティティと状態の更新の波を生み出すこともあります。

ラストウィルメッセージは逆の遷移をカバーします。クライアントが予期せず切断された場合、ブローカーは事前定義されたオフラインペイロードを公開できます。ウィルとオンラインメッセージが保持されている場合、再起動したサブスクライバーは最初に保存されたオフライン状態を見てから、デバイスの新しいオンライン状態を見ることがあります。

ブローカーパースィステンスがブローカー再起動後の状態を決定する

スマートホームサーバーの再起動とMQTTブローカーの再起動は同じイベントではありません。オートメーションサーバーだけが再起動した場合、ブローカーは保持ツリーやセッションキューを維持したままオンラインのままでいることがあります。ブローカーも再起動した場合、そのストレージ設定が何が残るかを決定します。

保持データはメモリまたはディスクに保存されることがあり、ブローカーパースィステンスはブローカープロセス復帰後に保持セットが利用可能かどうかを決めます。コンテナのボリュームマッピング、権限、正常シャットダウンの動作、ブローカー設定が起動結果を変えることがあります。

ブローカー再起動後に保持トピックが消えると、デバイスが再度公開するまでエンティティは不明のままになることがあります。古い保持トピックが無期限に残ると、削除されたデバイスや古い構成が新しいサブスクライバー接続時に再び現れることがあります。

どのメッセージが新しい状態を実際に設定したかを追跡する

変化を診断するには、再起動前のエンティティ状態を記録し、クライアントが再接続した瞬間からMQTTトラフィックをキャプチャします。トピック、ペイロード、保持フラグ、QoS、タイムスタンプ、発行者の識別、メッセージがディスカバリー完了前後のどちらで届いたかを記録してください。

重要な証拠は再生された状態であり、最終的なダッシュボードの値だけではありません。保持ペイロードはトピック状態を示し、キューに入ったQoSメッセージはセッション回復を示し、新しいデバイス公開はライブ再構築を示します。

ZimaSpaceの広範なアーキテクチャは、Home Assistant、MQTT、ストレージ、カメラ、AIを別々のサービスに分けているため、それぞれの再起動動作が理解しやすくなっています。そのMQTTサービス境界により、ブローカー、コントローラー、デバイスのどれが状態遷移を引き起こしたかを特定しやすくなっています。

原因が判明したら、起動時のメッセージを無差別に抑制するのではなく、データ契約を修正してください。保持メッセージは耐久性のある現在の状態に使い、有効期限は時間に敏感なデータに使い、ディスカバリーには安定したユニークIDを使い、再生してはならないイベントにはタイムスタンプやシーケンスルールを使いましょう。