なぜ故障したZigbeeルーターがホームサーバーからデバイスの接続を切断することがあるのですか？

故障したZigbeeルーターは、単にラジオ範囲を拡張する以上の役割を果たしているため、特定のデバイスの接続を切断することがあります。メッシュの遠隔部分間でメッセージを中継したり、バッテリー駆動のエンドデバイスのメッセージを保持する親ノードとして機能したりします。これを失うと、経路や親子関係、またはその両方が切断される可能性があります。

ホームサーバーは故障中も正常に動作し続けることがあります。Home Assistant、Zigbee2MQTT、コーディネーターはオンラインのままで、モーションセンサー、接点センサー、スイッチが到達不能になることがあります。これらのデバイスが回復するかどうかは、残りのラジオトポロジーと各Zigbeeスタックのルート修復や再接続の処理に依存します。

故障したZigbeeルーターはメッシュ経路を切断し、ホームサーバー自体は壊しません

ローカルスマートホームサーバーはオートメーションプラットフォーム、インテグレーション、ダッシュボード、アプリケーションロジックを実行します。Zigbeeコーディネーターは1つのZigbeeネットワークを形成し、そのネットワークをホストに接続するラジオインターフェースです。ルーターは通常、メイン電源で動作する別のZigbeeノードで、トラフィックを中継し、コーディネーターの直接のラジオ範囲を超えてカバレッジを拡張できます。

Home Assistantの公式ZHAドキュメントは、コーディネーターのハードウェアをルーターおよびエンドデバイスの役割と区別しています。この区別により、選択的な症状が説明されます。故障したルーターはメッシュの一部の接続を切断しても、ホストをクラッシュさせたり、オートメーションソフトウェアを停止させたり、必ずしもコーディネーターをオフラインにするわけではありません。

コーディネーター、ルーター、エンドデバイスは故障の仕方が異なります

故障パターンはノードの役割に従います。コーディネーターはネットワークの中央ラジオインターフェースであり、ルーターはメッセージの中継に参加し、エンドデバイスは通常、他のノードのトラフィックを中継するのではなく親ノードを通じて通信します。これらの役割はオフラインデバイスリストを解釈する前に特定する必要があります。

この表はネットワークの役割を示しており、厳格な製品ルールではありません。主電源駆動の製品でもルーター役割を実装しない場合があり、実際の動作はファームウェアによって決まります。実際の問題は、デバイスがプラグや電球のように見えるかではなく、ネットワークがそれをルーターとして認識し、他のノードが現在それに依存しているかどうかです。

ルーティングデバイスは別の経路が存在する場合にのみ壊れた経路を修復できる

確認応答付きユニキャストメッセージが目的地に届かない場合、Zigbeeスタックは配信を再試行し、ルート修復を開始できます。Silicon Labsの公式Zigbeeルーティングドキュメントでは、修復を損傷したノードがもはや参加しない新しい探索プロセスとして説明しています。別のルーターの経路が到達可能であれば、ルーティングテーブルはその経路を使うよう更新できます。

したがって、自己修復は有効な接続を見つける試みであり、すべてのデバイスが即座に再接続することを保証するものではありません。故障したルーターが壁や階、長距離を越える唯一の利用可能なブリッジだった場合、メッシュは範囲外の無線機を経由する経路を計算できません。代替経路がない場合、スタックは配信失敗を報告します。

スリーピーエンドデバイスはルートだけでなく親も失うことがある

バッテリー駆動のZigbeeエンドデバイスは、動作サイクルのほとんどをスリープ状態で過ごすことがあります。スリープ中、親デバイスは起動したままで、受信メッセージをバッファリングし、定期的なデータポーリングに応答します。Silicon Labsはこの親ポーリングの関係を説明しています：子デバイスはメッセージを直接受信可能な状態を常に維持するのではなく、一つの親から保留中のメッセージを要求します。

