Matterゲートウェイの結合テスト：UART応答からApple Homeの状態同期まで

開発ボードをつなぎ、スマートフォンをタップすると照明が点く。スマートホームの開発では、この瞬間に大きな山を越えたように感じます。

ところが、照明の電源を抜いてもアプリでは点灯中のままかもしれません。ゲートウェイを再起動したら再登録が必要になったり、本体のボタンで消灯してもApple Homeの表示が変わらなかったりします。

これらはコマンド実行、状態同期、復旧という別々の問題です。一度点灯するデモだけでは見えてきません。

前回の開発ボード購入チェックリストでは必要な機材を整理しました。今回は、最初の結合テストで何を記録し、何ができれば次へ進めるかを具体化します。

現在、PC上のMatter試作はApple Homeへの接続ができ、Linuxイメージもビルド済みです。一方、Silicon LabsのNCPとTelink機器の実際の相互接続、実機の状態通知、システム全体の復旧は未検証です。この記事は初回の受け入れ試験計画であり、実測結果の報告ではありません。

照明1台に絞り、バージョンを固定する

Apple HomeはLAN経由でLinuxゲートウェイに接続し、ゲートウェイはUART/BGAPIでSilicon Labs Bluetooth Mesh NCPを呼び出します。NCPがTelink機器を制御し、状態は逆方向に戻ります。

最初は1台のオン・オフだけを扱います。調光、色温度、シーン、多チャンネルスイッチは後回しにします。機種を増やすほど、失敗の原因候補も増えるからです。

ホストプログラムのコミット、NCPファームウェアとSDKのバージョン、機器側ファームウェア、シリアル設定を記録します。配線も撮影し、電圧レベル、GND、RTS/CTSを確認できるようにします。ホストとファームウェアを同時に変更して「何となく直った」で終わらせないことが大切です。

まず選んだSDKに対応する公式ホストサンプルでNCPと機器を確認し、その後ハードウェアとファームウェアを変えずに自作Rustプログラムへ置き換えます。公式サンプルでも動かなければ機能やモデル設定を調べ、自作側だけ失敗するならフレーム解析や呼び出し順序を絞って調べられます。

「成功」を4段階に分ける

段階	確認できること	まだ確認できないこと
UARTへの書き込み	データをシリアルインターフェースへ渡した	NCPが正しく解析した
BGAPI応答	NCPがAPI呼び出しの結果を返した	照明が実行した
機器の状態受信	リモートモデルが現在値または目標値を報告した	Matter属性とアプリが同期した
Apple Homeの表示一致	観測結果と画面が一致した	再起動や切断後も正しい

BGAPI応答の意味はコマンドごとの仕様によります。成功コードをすべて「点灯完了」と解釈してはいけません。非同期イベントは応答の間に入り得るため、単純に「1回送ったら1回読む」という前提でも解析できません。

ホスト側で操作IDを発行し、対象、要求状態、送信時刻、API応答、関連する状態イベント、最終結果を関連付ける予定です。これはアプリ内部のIDであり、BGAPIやすべてのMeshメッセージがそのIDを返すという意味ではありません。

最初は1台につき未完了操作を1件に限定します。状態を受け取ったら送信元アドレス、要素、モデル、時間範囲を確認し、別の機器や古い状態を今回の成功に数えないようにします。

プロビジョニング後にも確認が必要

ネットワーク参加の完了だけでは制御可能とは限りません。Composition Dataを読み、目的の機能を持つ要素とモデルを確認し、AppKey追加、モデルへのバインド、必要なPublicationとSubscriptionを設定します。

Bluetooth Mesh対応でも、共通して使える標準モデルは一部かもしれません。ベンダー独自機能には別の対応が必要です。

初回は既知のアドレスとオン・オフモデルに対するユニキャストで、応答を伴う操作を優先し、状態取得でも照合します。グループアドレスや複数ノードの応答を持ち込まず、アドレス、鍵、モデル、受信経路を確認できます。

制御への応答と自発的な状態Publicationも別です。本体ボタンによる変更を通知できるファームウェアなら、その設定と受信を確認します。通知しない機器ならポーリングと遅延を評価し、最初からリアルタイム同期を約束しないようにします。

3つの操作経路を別々に試す

1つ目はMatterを介さずホストから照明を制御する経路です。実際の点灯・消灯と返された状態を確認します。遷移に対応する機器では現在値、目標値、残り時間を区別し、到達予定の値を完了済みの値と扱わないようにします。

2つ目は照明側からの変更です。本体ボタンや既知の別経路で操作し、ホストからオン・オフを送らずに新しい状態が届くか確認します。問い合わせれば正しい値が返ることは、自発的通知の成功を意味しません。ポーリング設計なら更新時間を別に測ります。

3つ目がApple Homeから実機を操作する経路です。スマートフォンからの命令、照明の動作、ゲートウェイの状態受信、Matter属性の更新とレポートまで確認します。その後、照明側で操作して画面が追従するかを調べます。

