Bluetooth機器をMatterブリッジでApple Homeにつなぐ方法
機器ごとにチップを替えなくても、Matterゲートウェイ1台でBluetooth MeshのスイッチやライトをApple Homeにつなげます。構成、主な判断、今後の課題をまとめました。
最近、Bluetooth機器をまとめて Apple Home に対応させるプロジェクトを進めています。
機器そのものはシンプルです。1〜4路の壁スイッチ、調光ライト、調色ライト、それに壁に貼り付けて使うワイヤレススイッチ。どれも Bluetooth Mesh でネットワークを組み、これまでは自社アプリで操作してきました。使い勝手に不満はありません。
プレッシャーはお客さん側から来ます。いちばんよく聞かれるのが 「Apple Home で操作できますか?」 で、その次には決まって Google Home や Home Assistant の名前が出てきます。
Apple、Google、Amazon がここ数年こぞって推進しているのが Matter です。ユーザーはもう「家じゅうの機器を1つのアプリで管理する」ことに慣れてきていて、Matter に対応しない製品はこれから先、売りにくくなる一方でしょう。
この記事はプロジェクト全体の総論です。なぜこの方式にしたのか、全体のアーキテクチャはどうなっているのか、そして今どこまで進んでいるのか。チップ、メインプロセッサ、プロトコルスタック、認証といったテーマごとに、続きの記事で順番に掘り下げていきます。
2つの道:機器のチップを替えるか、ゲートウェイを足すか
Bluetooth機器を Matter につなぐ方法は、大きく2つあります。
1つ目は、機器そのものを作り変える方法。 全機種のチップを Matter 対応の Thread や Wi-Fi のものに載せ替え、ファームウェアを書き直し、さらに機種ごとに Matter 認証を取ります。
2つ目は、機器には手を入れずにゲートウェイを足す方法。 ゲートウェイは片側で Bluetooth 経由で機器とつながり、もう片側では Matter デバイスとしてホームネットワークに参加します。Apple Home から見ると、Matter ゲートウェイが1台あって、その下にスイッチやライトがぶら下がっている形です。Matter の仕様では、この種のデバイスを Bridge(ブリッジ) と呼びます。
| 比較項目 | 機器を作り変える | ゲートウェイを足す |
|---|---|---|
| 機器のコスト | 全台でより高価なチップが必要 | 変わらない |
| ファームウェアの工数 | 全機種で書き直し | 機器側の変更は小さく、主な作業はゲートウェイ側 |
| Matter 認証 | 機種ごとに個別に取得 | ゲートウェイで1回だけ |
| すでに販売済みの機器 | 対応できない | ファームウェア更新後に接続可能 |
| ユーザーが追加で買うもの | なし | ゲートウェイ1台 |
うちは機種が多く、単価が低く、しかもすでにお客さんの家に設置されているものがたくさんあります。1機種ずつチップを替えるのは現実的ではないので、ゲートウェイ方式を選びました。
代償もはっきりしています。ユーザーはゲートウェイをもう1台買う必要がありますし、ゲートウェイの電源が落ちたりネットワークから外れたりすると、Bluetooth ネットワーク全体に影響が出ます。この2点は、設計の段階で正面から向き合うことにしました。
全体アーキテクチャ
システムは上から下まで4つの層に分かれています。
Apple Home / Google Home / Home Assistant
│ Matter（Wi-Fi または有線LAN）
▼
【Linux ゲートウェイ】
├─ Matter Bridge：スイッチも照明も1台ずつ公開
├─ デバイステーブル：機器、回路数、オンライン状態
├─ マッピング層：Matterコマンド ↔ Meshメッセージ
└─ Mesh連携層：UARTでBluetoothモジュールを操作
│ UART
▼
【Bluetoothモジュール】ペアリング、Mesh送受信
│ Bluetooth SIG Mesh
▼
スイッチ / 調光ライト / 調色ライト / ワイヤレススイッチ- 最上位はスマートホームの各プラットフォームです。話せるのは Matter だけで、その下が Bluetooth だということは知りません。
- ゲートウェイの基板では Linux が動き、プログラムは1本だけです。外から見れば Matter ゲートウェイ、内側では Bluetooth 機器をすべて管理します。
- Bluetooth モジュールは別チップにしています。Bluetooth Mesh のプロトコルスタックはモジュールの中で動き、Linux ホストはシリアルポート経由で指示を送ります。
- 最下層が機器で、Bluetooth SIG 標準の Mesh プロトコル、つまり SIG Mesh を使います。
この分け方の一番のメリットは、Bluetooth 側と Matter 側を切り離してデバッグでき、別々に差し替えられることです。あとでメインプロセッサを替えても Bluetooth モジュールや機器のファームウェアには触らなくて済みますし、Bluetooth モジュールのメーカーを変えるときも、手を入れるのは連携層だけです。
ゲートウェイの肝:翻訳レイヤー
ゲートウェイが実際に仕事をするのがマッピング層です。Matter のデバイスタイプやコマンドを、Bluetooth Mesh が理解できるメッセージに翻訳します。
| 自社の機器 | Apple Home での見え方 | 変換が必要な点 |
|---|---|---|
| 1〜4路スイッチ | 1路ごとに1つのスイッチ(On/Off Light) | なし |
| 調光ライト | 明るさを調整できるライト(Dimmable Light) | Matter の明るさは 1〜254、Mesh の明るさは 0〜65535 |
| 調色ライト | 色温度を調整できるライト(Color Temperature Light) | Matter は mireds を使う。1,000,000 をケルビン値で割った値 |
| カラーライト | カラーライト(Extended Color Light) | 色相と彩度の値の範囲が違う |
| ワイヤレススイッチ | ボタンスイッチ(Generic Switch) | 短押し・長押し・ダブルクリックを Matter のボタンイベントに変換 |
4路スイッチは、Apple Home では4つの独立したスイッチになります。それぞれを別の部屋に置いたり、別のシーンに組み込んだりできます。これは Bridge の標準的なやり方で、ユーザーにとっても一番分かりやすい形です。
翻訳そのものは難しくありません。難しいのは、見落としやすい次の2点です。
1つ目は物理ボタン。 壁のスイッチを押したら、Apple Home 上の状態も変わらなければなりません。そのため、機器は状態が変わるたびに自分から新しい状態をゲートウェイに送り、ゲートウェイがそれを Matter に同期します。「アプリが機器を操作する」だけでは半分です。「機器がアプリに知らせる」ほうも同じくらい大事です。
2つ目はオフライン。 壁のブレーカーで電源が落ちたライトは、最後の状態をずっと表示し続けるのではなく、Apple Home で「応答なし」と表示されるべきです。そこで各機器からゲートウェイに定期的にハートビートを送らせ、何回か続けて届かなければオフラインと判定しています。
ユーザー体験に関わる設計がもう1つあります。ワイヤレススイッチはゲートウェイを通さず、ライトを直接制御します。 スイッチはコマンドを部屋のグループアドレスに送り、ライトがそれに直接応答します。ゲートウェイは横で聞いていて状態を同期するだけです。こうしておけば、ゲートウェイがネットワークから落ちたり壊れたりしても、壁のスイッチでちゃんと照明がつきます。ゲートウェイは便利さを足す存在であって、単一障害点になってはいけません。
主な選択
設計には、何度も比較してようやく決まった部分がいくつかあります。ここでは結論だけ書いておき、理由はそれぞれ別の記事で説明します。
- 機器とゲートウェイの間は独自プロトコルではなく SIG Mesh。 標準にはスイッチやライト用の標準モデルがあるので、両側が標準どおりに作ってあれば、ゲートウェイと機器で別メーカーのチップを使っても相互に通信できます。
- ゲートウェイの Bluetooth は Silicon Labs のモジュール、機器側は Telink。 ゲートウェイ側ではドキュメントとツールを重視しました。Silicon Labs のモジュールはコプロセッサとして使え、シリアルプロトコルも正式にドキュメント化されています。機器側ではコストと中国国内のサプライチェーンを重視していて、そこでは Telink のほうが向いています。
- メインプロセッサは要件に応じて段階分け。 ブリッジ専用なら Rockchip の RK3506 のようなエントリークラスで十分です。ローカルオートメーションや Web 管理画面の余裕を持たせたいなら RK3562、画面付きのコントロールパネルにするなら RK3576 まで上げます。
- Matter スタックは Rust 製の rs-matter。 ビルドすると小さな単体プログラムになり、実行中のデバイス追加・削除にも対応しています。Bridge にはぴったりです。
現在の進捗
いま完了しているのはソフトウェアのプロトタイプです。
- Windows PC をゲートウェイに見立てて、Apple Home でコードをスキャンして追加できた
- スマートフォンを Bluetooth 機器に見立てると、ゲートウェイがそれを検出し、Apple Home に操作可能なデバイスとして表示された
- Apple Home でオン・オフを切り替えると、模擬機器にコマンドが届く。機器を追加・削除すると、Apple Home 側にも現れたり消えたりする
つまり、「Matter ↔ ゲートウェイ ↔ Bluetooth 機器」のルートはソフトウェア上ではつながっていて、Apple Home はブリッジされた機器を認識し、操作できています。
まだ手をつけていないのが実機です。Silicon Labs のモジュールと Telink の機器の結合テスト、そして Linux ゲートウェイ基板での動作確認。開発ボードは発注中で、ここから数週間はこの部分が中心になります。
これから解決すべき課題
この4つが、方式として量産できるかどうかを左右します。それぞれ別の記事で書いていきます。
- 2社のチップは相互接続できるか。 Silicon Labs のゲートウェイに Telink の機器、標準プロトコルなら理屈の上ではつながるはずですが、実際に基板に載せて確かめる必要があります。
- 1台のゲートウェイで何台まで扱えるか。 一般家庭なら数十台は問題ありません。でも商業施設だと100台を超えるのも珍しくないので、負荷テストが要ります。
- ゲートウェイが壊れたらどうなるか。 停電からの再起動や Bluetooth モジュールの交換のあとでも、設定済みの機器が自動で復帰してくれないといけません。ユーザーにもう一度ペアリングさせるわけにはいきません。
- 認証。 Matter 認証、HomeKit 関連の要件、電波法関連の認証。それぞれいくらかかるのか、どれから着手するのか。
おわりに
Bluetooth 機器を Matter につなぐのは、思ったほど神秘的なことではありません。本当に時間がかかるのは、チップ選び、機器の状態同期、ゲートウェイが壊れたときの備え、そして量産前には避けて通れない認証まわりです。
このプロジェクトの、プロトタイプから量産までの道のりを、テーマごとに少しずつ書いていくつもりです。遠回りした話も含めて。
手元に Matter につなぎたい Bluetooth 機器がある方、似たようなゲートウェイを作っている方、ぜひ気軽に話しましょう。方式の考え方、チップ選定、踏んだ地雷の話など、なんでも歓迎です: linktr.ee/weiyii