その親機が故障した場合、通常のルーター間ルート修復だけでは子機との関係は回復しません。エンドデバイスはまず繰り返されるポーリング失敗を認識し、その後スタックが実装する再参加動作を開始する必要があります。準拠した実装は新しい適切な親機を探すことができますが、ポーリング間隔、再試行閾値、ファームウェアの動作、デバイスが次に起床するタイミングが回復の可視化速度に影響します。

冗長カバレッジが自己修復の成功を決定する

回復は「メッシュが自己修復する」という曖昧な表現にまとめやすい複数の条件に依存します。影響を受けた場所に無線カバレッジがまだあり、ネットワークが実用的なルートを形成でき、移動したエンドデバイスが新しい親機関係を確立できなければなりません。

影響を受けた場所から別のルーターに到達可能でなければならない

冗長性は、必要な場所に信頼できるリンクを持つ別のルーターが存在する場合にのみ成立します。コーディネーターの隣に2台のルーターがあっても、複数の厚い壁の向こうにいるセンサーへの2つの経路にはなりません。生き残ったノードは影響を受けた枝の実用的な無線経路内にあり、メッシュの残りの部分に接続されていなければなりません。

残っている親機は空きの子機テーブルエントリを持っていなければならない

親機および隣接テーブルは有限のメモリを使用します。直接の子機の正確な数は無線スタック、ファームウェア、デバイスの設定によって決まるため、すべてのコーディネーターやルーターに一律の子機制限を適用すべきではありません。到達可能なルーターでも、子機テーブルに使用可能なエントリがなかったり、リンクがスタックの選択基準を満たさなければ、新しい親機としては不適切です。

エンドデバイスは再接続を開始または完了しなければならない

スリーピーセンサーはすべて同じスケジュールでチェックインするわけではありません。頻繁に通信するものもあれば、測定値が変わるか定期レポートが必要になるまで沈黙を保つものもあります。影響を受けたデバイスがまだ再接続を完了してレポートを送信していないため、サーバーが新しいメッセージを受信していなくても、ネットワークには代替の親機が存在することがあります。

Zigbeeデバイスが利用不可に見えてもサーバーはオンラインのままでいられる

ダッシュボードの「利用不可」は、すべての無線リンクを常に直接測定した結果ではなく、観測された通信に基づくアプリケーションの判断です。デバイスはサーバーのタイムアウトが切れる前に親機を失うことがあるため、新しいコマンドやレポートが通らなくても、最後に知られている状態が表示されたままになることがあります。逆に、再起動後はデバイスが到達可能でも、再度チェックインするまでオフラインのまま表示されることもあります。

Zigbee2MQTTはアクティブデバイスとパッシブデバイスの利用可能性の動作を区別して文書化しています。アクティブデバイスはチェックインを逃した後にpingが可能ですが、パッシブなバッテリーデバイスはできず、より長いチェックインタイムアウトで判断されます。タイムアウトを延長することで早期のオフライン表示を防げますが、失敗したルートを再構築したり、孤立したセンサーに新しい親を与えたりはできません。

コーディネーターの故障とRF干渉はルーターの喪失を模倣することがある

オフラインのデバイスの集まりは共通の依存関係を示唆しますが、1台のルーターが故障した証明にはなりません。メッシュを変更する前に、障害の範囲、地理的位置、タイミングを比較してください。

コーディネーターの故障は通常、Zigbeeネットワーク全体に影響を及ぼす

オートメーションプラットフォームに接続できるがほぼすべてのZigbeeエンティティが同時に更新を停止した場合、コーディネーターとホストとの接続を調査してください。Home Assistantは、コーディネーターには安定したローカルシリアル接続が必要であり、不安定なシリアルからIPへの経路でのパケットロスや遅延が通信を妨げる可能性があると指摘しています。この障害境界は、単一の下流ルーターの喪失とは異なります。

2.4 GHzの干渉は複数のリンクを同時に劣化させる可能性がある