ホストには最新状態が届いているのに画面が変わらない場合、確認範囲はマッピング、属性更新、サブスクリプションによるレポートです。再プロビジョニングすると手掛かりを失いかねません。

保存する状態も、要求された状態と最後に確認できた実状態を分けます。操作を未確認として保持し、適切な報告で確定させます。楽観的に画面を更新するなら、タイムアウトと修正方法が必要です。UART送信の成功だけで、電源の抜けた照明をいつまでも点灯中にしてはいけません。

最初の合格条件を数値で決める

予定しているのは、一定の近距離で照明1台に20サイクルのオン・オフを行い、前の操作が終わってから次へ進む試験です。実機の変化、状態受信、アプリ更新の時間をそれぞれ記録し、端から端までの仮の待ち時間を5秒とします。超過は失敗としてログを残します。

20サイクルと5秒は今回の暫定基準であり、MatterやBluetooth Meshの規定でも、実測性能でもありません。 比較可能な記録を作り、機器の特性と操作感を見て見直すための設定です。

説明できない状態不一致、タイムアウト後の未処理操作、プログラムを再起動しないと進めない停止が残らないことを合格条件にします。再試行で成功しても、最初の失敗は消しません。

応答順序の逆転にも注意が必要です。古い問い合わせの返信が新しい操作より後に届く場合、受信順だけで状態を上書きできません。初回は逐次実行で可能性を減らしますが、連打に対応する前にはキュー、古い応答、状態の収束を別途試験します。

障害は1つずつ起こす

通常操作が通ったら、次の試験を1つずつ実施し、その都度安定状態へ戻します。

障害	観察項目	復旧後の条件
照明の電源断	タイムアウト処理と到達不能判定	再制御でき、実状態が取得できる
NCP再起動	再起動検出と未完了操作の処理	セッションと必要な初期化が戻り、既存機器を制御できる
ホストプロセス再起動	機器表、Matterの識別情報、対応関係の保持	照明が重複せず、ゲートウェイ再登録も不要
LAN切断	Matter接続と下位Meshを分けて観察	復旧後に再同期し、古いキャッシュのままにならない

問い合わせが1回失敗しただけでオフラインと断定できるとは限りません。判定の観測時間と失敗回数を決め、理由をログに残します。電源方式、通知の仕組み、ネットワーク状態に合わせ、一律のHeartbeat規則を全ノードへ適用しないようにします。

機器の重複防止には安定した識別子とマッピングが必要です。照明を再発見するたびにMatterエンドポイント番号を新しく生成せず、機器、要素、ブリッジされたエンドポイントの関係を永続化し、スタックの要件に沿って復元します。

Meshの鍵、アドレス割り当て、シーケンス番号、リプレイ保護の状態も適切な保存と復元が必要です。NCPとホストのどちらが保持するかを確認し、手作業でシーケンス番号に値を加えるだけで電源断を解決したことにしないようにします。

ここで試すのは同じ機器の再起動です。NCPの交換には内部の永続状態を移せるかという別の課題があり、再起動の合格だけでは保証できません。

初期化する前に証拠を残す

応答しない照明を削除して追加し直すと、一時的に直っても、バインド不備、キャッシュ、鍵と機器情報の不整合といった原因が分からなくなります。

失敗時にはバージョン、操作手順、機器識別情報、関連ログを残します。公開するログからは鍵やコミッショニング情報などの機密データを取り除きます。

記録項目	記入欄
試験IDとバージョンの組み合わせ	未記入
操作前の実機・ホスト状態	未記入
手順と期待結果	未記入
UART応答、状態受信、画面更新の時刻	未記入
合否とログの場所	未記入
復旧操作と再現性	未記入

削除の対象も区別します。Matterプラットフォームからゲートウェイを外すことと、Mesh機器を削除してリセットすることは別です。スマートフォンのペアリングを整理するために、下位ネットワーク全体を消すべきではありません。

機器を増やすのはいつか

最初に欲しいのは、決めたバージョンで1台を設定・制御でき、独立した状態変更も受信できる再現可能な手順です。実機と画面が一致し、照明、NCP、ホストを個別に再起動しても継続できることを確認します。

その後2台目を追加し、アドレスやエンドポイントが混ざらないかを調べてから、調光、色温度、グループ制御へ進みます。大規模ネットワーク、長時間負荷、OTA、モジュール交換、認証はそれぞれ別の試験です。

早い段階で身につけたいのは故障箇所を特定する力です。点灯しないときに命令が止まった層を、表示がおかしいときに最後の信頼できる実状態を追えること。その土台ができてから機能を積み上げたいと思います。

関連記事

• Matterゲートウェイ開発ボードの選び方
• Rustとrs-matterでApple Homeへ接続する
• Silicon Labs Bluetooth Mesh APIリファレンス：コマンド、応答、イベントの詳細は使用するSDKのバージョンで確認してください。

同様のブリッジを開発している方は、状態同期や復旧の経験をぜひ共有してください：連絡先。