SIG Mesh 対応なのに Mi Home に接続できない？Xiaomi Mesh の製品識別と接続の境界

照明はすでに SIG Mesh に参加でき、開発ボードから点灯や明るさを操作できる。Mi Home に追加するには、広告名を変えて Xiaomi のゲートウェイを用意するだけでよいのでしょうか。

逆の疑問もあります。Mi Home 対応の Bluetooth Mesh 照明が標準を使っているなら、自作ゲートウェイで管理し、Matter に橋渡しできるのでしょうか。

どちらも「SIG Mesh 対応」という表示だけでは判断できません。

前回は Provisioning、アプリケーション鍵、モデルのバインドを説明しました。今回は一段上の、Mi Home が認識する製品になる条件、プラットフォームの機能が無線メッセージに変わる仕組み、ゲートウェイの保証範囲を整理します。

2026 年 11 月 5 日に確認できた Xiaomi BLE Mesh 開発資料に基づきます。製品世代、SDK、ゲートウェイのファームウェアは個別に確認が必要です。「Xiaomi Mesh」と呼ばれる全製品共通の能力一覧ではありません。照明や診断手順は設計例で、実機の相互運用試験は行っていません。

照明が答えるべき三つの問い

標準 Mesh では、ノードのアドレス、鍵、エレメント、モデルを扱います。Mi Home ではさらに、どの製品で、どんな機能を持ち、ユーザーがどう操作するかをプラットフォームに伝えます。

層	確認すること	これだけでは足りない
Mesh ネットワークとアプリ	参加方法、メッセージを受けるモデル、鍵の設定	広告を検出できる
製品定義と機器の識別	製品と個体を識別し、プラットフォームの登録を完了できるか	点灯モデルを実装している
利用と保守	アプリ、音声、ゲートウェイが機能、状態、更新を扱えるか	一度登録できた

各層は関連しますが、代わりにはなりません。第 3 回はネットワーク参加からアプリ通信の準備まで。Mi Home への接続では、それをプラットフォームの対応する製品フローに組み込む必要があります。

チップメーカーの「SIG Mesh 対応」に続けて聞くべきなのは、どの接続方式、どの SDK バージョンで、予定する製品カテゴリに使えるのかです。

MIoT Spec と Mesh Model は異なるインターフェース

Xiaomi の過去の接続資料は、製品のサービス、プロパティ、操作を表す MIoT Spec と、SIG Mesh のモデル、メッセージ、状態を扱う Mesh Spec を区別しています。現在の BLE Mesh 基礎知識も、ゲートウェイが Spec と Mesh のメッセージを変換すると説明しています。

たとえば点灯は、プラットフォームでは電源プロパティをオンにする操作です。無線側では対象機器が理解できるメッセージに変換します。状態報告は逆向きに変換します。

項目名を変えるだけではありません。機能 ID、型、値域、報告方法をプラットフォームとファームウェアで一致させる必要があります。アプリに明るさのスライダーが表示されても、値が照明モデルへ正しく変換されている証拠にはなりません。

クラウド制御の概念図：アプリや音声の要求、Spec 処理、ゲートウェイでの変換、機器の実行と状態報告

図は Xiaomi 資料のクラウド制御経路をまとめたもので、中継などの詳細は省略しています。すべての操作にクラウドが必須という意味ではなく、スマートフォンの直接接続やローカル自動化は実装ごとの確認が必要です。

標準モデルとメーカー拡張は共存できます。過去の色温度照明の例にも、標準照明モデルと Xiaomi のモデルが含まれています。ただし、現在の任意の製品が同じエレメント構成やモデル ID を使う保証にはなりません。

プラットフォームに独自機能を追加しても、既存ゲートウェイ、ファームウェア、音声機能が自動的に理解するわけではありません。現在の方式で各段階がどこまで対応するかを確認します。

製品型番、機器の識別情報、Mesh の鍵は別物

プラットフォームの model 名は製品型番を識別します。一方 Mesh Model はアプリ通信の振る舞いを定義します。型番に light と入れても、照明モデルが実装されるわけではありません。

PID、Product ID も、個体の Mesh ユニキャストアドレスではありません。製品識別とネットワーク内の宛先指定は目的が違います。

プラットフォームには機器の識別に関する条件もあります。BLE Mesh FAQでは、記載されたモジュール方式において、最初の登録後に証明書チェーン、Product ID、MAC が関連付けられると説明しています。それらの変更で後の接続に失敗する可能性があり、チップ全体の消去は証明書チェーンの消失につながります。