Zigbee、Wi-Fi、その他の無線は2.4 GHzのISM帯を共有できます。Silicon Labsの共存ガイドラインによると、同時運用は1つ以上のプロトコルの性能を低下させ、遅延や再試行を増加させる可能性があります。新しいアクセスポイント、Wi-Fiチャネルの変更、または不適切なコーディネーター配置により、ルーターの電源が切れていなくても複数のデバイスが不安定になることがあります。

複数のメイン電源デバイスの削除は冗長性を崩壊させる可能性がある

メンテナンスイベントで複数のルーターが一度に削除されることがあります。照明回路の電源を切る、スマートプラグのグループを抜く、機器を移動することで、主経路とバックアップの両方が失われる可能性があります。テスト中に1台のルーターが失われて回復したネットワークでも、近くの複数のルーティングノードが同時に消えると失敗することがあります。

障害パターンを使って失われたメッシュ依存関係を特定する

普遍的なリセット手順ではなく、相関関係から始めます。どのデバイスが報告を停止したか、いつ変化が起きたか、影響を受けたノードがコーディネーターから見て同じ部屋や物理的な方向にあるかを記録します。そのパターンを、同時に電源が切れたか移動されたメイン電源のZigbeeデバイスと比較します。

• 同時に更新が停止したデバイスを特定してください。
• 故障が部屋、階、または方向ごとに集中しているか確認してください。
• 電源が入っていなかったり、プラグが抜かれたり、取り外されたメイン電源のZigbeeルーターを探してください。
• ルーターの故障とバッテリーエンドデバイスの故障を区別してください。
• コーディネーターとそのホスト接続がまだ正常であることを確認してください。
• 配信失敗、再参加、または繰り返される可用性チェックのためにトポロジーとログを確認してください。

センサーを1つのルーター近くでペアリングしたからといって、その経路が永久に固定されるとは限らず、実際の通信損失を隠すために可用性タイマーを変更しないでください。カバレッジが制限要因であれば、弱い枝がある場所に信頼できる常時電源のルーティング容量を追加し、時間をかけてトポロジーを検証してください。ローカルの自動化ソフトウェアとホームサーバーサービスの広範な関係については、こちらのローカルスマートホームサーバーアーキテクチャ概要をご覧ください。

よくある質問

ルーターが故障した後、Zigbeeメッシュは常に自己修復しますか？

いいえ。ルート修復は使用可能な代替経路がある場合にのみ新しい経路を選択できます。スリーピーエンドデバイスは、失われた親を検出し、別の適切な親を通じて再参加する必要がある場合もあります。無線カバレッジ、テーブル容量、ファームウェアの動作、チェックインのタイミングが回復を妨げたり遅らせたりすることがあります。

Zigbeeルーターを増やせば常に切断を防げますか？

いいえ。追加のルーターは、信頼性があり、常に電源が供給され、適切に配置され、周囲のネットワークと互換性がある場合にのみ耐障害性を向上させます。コーディネーター近くにルーターが多くあっても、遠くのデッドゾーンへの保護はほとんど増えず、テーブルや干渉の問題はデバイス数だけでは解決しません。

利用不可タイムアウトを延長するとZigbeeデバイスが再接続しますか？

いいえ。タイムアウトはサーバーがデバイスをオフラインとラベル付けしたときに変わりますが、RFカバレッジを修復したり、新しいルートを発見したり、新しい親を確立したりはしません。長い値は静かなバッテリーセンサーの誤ったオフラインラベルを減らせますが、実際の障害の通知を遅らせることもあります。

ZigbeeルーターはWi-Fiルーターと同じですか？

いいえ。Zigbeeルーターは、Zigbeeメッシュ内のノードで、Zigbeeメッセージを中継し、エンドデバイスの親になることがあります。Wi-Fiルーターやアクセスポイントは異なるプロトコルとネットワークを提供します。両者は2.4 GHzの干渉を通じて影響し合うことがありますが、同じルーティングの役割を果たすわけではありません。