Bluetooth Mesh の一括制御：1灯だけ点かないとき、全体へ再送すべき？

会議室で「すべて点灯」を押したとします。ほとんどは点いたのに、隅の1灯だけ反応しない。それでもスマートフォンには「送信成功」と表示されています。

もう一度押すと全部点きました。でも、一括操作のたびに天井を見上げて確認するのでしょうか。

思いつきやすい対策は、各照明に「受信した」と返してもらい、返答がなければ再送することです。情報は増えますが、一斉の応答と繰り返す問い合わせ自体がネットワークの負担にもなります。

先に結論です。フィードバックが足りないからといって、すぐに全体へ再送しないこと。送信できたのか、機器がどの状態を報告したのか、実際に照明が点いたのかは、別の証拠です。

会議室は説明用の仮定であり、現場テストではありません。対象は SIG Mesh のマルチキャストとモデルメッセージで、米家など特定製品の実装を示すものではありません。成功率、遅延、ノード容量は測定していません。以下の状態管理や補償は設計上の提案であり、プロトコルが自動で提供する完成済みの仕組みではありません。

1. 「送信成功」は、どこまでの成功？

アプリがゲートウェイに要求を渡しただけかもしれません。モジュールが送信タスクを受け付けた意味かもしれません。表示から推測せず、インターフェースとログを確認します。

証拠を3層に分けます。

送信側がタスクを受け付けた。 送信処理のある段階に進んだ証拠であり、対象照明が受信した証拠ではありません。

対象モデルから状態が届いた。 例えば Generic OnOff Status は該当エレメントの Generic OnOff 状態を報告します。送信元を特定し、現在値、目標値、必要に応じて残り遷移時間を区別します。

現実の照明が要求を満たした。 ドライバー、電源、光源、現場条件も関わります。モデルの「オン」は独立した光学測定ではなく、LED やドライバーの故障を否定できません。

送信受付、モデル状態、実際の点灯という3層の証拠は、それぞれ別の確認が必要

毎回3種類の確認を増やせという話ではありません。画面が主張する範囲を、その証拠で裏付けようという話です。

まず確認： 成功表示の元になったコードや API 定義を調べます。キューへの登録、モジュールの結果、対象からの状態報告のどれでしょうか。ここが曖昧だと成功率の集計も出発点からずれます。

2. グループ宛ての1通は、全員の受領票ではない

SIG Mesh のグループ制御では、一般にパブリッシュ／サブスクライブを使います。スイッチがグループアドレスへ送信し、照明の該当モデルがそのアドレスを購読します。各灯へ順番に電話するのではなく、「会議室のみなさん」と一度呼びかけるイメージです。

同じ意図を1台ずつ送る必要はありません。ただしグループアドレスは、実行済み全メンバーの一覧を自動生成しません。

期待するメンバーは管理側が把握する必要があります。 新設灯のモデル購読は設定済みか。交換した旧機器が一覧に残っていないか。数件の状態報告から正しい名簿は復元できません。

パケット数も完了台数とは別です。期待するエレメントとモデルに照合し、同じ送信元からの重複を別の照明として数えないようにします。

まず確認： 設置一覧とモデル、AppKey バインド、グループ購読を比較します。1灯だけ毎回反応しないなら、すべての中継や再送設定を増やす前に、その制御グループの対象かを調べます。

3. 全灯から返事をもらえば、もっと確実では？

Generic OnOff を例にすると、次の違いがあります。

Generic OnOff Set は応答を要求し、Generic OnOff Status が返答になります。
Generic OnOff Set Unacknowledged は、その要求に対するモデル応答を要求しません。

ここでの話はモデル層の応答です。下位の転送確認、ゲートウェイ API の返答、現実の実行を1つの「ACK」にまとめないことが重要です。

1対1の操作では対応する返答が役立ちます。しかし1つのグループ要求に多数のノードが応答すると、無線資源を使うのは制御の1通だけではなくなります。

Bluetooth SIG の規模設計記事は、多数の応答に問い合わせや再試行が重なると密なメッセージ流になることを説明しています。毎回全員の返事を求めるのではなく、応答不要のマルチキャスト制御も重視しています。

応答不要なら必ず届く、あるいはグループ宛ての応答要求は禁止、という意味ではありません。 制御と確認の両方を通信量として見積もり、業務要件に応じて選ぶという意味です。返答が多いほど必ず信頼性が高いとは限りません。

また、この要求への応答が不要でも、状態報告を一切しないとは限りません。状態パブリッシュと要求への応答は別々の設定・動作として確認します。

まず確認： 送ったメッセージ、制御側が待つ応答、設定済みの状態パブリッシュを列挙してから再試行を考えます。

4. 状態が来なければ、まず「不明」にする

命令自体が届いていない場合も、実行したのに状態の戻り経路で失われた場合もあります。遷移中かもしれず、古い報告を新しい結果と取り違えているかもしれません。「応答あり／なし」だけでは区別できません。

