Bluetooth Meshの配網は成功したのに、なぜ照明を操作できない？

スキャン一覧に機器が現れ、「追加」を押すとProvisioning成功のログが出る。ゲートウェイにも新しい項目が増え、作業は終わったように見えます。

ところが点灯コマンドを送っても、照明は反応しません。

電波やチップの互換性、シリアル通信を疑う前に、確認したいことがあります。ネットワークへ参加したことと、アプリケーションで使える設定が整ったことは別です。

前回は独自の広告通信をマルチホップ化する話でした。今回は標準に戻り、照明を一台追加する例で、発見、Provisioning、鍵、モデルバインド、発行と購読をつなげます。仕組みの説明であり、実機試験の結果や特定チップのシリアル手順ではありません。

発見できても、接続待ちと分かっただけ

未参加の機器はUnprovisioned Device Beaconを送信し、配網可能であることを知らせられます。スマートフォンやゲートウェイが発見し、Provisionerの役割を担う側が処理を始めます。

Provisionerは役割であり、必ずスマートフォンである必要も、常にゲートウェイと一体である必要もありません。一つのアプリに配網、設定、通常操作をまとめることはできますが、理解する際には責務を分けると見通しがよくなります。

広告を受信しただけでは、目的の照明だとは確認できません。接続には対象の確認と適切な安全手順が必要です。同じ照明が何台もあるなら、ボタン、製品に付属する情報、対応する入出力手段などで選べるようにします。同名の一覧が現場に並んでから考えるのでは遅いでしょう。

Provisioningで得るのはネットワーク上の身元

Provisioningは単にパスワードを書き込む処理ではありません。

双方が能力を交換し、対応する認証方法を選び、公開鍵に関する交換と認証を経て、参加に必要な状態を安全に確立します。入出力能力、認証方法、実装が関係し、通信の暗号化だけでは接続相手の確認を代替できません。

完了した機器は、初期NetKey、IV Index、割り当てられたユニキャストアドレスなどを持つノードとなり、DevKeyも確立します。DevKeyは双方で個別に導出され、平文の設定値として無線送信されるものではありません。 共有NetKeyとは役割が異なります。

ここではまだ、照明に使うAppKey、コマンドを受けるモデル、受信するグループの設定が済んでいない場合があります。画面には「参加済み・設定待ち」と表示したいところです。「追加成功・利用可能」とは区別します。

三種類の鍵を混同しない

鍵	主な役割	意味しないこと
NetKey	ネットワーク／サブネットの保護とネットワーク層の処理	全アプリケーションの内容を読めること
AppKey	モデルバインドと組み合わせたアプリメッセージの保護	保存しただけで全モデルが使用できること
DevKey	そのノードへの設定通信の保護	照明グループで共有する日常操作用の鍵

廊下の照明が他の機器の通信を中継する場合、ネットワーク層の処理は必要でも、すべての業務データを読める必要はありません。NetKeyとAppKeyの分離は、運ぶことと理解することを分けます。中継できても、コマンドを実行する権限やモデルがある証拠にはなりません。

ログのAppKey Indexは索引であり、鍵そのものではありません。同じ番号が表示されても、鍵の値や文脈まで一致するとは限りません。信頼できる設定記録で対応を確認し、実際の鍵を通常ログやスクリーンショットへ出さないようにします。

アドレスを推測する前に構成を読む

Configuration ClientがノードのConfiguration Serverと通信し、設定を読み書きします。Composition Dataにはエレメント、実装モデル、関連する能力が記載されています。

ノード、エレメント、モデルは別の階層です。 一つの筐体に複数のエレメントがあり、それぞれ複数のモデルを持つ場合があります。

多チャンネル機器の全機能がプライマリエレメントにあるとは限りません。主アドレスとOnOffコマンドだけですべての出力を操作できるとも限らず、実際の構成を確認します。アドレス割り当てもエレメント用の領域を確保し、別ノードとの重複を防ぎます。

この例では照明のエレメントとGeneric OnOff Serverを確認します。操作側にも対応する送信と状態応答処理が必要です。発見やProvisioningの成功は、目的のモデルの存在を保証しません。モデルが違えば送信出力を上げても解決しません。

AppKey AddとModel App Bindは別工程

まず対象ノードへAppKeyを追加し、適切なNetKeyとの関係を指定します。次に、そのAppKeyを利用するアプリケーションモデルへバインドします。

鍵が保存されただけでは各モデルがその鍵のメッセージを処理できるとは限りません。別のエレメントやモデルへバインドしても、目的の照明機能は設定されません。

送信側にも正しい鍵とモデル設定が必要です。照明だけ設定しても通信関係は完成しません。また、すべてのモデルがAppKeyを使うわけではなく、ConfigurationモデルはDevKeyを使います。