開発モジュールを、いつでも消去して別の PID を入れ直せる空のデモ基板と考えてはいけません。書き込み前に識別データの保存領域と、供給元が認める更新、リセット、復旧方法を確認します。

これは Xiaomi の該当方式の説明で、SIG Mesh が全機器に求める条件ではありません。全チップ共通のメモリ配置や全製品共通の復旧手順を導くこともできません。

前回の NetKey、AppKey、DevKey は、Mesh のネットワーク、アプリ、構成通信の安全性を担います。製品の識別要件を代替せず、製品証明書も Mesh のアプリ鍵として使うものではありません。

標準 Mesh のデモ成功は、その技術経路が動くことの証明です。自社製品として Mi Home に接続するには、対応するプラットフォームと識別情報の設定が必要です。

実際に見つかった資料の差：旧テンプレートをそのまま使わない

今回役立ったのはコード断片より、新旧資料の違いでした。

BLE Mesh 基礎知識の更新表示は 2026 年 8 月 4 日です。8 月 6 日から新規作成の BLE Mesh 製品のテンプレートが変わり、すでに作成された試験中の製品は影響を受けないと説明しています。明るさ照明と明るさ・色温度照明のテンプレートは維持され、1・2・3 キースイッチやファンなどは MI_MESH_TEMPLATE_CLOUD に統合されます。

プラットフォームとファームウェアのテンプレート不一致は制御や報告の不具合につながり、MI_MESH_TEMPLATE_CLOUD へ変更したファームウェアでは周期発行プロパティを手動追加する必要がある、とも書かれています。

しかし、2024 年 11 月 6 日更新の FAQ には、3 キースイッチで MI_MESH_TEMPLATE_THREE_KEY_SWITCH を使う旧例が残っています。

ここから「古いファームウェアを全部変更する」とは結論できません。製品の作成時期、カテゴリ、現在選べる方式、SDK とファームウェア設定を先に確認します。

新ルールの対象製品は新しい変更通知に照らし、既存製品は新しいマクロを見ただけで切り替えないことが大切です。

チュートリアルがコンパイルできても、現在のプラットフォーム設定と一致するとは限りません。 チップ型番だけでなく、製品定義、ファームウェア、対象ゲートウェイのバージョンを一緒に記録します。

ゲートウェイの「受信した」は照明の「実行した」ではない

登録後によく起きる疑問は、ボタンを押してインターフェースも応答したのに、なぜ照明が変わらないのか、です。

基礎知識は、サーバー・ゲートウェイ・機器間の通信が非同期で、サーバーからの制御指示にゲートウェイがすぐ応答すると明記しています。

その応答だけで機器の実行を判定できません。要求処理、無線配送、機器からの状態報告を分け、具体的なステータスコードは実際のインターフェース定義で解釈します。

プロパティ取得も「今、無線で機器に問い合わせた」とは限りません。登録直後でゲートウェイに値のキャッシュがなければ、アプリの取得は -4004 を返す場合があります。登録後に機器がプロパティを能動報告することが、資料の対処案の一つです。

報告にもフィルターがあります。ゲートウェイはプロパティをキャッシュし、間隔または変化条件を満たすとクラウドへ送ります。イベントは別経路で、資料では受信後すぐ転送するとしています。この「すぐ」はゲートウェイの処理説明で、全経路の遅延や必達の保証ではありません。

照明は変化したがクラウドの表示が遅い、機器は通信可能だがあるプロパティは再報告されない、といった現象では、制御、報告、キャッシュ、フィルターを分けて調べます。直ちに無線の欠落と決めつけないことです。

自作ゲートウェイなら、期待する状態と最後の機器報告、その時刻を保持します。命令送信と同時にすべての画面を「オン」にするのは避けたいところです。これは設計上の提案で、Xiaomi 指定の画面仕様ではありません。

Bluetooth スピーカーが適切な Mesh ゲートウェイとは限らない

FAQ は、スピーカーの BLE Mesh ゲートウェイ対応、機能の有効化、ファームウェアを確認項目に挙げています。

「XiaoAI スピーカーがある」だけでは互換性条件が不十分です。具体的な型番とファームウェア、対象製品の機能を確認します。Bluetooth 音声再生と BLE Mesh ゲートウェイ機能は別です。

中継できることもゲートウェイ機能の代わりにはなりません。現行の基礎資料は、低消費電力機器ではなくスキャン窓が FULL の場合に標準で中継するとしつつ、その方式では機器同士の制御はできないと述べています。