アプリでは、例えば次のように表せます。

要求済み： 意図を送ったが、対象の十分な証拠はまだない。
状態確認済み： 今回の判断条件を満たすモデル状態を受信し、送信元と時刻を記録した。
要確認： 合意した観測時間内に十分な証拠が得られなかった。

これはアプリの設計提案であり、Mesh の標準状態を追加するものではありません。

確認の有効性も永続ではありません。壁スイッチ、センサー、自動化が後から状態を変えます。昨日の「オン」をリアルタイム表示にせず、最終確認時刻も示します。

そして、Generic OnOff Status は Set の TID を含みません。 応答のトランザクション番号で要求と1対1に照合できると思わないこと。連続制御、状態パブリッシュ、複数の制御元があるなら、送信元、値、受信時刻、業務文脈を合わせて判断します。今「オン」が届いただけで今回の完了とは断定できません。

5. なぜグループ全体へ無限に再送しないのか

再送で取りこぼした命令が届くことはありますが、無料ではありません。大半が完了済みなら同じ目標を再び処理します。購読漏れ、電源断、ドライバー故障は再送では直りません。

より制御しやすい方向は、グループ制御を送り、報告を観測し、必要なら少数の未確認メンバーを速度制限付きで調べ、根拠がある対象だけに有限の補償を行うことです。

これを「毎回直後に全機器を順番に照会する」と実装してはいけません。同じ通信負荷を後ろへ移すだけです。対象範囲、間隔、終了期限、最大試行回数は、規模と必要応答時間を踏まえてテストします。

再試行はモデルのトランザクション規則に従います。Generic OnOff Set の TID は新規トランザクションと同じものの再送を区別します。再送のたびに勝手に増やすことも、独立した次の操作に古い値を使い続けることも避けます。完全な時間窓と照合条件は採用バージョンの仕様と SDK を確認してください。本記事は万能の再送間隔を提示しません。

補償前には、ユーザーの意図が更新されていないかも確認します。「消灯」の後に以前の「点灯」を補償していては、旧タスクが新しい操作を妨げます。

6. この表を結合テストに持ち込む

以下は診断の提案であり、認証手順や検証済みの製品既定ポリシーではありません。

見える現象	最初の確認	急いで断定しないこと
成功表示だが一部が点かない	表示の意味、購読、電源	全員の実行が保証された
点灯済みなのに失敗表示	状態の戻り経路、受信処理、観測時間	応答なしなら未実行
単体制御は正常、一括で不安定	グループ設定、応答とパブリッシュ、同時負荷	再送を増やせば必ず改善
状態はオンだが暗い	状態の意味、遷移、ドライバーと光源	ソフト状態が光学検査と同じ
連続操作後に表示が揺れる	報告の新旧、複数制御元、旧補償	最後に来た報告が最新
1台だけ報告がない	一覧、モデル、鍵バインド、購読、電源、到達性	全体への再送で必ず解決

送信側の結果、モデル状態、現場観察は別々に記録します。サンプル、観測時間、期待メンバーを揃え、3種類の基準を混ぜて1つの「成功率」にしません。

SDK バージョン、メッセージ種別、送受信元、時刻、関連設定を記録し、機器識別情報は必要に応じて匿名化します。NetKey、AppKey、DevKey や顧客情報は公開しません。

隔離した環境で個別の電源断、連続操作、通常業務との同時実行も試します。不明をどう表示し、再試行をどう止め、復旧後に古い処理が実行されないかを観察します。公共照明や安全機能を持つ設備への障害注入は避けます。

7. 信頼性は「最後に全部点いた」だけではない

1つのボタンの裏には、効率的に送る、どんな証拠を持っているか把握する、不明なときに余計な問題を起こさず補うという3つの課題があります。

毎回全員の返事が必要とは限りません。しかし未確認を100%成功として見せてもいけません。

再送回数を決める前に、期待メンバー、完了の証拠、待機限界、新しい指示による古い作業の終了を定義しましょう。隅の暗い1灯が、単なる「もう一度押す理由」ではなく診断できる問題になります。

関連：配網とモデルバインド、選定・受け入れチェックリスト、電池ノードの受信。

資料と適用範囲

Bluetooth SIG：Mesh Model v1.1、特に 3.2.1。メッセージ、TID、遷移関連フィールドを確認。製品の採用仕様と SDK を別途確認してください。
Bluetooth SIG：Mesh in large-scale networks、2018-06-26。共有無線資源と応答負荷の説明。歴史的な規模や数値を現在の製品性能とは扱いません。
Silicon Labs：Lighting Demonstration、11.0.1。パブリッシュ／サブスクライブとグループ制御の確認用で、全メーカー共通の動作を示しません。

資料確認日：2026-11-06。仕組みの分析と設計提案であり、実機・現場の性能試験は行っていません。

表紙は会議室の照明のグループ制御を表す AI 生成のイラストであり、実機試験の現場写真ではありません。