Silicon Labsの設定APIでも鍵追加とモデルバインドは独立した操作で、結果イベントが分かれています。ローカルAPIが受理したこと、相手から設定結果が返ったこと、目的の機能が動くことは別々に確認します。

SDKに従って対応する結果を待ち、ノード、エレメント、モデル、ステータスを確認します。タイムアウトは結果が不明という意味で、相手が何も実行していない証拠ではありません。

一台を動かしてからグループへ

最初は確認済みの照明エレメントへユニキャストし、対応する状態応答を見ます。

ユニキャスト制御のために、先にグループ購読を追加する必要はありません。 宛先を明示できる送信APIでも、すべての送信に事前のモデル発行先設定が必須とは限りません。

単体で動いたらグループを追加します。壁スイッチで廊下の照明をまとめて操作するなら、次の関係を作ります。

• スイッチの対象クライアントモデルがグループアドレスへ発行する。
• 各照明の対象サーバーモデルがそのアドレスを購読する。
• 両側のAppKeyとモデル設定を一致させる。

照明を増やすときは、参加とアプリ設定後に同じグループを購読させれば、スイッチ内の個別機器一覧を書き換えずに済みます。

「廊下の照明」という名前は人向けのラベルです。購読は具体的なモデルに設定するもので、アプリで同じ部屋に移しただけでは無線側の設定完了を証明できません。

発行先は状態の行き先にも関わる

要求に応じた状態応答と、機器のボタン操作後に自発的に送る通知は別経路です。

モデルの発行設定には宛先、AppKey、対応する発行パラメータなどがあります。ただし宛先を設定しても、すべてのモデルが期待した周期で自動報告するわけではなく、アプリが全ローカル変更を処理した保証もありません。

「点灯できる」と「最新の報告状態を把握できる」は分けて検証します。Matter Bridgeで壁スイッチの変更が届かなければ、上位アプリは実際の最新報告ではなく、最後の送信コマンドを表示し続けます。

状態報告にも観測限界があります。出力オンという報告は、物理的なフィードバックがない限り、照明が正常に光っている証明ではありません。

設定は途中から復旧できるようにする

設定中の停電、応答の消失、ホスト再起動は想定すべき事象です。鍵追加、バインド、購読、発行設定を順に送るだけでは、失敗後の再開位置が分かりません。

期待する設定と確認済み結果を記録し、復旧時には必要な状態を読み、差分を埋めます。AppKey Addがタイムアウトしたら、プロトコルとSDKの照会機能で状態を確認して再試行を判断します。繰り返しの挙動はコマンド次第であり、すべて無害とは限りません。

アドレス割り当て、ノード識別、必要な鍵と設定を永続化し、アクセス制御とバックアップを用意します。そうしないと機器はネットワークに残っているのに、管理側だけ管理方法を失います。

毎回の工場出荷リセットを最初の手段にはしません。既存の関係を壊す可能性があります。未参加、参加済みで未設定、設定済みだが管理記録を失った状態をまず区別します。

症状から確認する層を絞る

症状	先に確認する項目
発見できるがProvisioning失敗	接続モード、bearer、認証、双方のエラー
参加後の設定がタイムアウト	アドレス、DevKeyとネットワーク文脈、到達性、応答対応、LPNの受信時機
設定できるが単体制御できない	エレメントとモデル、AppKey追加・バインド、送信側
単体制御だけ成功	グループ宛先、モデル購読、鍵と送信設定
制御できるが表示が更新されない	応答、自発通知、受信処理、上位への状態変換
再起動後に動かない	永続化、アドレス記録、設定復旧、鍵の文脈

これは調査順序で、症状だけによる断定ではありません。状態照会、ログ、必要ならパケット取得で停止位置を確認します。

単体制御と状態回読、グループ、本体操作後の通知、設定中断と再起動の順に確かめます。「光った」の一言より、段階ごとの成功条件が役立ちます。

機器の追加は一つの処理ではない

画面のボタンは一つでも、内部には発見、Provisioning完了、構成把握、アプリ設定完了、制御と状態の検証という段階があります。

分けて管理すれば、利用者に全プロトコルを教えなくても、完了したこと、残っていること、再開できる位置を正確に伝えられます。

SIG Meshは共通の機構を提供しますが、配網だけですべてのブランド、モデル、エコシステムが自動的につながるとは約束していません。ネットワークへ入ったノードを、信頼して管理できる機器にするまでがゲートウェイの仕事です。

次回は小米Meshに戻り、標準ネットワークとモデルに加えて、米家接続が求める製品定義、識別情報、プラットフォーム要件を扱います。

参考資料

• Bluetooth SIG：Mesh Networking Primer — アドレス、発行と購読、鍵、Provisioning、Configuration。
• Silicon Labs：Configuration Client API — 構成取得、鍵追加、バインド、購読と発行。採用するSDKの版を確認してください。