矛盾ではありません。中継は配送を助け、制御にはアプリの役割と設定が必要です。Bluetooth SIG の説明では、スイッチ、センサー、照明のローカルな制御通信が可能です。特定の Xiaomi 方式がそれを実装し公開するかは別問題です。

方式の制限を Mesh 全体の制限にせず、標準が許す機能を個別製品の実装済み機能として約束しないことが重要です。

オフライン動作は制御経路ごとに検証する

Xiaomi は、遠隔制御には Mesh ゲートウェイが必要で、ゲートウェイがなければ必要に応じて Bluetooth 直接制御を開発できるとしています。全市販品が同じ直接接続機能を持つ、すべての自動化がローカルで動く、という意味ではありません。

開発や購入の前に、同じ機能を条件を変えて試します。

条件	観察する内容
インターネットだけ切断し、ルーター・ゲートウェイ・機器は給電	既存の制御や自動化の継続と失敗
ゲートウェイを停止し、機器は給電	物理ボタン、明示的に対応する直接接続、機器連動
機器をローカル操作して状態変更	ゲートウェイ・アプリの更新、再接続時の古い値
ゲートウェイと機器を個別に再起動	登録・設定の保持と状態の再取得

これは未実施の試験案です。機器・ゲートウェイの型番、ファームウェア、アプリ版、操作入口を記録し、結果を特定の組み合わせに結び付けます。

ゲートウェイ停止後に物理ボタンで照明が点いても、自動化全体の独立性は証明できません。試した経路に限定して結論を出します。

自作ゲートウェイや Matter では、どこにつなぐかを先に決める

既製の Mi Home 照明を管理するなら、製品が認める対応接続方法の確認から始めます。自前ネットワークへの参加、モデル設定、識別と Provisioning の利用可能な実装は、製品ごとの検証が必要です。工場出荷状態へのリセットも、任意の Provisioner への開放を保証しません。

公式のプラットフォーム API を使う場合、利用するのはその API の機能、権限、制御経路です。下位 Mesh の直接管理と同一視できず、クラウド経由の操作をローカル制御と呼ぶこともできません。

機器のファームウェアも開発するなら、モデルや報告、保守を統一しやすくなります。それでも自前方式と Mi Home 版にはそれぞれ識別、設定、対応範囲の評価が必要で、切り替え一つで既存機器を無損失移行できるとは約束できません。

Matter ブリッジはさらに上の層です。すでに確実に管理できる機能を Matter の機器と状態に変換します。Bluetooth 側の管理権限不足、未対応機能、状態取得不可を解決してくれるものではありません。実装の話は Rust で作る Matter ゲートウェイへ続きます。

着手前に互換性を具体的な合意にする

Mi Home Mesh 製品なら、供給元と次を確認します。

対象カテゴリの対応方式と、入手・保守できる SDK バージョン。
製品識別子と個体識別情報の提供方法、書き込み時に保持する領域、復旧支援。
電源、調光、色温度、独自機能のモデルや変換と、状態報告方法。
受入試験に使うゲートウェイとファームウェア、アプリ・音声・オフラインの各能力。
更新、既存製品の維持、プラットフォーム変更への対応責任。

この一覧は参加審査や公開手順を代替しません。技術デモの成功は販売承認、認証、ブランド使用資格ではありません。現在の商用条件はプラットフォームと供給元に確認し、旧記事の費用や約束を流用しないようにします。

役立つ互換性の表現は、「この製品が、このバージョンと設定で、この経路から、この操作を実行し、状態を確認できる」です。標準を再利用できる範囲、プラットフォーム適合が必要な範囲、試験不足が見えるようになります。

次回は独自 Mesh、標準 SIG Mesh、Mi Home 接続方式を具体的な場面に戻し、制御、オフライン能力、保守コストから選び、公平で再現可能な検証を設計します。

参考資料

Xiaomi IoT：BLE Mesh 基礎知識、更新表示 2026-08-04。テンプレート変更、通信、状態報告。
Xiaomi IoT：BLE Mesh FAQ、更新表示 2024-11-06。識別、書き込み、診断。テンプレート例は新しい通知と照合。
MiEcosystem：Bluetooth Mesh 接続開発、過去の構造説明。現在のチップ、テンプレート、公開手順のガイドではありません。
Bluetooth SIG：The Bluetooth Mesh Networking Primer、標準の能力とエコシステム実装の区別。