ハードなしでMatterゲートウェイを動かす：PCとスマホだけでApple Home連携
前回の記事では全体の構成を紹介しました。Bluetooth デバイスと Apple Home のあいだに Matter ゲートウェイを置き、ゲートウェイに双方のメッセージを翻訳してもらう、という形です。
構成は紙の上ならいくらでもきれいに描けます。実際に手を動かす前に、まず確かめておきたいことがありました。自作したゲートウェイを Apple Home はちゃんと認識してくれるのか、そしてその配下の Bluetooth デバイスを操作できるのか？
これはハードウェアがなくても確認できます。開発ボードはまだ配送中だったので、手元にあった Windows パソコンとスマホだけで、経路全体を通しで動かしてみました。
まずはソフトウェアで、ハードウェアはそのあと
ハードウェアのプロジェクトだと、つい最初にボードを買って、モジュールをはんだ付けして、ファームウェアを焼きたくなります。ただ、経路が長くなると、問題が起きたときにどの層が悪いのか切り分けにくいんですよね。Matter のペアリングが失敗したのか、ゲートウェイにバグがあるのか、シリアル通信でバイトが落ちたのか、それとも Bluetooth の電波が弱いだけなのか。
先にソフトウェアで上の2層を通しておけば、実機に切り替えたときに疑うべき範囲がぐっと狭まります。しかもコストはほぼゼロ。パソコンとスマホがあればできます。
誰が何の役を演じるか
役割
実際の製品では
今回のデモでは
コントローラー
Apple Home
Apple Home（本物）
ゲートウェイ
Linux ゲートウェイボード + Bluetooth モジュール
Windows パソコン（内蔵の Bluetooth を使用）
Bluetooth デバイス
スイッチ、照明
スマホ（nRF Connect を使用）
Apple Home は本物で、ゲートウェイのプログラムも後で製品に載せるものと同じです。一番下の「Bluetooth デバイス」だけをスマホが演じています。
nRF Connect は Nordic が出している無料の Bluetooth デバッグツールで、Android にも iPhone にもあります。周囲の Bluetooth アドバタイズをスキャンできるだけでなく、自分でアドバタイズを出すこともできるので、デバイス役にちょうどいいんです。
なぜ Bluetooth Mesh デバイスを直接シミュレートしないのか
実際の製品では、デバイスとゲートウェイのあいだは SIG Mesh で通信します。ただ、スマホは Mesh デバイスを演じられません。Android も iOS も「Mesh ノードになる」機能を公開していないからです。nRF Mesh のようなアプリは、プロビジョニング用のツールやリモコンとしてしか使えません。
そこでデモでは、もっと単純な方法に切り替えました。デバイスとゲートウェイのあいだは、平文の Bluetooth アドバタイズで直接やりとりするという方法です。ゲートウェイが照明をつけたいときは「オン」をアドバタイズし、デバイスの状態が変わったら、その内容をゲートウェイに向けてアドバタイズします。
この形式は暗号化もリプレイ対策もしていないので、経路の検証専用で、製品には使いません。それでも価値があるのは、一番下の通信方式を除けば、ゲートウェイの中身がすべて本物だからです。Matter のペアリング、デバイステーブル、コマンドの変換、状態の同期、どれも本物のまま検証できます。
デモ用のアドバタイズ形式
形式はシンプルなほどよく、スマホアプリで手打ちして組み立てられるくらいがちょうどいいです。
ゲートウェイ → デバイス（ダウンリンク）：製造者固有データ（Manufacturer Data）を1つ使い、Company ID は 0xFFFF にします。これは Bluetooth SIG がテスト用に確保している番号で、正式な製品には使えません。
バイト
内容
例
1～2
固定の GW
47 57
3～4
デバイスアドレス（リトルエンディアン）
02 00 は 0002
5
オン/オフの状態
01 がオン、00 がオフ
6
シーケンス番号（毎回 +1）
05
デバイス → ゲートウェイ（アップリンク）：Android と iPhone でそれぞれ書き方が違います。
Android：同じく製造者固有データで、Company ID は 0xFFFF、データは 4456020001 にします。4456 が DV、0200 がアドレス 0002、最後の 01 がオンを表します。
iPhone：iOS ではアプリがアドバタイズに独自の製造者固有データを載せられず、できるのはデバイス名の変更だけです。そこでデバイス名を DV0002:1 にします。意味はアドレス 0002、オンです。
ゲートウェイ側のパースは数行で済み、どちらの書き方にも対応しています。
pub fn uplink(sections: &[(u8, Vec<u8>)]) -> Option<(u16, bool)> {
sections.iter().find_map(|(t, d)| match (*t, d.as_slice()) {
// Android：製造者固有データ FF FF 'D' 'V' アドレス 状態
(0xFF, [0xFF, 0xFF, b'D', b'V', a0, a1, on, ..]) => {
Some((u16::from_le_bytes([*a0, *a1]), *on != 0))
}
// iPhone：デバイス名 DV0002:1
(0x08 | 0x09, name) => {
let s = std::str::from_utf8(name).ok()?.strip_prefix("DV")?;
let (addr, on) = s.split_once(':')?;
Some((u16::from_str_radix(addr, 16).ok()?, match on {
"1" => true,
"0" => false,
_ => return None,
}))
}
_ => None,
})
}
ゲートウェイのプログラム
ゲートウェイは Rust で書いていて、Matter まわりにはオープンソースの rs-matter を使っています。パソコン側の Bluetooth 送受信は Windows 標準の Bluetooth API を呼んでいるので、追加のドライバーは要りません。
起動すると、プログラムは次の3つのことをします。
Matter ゲートウェイとして振る舞う：ローカルネットワーク上に自分の存在を知らせ、Apple Home からのペアリングを待ちます。まだペアリングしていなければ、ペアリング用の QR コードがターミナルにそのまま表示されます。
デバイステーブルを管理する：ターミナルで add 0002 リビングの照明 と入力すると、照明が1つ追加されます。各デバイスは Matter 上では独立した「ブリッジデバイス」になります。
Bluetooth アドバタイズを送受信する：Apple Home から来たコマンドはダウンリンクのアドバタイズに変換して送り出し、スマホからのアップリンクのアドバタイズをスキャンしたら、状態を更新して Apple Home に同期します。
デバイステーブルとペアリング情報はローカルのファイルに保存されるので、プログラムを再起動してもペアリングし直す必要はありません。
Apple Home に追加する
iPhone の「ホーム」アプリでターミナルの QR コードを読み取れば追加できます。注意点がいくつかあります。
「認証されていないアクセサリ」という警告が出ます。開発中は Matter 公式のテスト用証明書を使っていて、認証を受けていないため、iOS が警告を出すんです。「このまま追加」を選べば大丈夫です。量産時には、認証を取った正式な証明書に差し替える必要があります。
パソコンと iPhone は同じローカルネットワークに接続しておく必要があります。また、Windows ファイアウォールでこのプログラムの通信を許可しておいてください。ペアリングがタイムアウトするときは、まずここを確認しましょう。
ホームハブが必要です。Apple Home で Matter デバイスを操作するには、HomePod か Apple TV をハブとして用意しておく必要があります。
追加に成功すると、Apple Home にゲートウェイが1つ現れ、その配下に「リビングの照明」と「書斎の照明」がぶら下がります。普通の照明と同じように、それぞれ別の部屋に振り分けることもできます。
ダウンリンク：Apple Home から照明をつける
スマホで nRF Connect を開き、スキャン（Scanner）画面に入ります。
Apple Home で「リビングの照明」をタップします。
パソコンのターミナルに BLE TX -> 0002 と1行表示され、ゲートウェイがそのコマンドを1秒間アドバタイズします。
nRF Connect のスキャン一覧にデバイスが1つ増え、製造者固有データは 0xFFFF に 4757 0200 01 xx が続く形になります。つまり「ゲートウェイから、0002 番のデバイスをオンに」という意味です。
パソコンはアドバタイズのたびに別の Bluetooth アドレスを使うことがあります。一覧から探しにくいときは、製造者固有データか電波強度で絞り込んでみてください。
アップリンク：デバイスから Apple Home に伝える
nRF Connect で新しいアドバタイズ（Advertiser）を作ります。Android なら製造者固有データに 0xFFFF / 4456020001 を入力し、iPhone ならデバイス名を DV0002:1 にします。
アドバタイズを開始します。
パソコンのターミナルに BLE RX <- 0002 (リビングの照明): ON と表示されます。
Apple Home のリビングの照明がオンの状態に変わります。
これは、ユーザーが壁のスイッチを押した状況を再現したものです。ダウンリンクよりもこちらのほうが大事かもしれません。デバイスの状態が戻ってこないと、Apple Home の表示が実際の状態とずれてしまうからです。
ハマったところ
全体としては難しい作業ではありませんが、初めてだと詰まりやすいところがいくつかありました。
1. スマホのアドバタイズした状態が、消したばかりの照明をまたつけてしまう。
スマホは同じパケットを延々と繰り返し送り続けます。最初はゲートウェイが受信のたびに状態を更新していたので、Apple Home で照明を消しても、1秒後にスマホの「オン」のパケットで元に戻されてしまいました。内容が変わったときだけ1回の報告として扱うように直したところ、解決しました。実機でも同じで、重複したメッセージは必ず除去する必要があります。
2. iPhone のデバイス名はスキャンレスポンスに入っている。
iPhone がアドバタイズするとき、デバイス名は最初のアドバタイズパケットではなく「スキャンレスポンス」に入っています。パソコンのデフォルトであるパッシブスキャンでは受け取れないので、アクティブスキャンに切り替える必要があります。
3. Bluetooth アドレスではデバイスを識別できない。
スマホもパソコンも、アドバタイズにはランダムアドレスを使っていて、しばらくすると変わってしまいます。そのため、デバイスの身元はアドバタイズの内容、つまりあの2バイトのアドレスに持たせました。これは Mesh の考え方とも一致しています。Mesh のデバイスも MAC ではなく、割り当てられたユニキャストアドレスで識別されます。
4. Windows では複数のアドバタイズを同時に出すと干渉する。
照明を続けて何回かタップすると、複数のアドバタイズが同時に出て、お互いに上書きし合ってしまいました。キューに入れて、1件送り終えてから次を送る方式に変えています。
5. アドバタイズの送信で Matter が止まる。
Windows ではアドバタイズを1回出すのにしばらく時間がかかります。Matter の処理の流れの中で直接呼ぶと、その間は Apple Home から来る他のコマンドがすべて待たされてしまいます。そこで、アドバタイズの送信は別のスレッドに切り出しました。
6. ゲートウェイの製造元や型番を変えても、ペアリングし直す必要はない。
これらの情報は Apple Home がゲートウェイから読み取っているので、ゲートウェイを再起動すれば新しい値が反映されます。ただ、Apple Home にはキャッシュがあり、いつ更新されるかはよく分かりません。すぐに確認したいなら、削除して追加し直すしかありません。ただし、ゲートウェイを削除すると、配下のデバイスもすべて一緒に消えるので注意してください。
ちなみに、ビルドしたてのプログラムは最初かなり大きかったのですが、サイズ優先の最適化にしてデバッグ情報を削ったところ、リリースビルドは 2.3 MB ほどになりました。ゲートウェイボードのストレージには余裕で収まります。
このデモで分かったこと
確認できたこと：
自作したゲートウェイを Apple Home が認識し、ペアリングできる
ブリッジしたデバイスを Apple Home で個別に操作できる
ダウンリンクのコマンドも、アップリンクの状態も、どちらも通る
デバイスの追加や削除、接続が切れたあとの再起動でも、Apple Home の状態が追従する
まだ確認できていないこと：
実際の Bluetooth Mesh でのプロビジョニング、暗号化、ネットワーク構築
Silicon Labs のモジュールと Telink のデバイスが相互に接続できるか
Linux のゲートウェイボード上での動作
数十から数百台のデバイスが同時にオンラインのときの挙動
言い換えると、Matter 側の半分は検証が済み、Bluetooth Mesh 側の半分は実機を待つ段階です。次のステップは、パソコンの平文アドバタイズを、シリアルポートでつないだ Bluetooth モジュールに置き換えること。ゲートウェイのプログラムから見れば、アダプター層を1つ差し替えるだけです。
おわりに
このステップで一番の収穫は、ハードウェアにお金をかける前に、いちばん肝心なことを確認できたことです。Apple Home はこのゲートウェイを受け入れてくれました。この先何か問題が起きても、少なくとも Matter の層はもう疑わなくて済みます。
同じようなゲートウェイを作っている方や、ハードウェアがない状態で先に Matter を動かしてみたい方は、ぜひ気軽に声をかけてください。コードの細かい部分やハマったポイントなど、何でも情報交換しましょう：linktr.ee
デモのコードは、小さくまとめたバージョンに整理してオープンソースにする予定です。公開したら、この記事にリンクを追記します。
この記事は ay3s.com の記事 をもとに公開しています。
Test a Matter Bridge with Apple Home Using Only a PC and a Phone
The previous post covered the overall plan: put a Matter gateway between our Bluetooth devices and Apple Home, and let it translate messages in both directions.
Plans always look tidy on paper. Before touching any hardware, I wanted to confirm one thing first: will Apple Home actually accept a gateway we wrote ourselves, and control the Bluetooth devices behind it?
That question doesn't need hardware. The development boards were still in the mail, so I used what was already on my desk, a Windows PC and a phone, and ran the whole chain end to end.
Software first, hardware second
On hardware projects it's tempting to start by buying boards, soldering modules and flashing firmware. The trouble is that with a long chain, it's hard to tell which layer broke: did Matter pairing fail, is there a bug in the gateway, did the serial link drop bytes, or is the Bluetooth signal just weak?
Getting the top two layers working in software first shrinks the search area when real hardware arrives. It also costs almost nothing: a computer and a phone are enough.
Who plays which part
| Role | In the real product | In this demo |
|---|---|---|
| Controller | Apple Home | Apple Home (the real thing) |
| Gateway | Linux board + Bluetooth module | A Windows PC using its built-in Bluetooth |
| Bluetooth device | Switches and lights | A phone running nRF Connect |
Apple Home is real, and the gateway program is the same one that will ship in the product. Only the Bluetooth device at the bottom is played by a phone.
nRF Connect is Nordic's free Bluetooth debugging app for Android and iPhone. It can scan nearby Bluetooth advertisements and send its own, which makes it a good stand-in for a device.
Why not simulate a Bluetooth Mesh device directly?
In the real product, the devices and the gateway talk SIG Mesh. A phone can't act as a Mesh device, though: neither Android nor iOS lets apps become a Mesh node. Apps like nRF Mesh can only provision devices and act as remotes.
So the demo uses something simpler: the device and the gateway exchange plain Bluetooth advertisements. To turn a light on, the gateway broadcasts "on"; when a device's state changes, it broadcasts that back to the gateway.
This format has no encryption and no replay protection. It exists only to test the chain and will never ship. Its value is that everything in the gateway except the lowest communication layer is real: Matter pairing, the device table, command translation and state sync.
The demo advertising format
The simpler the format, the better: you should be able to type it by hand into a phone app.
Gateway → device (downlink): one Manufacturer Data entry with Company ID 0xFFFF. That ID is reserved by the Bluetooth SIG for testing and must not be used in real products.
| Bytes | Content | Example |
|---|---|---|
| 1–2 | Fixed GW | 47 57 |
| 3–4 | Device address, little-endian | 02 00 means 0002 |
| 5 | On/off state | 01 on, 00 off |
| 6 | Sequence number, +1 each time | 05 |
Device → gateway (uplink): one format for Android, another for iPhone.
- Android: also Manufacturer Data, Company ID 0xFFFF, data 4456020001. 4456 is DV, 0200 is address 0002, and the final 01 means on.
- iPhone: iOS doesn't allow apps to put custom manufacturer data in advertisements, only to change the device name. So set the name to DV0002:1, meaning address 0002, on.
Parsing on the gateway side takes only a few lines and accepts both:
pub fn uplink(sections: &[(u8, Vec<u8>)]) -> Option<(u16, bool)> {
sections.iter().find_map(|(t, d)| match (*t, d.as_slice()) {
// Android: manufacturer data FF FF 'D' 'V' address state
(0xFF, [0xFF, 0xFF, b'D', b'V', a0, a1, on, ..]) => {
Some((u16::from_le_bytes([*a0, *a1]), *on != 0))
}
// iPhone: device name DV0002:1
(0x08 | 0x09, name) => {
let s = std::str::from_utf8(name).ok()?.strip_prefix("DV")?;
let (addr, on) = s.split_once(':')?;
Some((u16::from_str_radix(addr, 16).ok()?, match on {
"1" => true,
"0" => false,
_ => return None,
}))
}
_ => None,
})
}
The gateway program
The gateway is written in Rust, using the open-source rs-matter for Matter. Bluetooth on the PC goes through Windows' built-in Bluetooth APIs, so no extra drivers are needed.
Once running, the program does three things:
1. Acts as a Matter gateway: it announces itself on the local network and waits for Apple Home to pair. If it hasn't been paired yet, the pairing QR code is printed right in the terminal.
2. Maintains a device table: typing add 0002 Living room light in the terminal adds a light. Each device appears in Matter as a separate bridged device.
3. Sends and receives advertisements: commands from Apple Home become downlink advertisements; uplink advertisements from the phone update the state, which is synced back to Apple Home.
The device table and pairing data are saved to local files, so restarting the program doesn't require pairing again.
Adding it to Apple Home
Scan the terminal's QR code with the Home app on an iPhone. A few things to watch for:
- You'll see an "Uncertified Accessory" warning. During development the gateway uses the official Matter test certificates, which aren't certified, so iOS warns you. Choose "Add Anyway". Production units need real certificates issued after certification.
- The PC and the iPhone must be on the same local network, and Windows Firewall must allow the program to send and receive network traffic. If pairing times out, check this first.
- You need a home hub. Apple Home needs a HomePod or Apple TV as a home hub to control Matter accessories.
Once added, Apple Home shows a gateway with "Living room light" and "Study light" behind it, each of which can go into a different room like any other light.
Downlink: turn a light on in Apple Home
1. Open nRF Connect on the phone and go to the Scanner tab.
2. Tap "Living room light" in Apple Home.
3. The PC terminal prints BLE TX -> 0002, and the gateway broadcasts the command for one second.
4. A new device appears in nRF Connect's scan list with manufacturer data 0xFFFF and 4757 0200 01 xx, which reads "gateway says: device 0002, on".
The PC may use a different Bluetooth address for each advertisement. If it's hard to spot in the list, filter by manufacturer data or signal strength.
Uplink: the device tells Apple Home
1. In nRF Connect, create a new advertisement (Advertiser). On Android, enter manufacturer data 0xFFFF / 4456020001; on iPhone, set the device name to DV0002:1.
2. Start advertising.
3. The PC terminal prints BLE RX <- 0002 (Living room light): ON.
4. The living room light shows as on in Apple Home.
This simulates someone pressing the switch on the wall. It matters even more than the downlink: if device state can't flow back, what Apple Home shows won't match reality.
Pitfalls along the way
None of this is complicated, but a few spots are easy to get stuck on the first time.
1. The phone's advertisement turned lights back on.
The phone keeps repeating the same packet. At first the gateway updated the state every time it received one, so after turning a light off in Apple Home, the phone's "on" packet switched it back a second later. The fix was to count a report only when its content changes. Real devices need the same thing: repeated messages must be de-duplicated.
2. The iPhone puts its device name in the scan response.
When an iPhone advertises, the device name isn't in the first advertising packet but in the scan response. The PC's default passive scanning never sees it; it has to use active scanning.
3. You can't identify devices by Bluetooth address.
Phones and PCs advertise with random addresses that change periodically. So the device identity goes inside the advertisement, in those two address bytes. That matches how Mesh works: Mesh devices are identified by their assigned unicast address, not their MAC.
4. Multiple advertisements at once interfere on Windows.
Tapping several lights in a row sent several advertisements at the same time, and they overwrote one another. Queuing them, one after another, fixed it.
5. Advertising blocked Matter.
Each advertisement on Windows has to run for a while. Calling it directly inside Matter's processing loop meant every other command from Apple Home waited in the meantime. So advertising moved to its own thread.
6. Changing the gateway's manufacturer and model doesn't require re-pairing.
Apple Home reads these from the gateway and picks up new values after a restart. It does cache them, though, and there's no telling when it refreshes. If you need to see the change right away, remove and re-add the gateway, but note that removing the gateway removes every device behind it too.
Also, the freshly compiled program was fairly large at first. With size optimization and debug symbols stripped, the release build is about 2.3 MB, which fits easily on a gateway board.
What the demo proves
Proven:
- A gateway we wrote is recognized and paired by Apple Home.
- The bridged devices can be controlled individually in Apple Home.
- Downlink commands and uplink state both work.
- After adding or removing devices, or restarting after a disconnect, Apple Home stays in sync.
Not yet proven:
- Real Bluetooth Mesh provisioning, encryption and networking.
- Whether the Silicon Labs module and Telink devices work together.
- How it runs on a Linux gateway board.
- Behavior with dozens or hundreds of devices online at once.
In other words, the Matter half is verified; the Bluetooth Mesh half has to wait for real hardware. The next step is replacing the PC's plain advertisements with a Bluetooth module connected over a serial port. In the gateway program, that's just a different adapter layer.
Final thoughts
The biggest payoff from this step was confirming the most important thing before spending money on hardware: Apple Home accepts this gateway. Whatever goes wrong later, at least the Matter layer is no longer a suspect.
If you're building a similar gateway, or want to get Matter running before you have hardware, I'd be glad to talk. Code details and lessons learned are all on the table: linktr.ee
I'm cleaning up the demo code into a smaller version to open-source. I'll add the link to this post once it's out.
---
Cover image: Alejandro Escamilla, CC0 1.0.
This article was prepared for DEV with AI assistance.
Mentions
ハードなしでMatterゲートウェイを動かす：PCとスマホだけでApple Home連携 前回の記事では全体の構成を紹介しました。Bluetooth デバイスと Apple Home のあいだに Matter ゲートウェイを置き、ゲートウェイに双方のメッセージを翻訳してもらう、という形です。 構成は紙の上ならいくらでもきれいに描けます。実際に手を動かす前に、まず確かめておきたいことがありました。自作したゲートウェイを Apple Home はちゃんと認識してくれるのか、そしてその配下の Bluetooth デバイスを操作できるのか？ これはハードウェアがなくても確認できます。開発ボードはまだ配送中だったので、手元にあった Windows パソコンとスマホだけで、経路全体を通しで動かしてみました。 まずはソフトウェアで、ハードウェアはそのあと ハードウェアのプロジェクトだと、つい最初にボードを買って、モジュールをはんだ付けして、ファームウェアを焼きたくなります。ただ、経路が長くなると、問題が起きたときにどの層が悪いのか切り分けにくいんですよね。Matter のペアリングが失敗したのか、ゲートウェイにバグがあるのか、シリアル通信でバイトが落ちたのか、それとも Bluetooth の電波が弱いだけなのか。 先にソフトウェアで上の2層を通しておけば、実機に切り替えたときに疑うべき範囲がぐっと狭まります。しかもコストはほぼゼロ。パソコンとスマホがあればできます。 誰が何の役を演じるか 役割 実際の製品では 今回のデモでは コントローラー Apple Home Apple Home（本物） ゲートウェイ Linux ゲートウェイボード + Bluetooth モジュール Windows パソコン（内蔵の Bluetooth を使用） Bluetooth デバイス スイッチ、照明 スマホ（nRF Connect を使用） Apple Home は本物で、ゲートウェイのプログラムも後で製品に載せるものと同じです。一番下の「Bluetooth デバイス」だけをスマホが演じています。 nRF Connect は Nordic が出している無料の Bluetooth デバッグツールで、Android にも iPhone にもあります。周囲の Bluetooth アドバタイズをスキャンできるだけでなく、自分でアドバタイズを出すこともできるので、デバイス役にちょうどいいんです。 なぜ Bluetooth Mesh デバイスを直接シミュレートしないのか 実際の製品では、デバイスとゲートウェイのあいだは SIG Mesh で通信します。ただ、スマホは Mesh デバイスを演じられません。Android も iOS も「Mesh ノードになる」機能を公開していないからです。nRF Mesh のようなアプリは、プロビジョニング用のツールやリモコンとしてしか使えません。 そこでデモでは、もっと単純な方法に切り替えました。デバイスとゲートウェイのあいだは、平文の Bluetooth アドバタイズで直接やりとりするという方法です。ゲートウェイが照明をつけたいときは「オン」をアドバタイズし、デバイスの状態が変わったら、その内容をゲートウェイに向けてアドバタイズします。 この形式は暗号化もリプレイ対策もしていないので、経路の検証専用で、製品には使いません。それでも価値があるのは、一番下の通信方式を除けば、ゲートウェイの中身がすべて本物だからです。Matter のペアリング、デバイステーブル、コマンドの変換、状態の同期、どれも本物のまま検証できます。 デモ用のアドバタイズ形式 形式はシンプルなほどよく、スマホアプリで手打ちして組み立てられるくらいがちょうどいいです。 ゲートウェイ → デバイス（ダウンリンク）：製造者固有データ（Manufacturer Data）を1つ使い、Company ID は 0xFFFF にします。これは Bluetooth SIG がテスト用に確保している番号で、正式な製品には使えません。 バイト 内容 例 1～2 固定の GW 47 57 3～4 デバイスアドレス（リトルエンディアン） 02 00 は 0002 5 オン/オフの状態 01 がオン、00 がオフ 6 シーケンス番号（毎回 +1） 05 デバイス → ゲートウェイ（アップリンク）：Android と iPhone でそれぞれ書き方が違います。 Android：同じく製造者固有データで、Company ID は 0xFFFF、データは 4456020001 にします。4456 が DV、0200 がアドレス 0002、最後の 01 がオンを表します。 iPhone：iOS ではアプリがアドバタイズに独自の製造者固有データを載せられず、できるのはデバイス名の変更だけです。そこでデバイス名を DV0002:1 にします。意味はアドレス 0002、オンです。 ゲートウェイ側のパースは数行で済み、どちらの書き方にも対応しています。 pub fn uplink(sections: &[(u8, Vec<u8>)]) -> Option<(u16, bool)> { sections.iter().find_map(|(t, d)| match (*t, d.as_slice()) { // Android：製造者固有データ FF FF 'D' 'V' アドレス 状態 (0xFF, [0xFF, 0xFF, b'D', b'V', a0, a1, on, ..]) => { Some((u16::from_le_bytes([*a0, *a1]), *on != 0)) } // iPhone：デバイス名 DV0002:1 (0x08 | 0x09, name) => { let s = std::str::from_utf8(name).ok()?.strip_prefix("DV")?; let (addr, on) = s.split_once(':')?; Some((u16::from_str_radix(addr, 16).ok()?, match on { "1" => true, "0" => false, _ => return None, })) } _ => None, }) } ゲートウェイのプログラム ゲートウェイは Rust で書いていて、Matter まわりにはオープンソースの rs-matter を使っています。パソコン側の Bluetooth 送受信は Windows 標準の Bluetooth API を呼んでいるので、追加のドライバーは要りません。 起動すると、プログラムは次の3つのことをします。 Matter ゲートウェイとして振る舞う：ローカルネットワーク上に自分の存在を知らせ、Apple Home からのペアリングを待ちます。まだペアリングしていなければ、ペアリング用の QR コードがターミナルにそのまま表示されます。 デバイステーブルを管理する：ターミナルで add 0002 リビングの照明 と入力すると、照明が1つ追加されます。各デバイスは Matter 上では独立した「ブリッジデバイス」になります。 Bluetooth アドバタイズを送受信する：Apple Home から来たコマンドはダウンリンクのアドバタイズに変換して送り出し、スマホからのアップリンクのアドバタイズをスキャンしたら、状態を更新して Apple Home に同期します。 デバイステーブルとペアリング情報はローカルのファイルに保存されるので、プログラムを再起動してもペアリングし直す必要はありません。 Apple Home に追加する iPhone の「ホーム」アプリでターミナルの QR コードを読み取れば追加できます。注意点がいくつかあります。 「認証されていないアクセサリ」という警告が出ます。開発中は Matter 公式のテスト用証明書を使っていて、認証を受けていないため、iOS が警告を出すんです。「このまま追加」を選べば大丈夫です。量産時には、認証を取った正式な証明書に差し替える必要があります。 パソコンと iPhone は同じローカルネットワークに接続しておく必要があります。また、Windows ファイアウォールでこのプログラムの通信を許可しておいてください。ペアリングがタイムアウトするときは、まずここを確認しましょう。 ホームハブが必要です。Apple Home で Matter デバイスを操作するには、HomePod か Apple TV をハブとして用意しておく必要があります。 追加に成功すると、Apple Home にゲートウェイが1つ現れ、その配下に「リビングの照明」と「書斎の照明」がぶら下がります。普通の照明と同じように、それぞれ別の部屋に振り分けることもできます。 ダウンリンク：Apple Home から照明をつける スマホで nRF Connect を開き、スキャン（Scanner）画面に入ります。 Apple Home で「リビングの照明」をタップします。 パソコンのターミナルに BLE TX -> 0002 と1行表示され、ゲートウェイがそのコマンドを1秒間アドバタイズします。 nRF Connect のスキャン一覧にデバイスが1つ増え、製造者固有データは 0xFFFF に 4757 0200 01 xx が続く形になります。つまり「ゲートウェイから、0002 番のデバイスをオンに」という意味です。 パソコンはアドバタイズのたびに別の Bluetooth アドレスを使うことがあります。一覧から探しにくいときは、製造者固有データか電波強度で絞り込んでみてください。 アップリンク：デバイスから Apple Home に伝える nRF Connect で新しいアドバタイズ（Advertiser）を作ります。Android なら製造者固有データに 0xFFFF / 4456020001 を入力し、iPhone ならデバイス名を DV0002:1 にします。 アドバタイズを開始します。 パソコンのターミナルに BLE RX <- 0002 (リビングの照明): ON と表示されます。 Apple Home のリビングの照明がオンの状態に変わります。 これは、ユーザーが壁のスイッチを押した状況を再現したものです。ダウンリンクよりもこちらのほうが大事かもしれません。デバイスの状態が戻ってこないと、Apple Home の表示が実際の状態とずれてしまうからです。 ハマったところ 全体としては難しい作業ではありませんが、初めてだと詰まりやすいところがいくつかありました。 1. スマホのアドバタイズした状態が、消したばかりの照明をまたつけてしまう。 スマホは同じパケットを延々と繰り返し送り続けます。最初はゲートウェイが受信のたびに状態を更新していたので、Apple Home で照明を消しても、1秒後にスマホの「オン」のパケットで元に戻されてしまいました。内容が変わったときだけ1回の報告として扱うように直したところ、解決しました。実機でも同じで、重複したメッセージは必ず除去する必要があります。 2. iPhone のデバイス名はスキャンレスポンスに入っている。 iPhone がアドバタイズするとき、デバイス名は最初のアドバタイズパケットではなく「スキャンレスポンス」に入っています。パソコンのデフォルトであるパッシブスキャンでは受け取れないので、アクティブスキャンに切り替える必要があります。 3. Bluetooth アドレスではデバイスを識別できない。 スマホもパソコンも、アドバタイズにはランダムアドレスを使っていて、しばらくすると変わってしまいます。そのため、デバイスの身元はアドバタイズの内容、つまりあの2バイトのアドレスに持たせました。これは Mesh の考え方とも一致しています。Mesh のデバイスも MAC ではなく、割り当てられたユニキャストアドレスで識別されます。 4. Windows では複数のアドバタイズを同時に出すと干渉する。 照明を続けて何回かタップすると、複数のアドバタイズが同時に出て、お互いに上書きし合ってしまいました。キューに入れて、1件送り終えてから次を送る方式に変えています。 5. アドバタイズの送信で Matter が止まる。 Windows ではアドバタイズを1回出すのにしばらく時間がかかります。Matter の処理の流れの中で直接呼ぶと、その間は Apple Home から来る他のコマンドがすべて待たされてしまいます。そこで、アドバタイズの送信は別のスレッドに切り出しました。 6. ゲートウェイの製造元や型番を変えても、ペアリングし直す必要はない。 これらの情報は Apple Home がゲートウェイから読み取っているので、ゲートウェイを再起動すれば新しい値が反映されます。ただ、Apple Home にはキャッシュがあり、いつ更新されるかはよく分かりません。すぐに確認したいなら、削除して追加し直すしかありません。ただし、ゲートウェイを削除すると、配下のデバイスもすべて一緒に消えるので注意してください。 ちなみに、ビルドしたてのプログラムは最初かなり大きかったのですが、サイズ優先の最適化にしてデバッグ情報を削ったところ、リリースビルドは 2.3 MB ほどになりました。ゲートウェイボードのストレージには余裕で収まります。 このデモで分かったこと 確認できたこと： 自作したゲートウェイを Apple Home が認識し、ペアリングできる ブリッジしたデバイスを Apple Home で個別に操作できる ダウンリンクのコマンドも、アップリンクの状態も、どちらも通る デバイスの追加や削除、接続が切れたあとの再起動でも、Apple Home の状態が追従する まだ確認できていないこと： 実際の Bluetooth Mesh でのプロビジョニング、暗号化、ネットワーク構築 Silicon Labs のモジュールと Telink のデバイスが相互に接続できるか Linux のゲートウェイボード上での動作 数十から数百台のデバイスが同時にオンラインのときの挙動 言い換えると、Matter 側の半分は検証が済み、Bluetooth Mesh 側の半分は実機を待つ段階です。次のステップは、パソコンの平文アドバタイズを、シリアルポートでつないだ Bluetooth モジュールに置き換えること。ゲートウェイのプログラムから見れば、アダプター層を1つ差し替えるだけです。 おわりに このステップで一番の収穫は、ハードウェアにお金をかける前に、いちばん肝心なことを確認できたことです。Apple Home はこのゲートウェイを受け入れてくれました。この先何か問題が起きても、少なくとも Matter の層はもう疑わなくて済みます。 同じようなゲートウェイを作っている方や、ハードウェアがない状態で先に Matter を動かしてみたい方は、ぜひ気軽に声をかけてください。コードの細かい部分やハマったポイントなど、何でも情報交換しましょう：linktr.ee デモのコードは、小さくまとめたバージョンに整理してオープンソースにする予定です。公開したら、この記事にリンクを追記します。 この記事は ay3s.com の記事 をもとに公開しています。
Test a Matter Bridge with Apple Home Using Only a PC and a Phone The previous post covered the overall plan: put a Matter gateway between our Bluetooth devices and Apple Home, and let it translate messages in both directions. Plans always look tidy on paper. Before touching any hardware, I wanted to confirm one thing first: will Apple Home actually accept a gateway we wrote ourselves, and control the Bluetooth devices behind it? That question doesn't need hardware. The development boards were still in the mail, so I used what was already on my desk, a Windows PC and a phone, and ran the whole chain end to end. Software first, hardware second On hardware projects it's tempting to start by buying boards, soldering modules and flashing firmware. The trouble is that with a long chain, it's hard to tell which layer broke: did Matter pairing fail, is there a bug in the gateway, did the serial link drop bytes, or is the Bluetooth signal just weak? Getting the top two layers working in software first shrinks the search area when real hardware arrives. It also costs almost nothing: a computer and a phone are enough. Who plays which part | Role | In the real product | In this demo | |---|---|---| | Controller | Apple Home | Apple Home (the real thing) | | Gateway | Linux board + Bluetooth module | A Windows PC using its built-in Bluetooth | | Bluetooth device | Switches and lights | A phone running nRF Connect | Apple Home is real, and the gateway program is the same one that will ship in the product. Only the Bluetooth device at the bottom is played by a phone. nRF Connect is Nordic's free Bluetooth debugging app for Android and iPhone. It can scan nearby Bluetooth advertisements and send its own, which makes it a good stand-in for a device. Why not simulate a Bluetooth Mesh device directly? In the real product, the devices and the gateway talk SIG Mesh. A phone can't act as a Mesh device, though: neither Android nor iOS lets apps become a Mesh node. Apps like nRF Mesh can only provision devices and act as remotes. So the demo uses something simpler: the device and the gateway exchange plain Bluetooth advertisements. To turn a light on, the gateway broadcasts "on"; when a device's state changes, it broadcasts that back to the gateway. This format has no encryption and no replay protection. It exists only to test the chain and will never ship. Its value is that everything in the gateway except the lowest communication layer is real: Matter pairing, the device table, command translation and state sync. The demo advertising format The simpler the format, the better: you should be able to type it by hand into a phone app. Gateway → device (downlink): one Manufacturer Data entry with Company ID 0xFFFF. That ID is reserved by the Bluetooth SIG for testing and must not be used in real products. | Bytes | Content | Example | |---|---|---| | 1–2 | Fixed GW | 47 57 | | 3–4 | Device address, little-endian | 02 00 means 0002 | | 5 | On/off state | 01 on, 00 off | | 6 | Sequence number, +1 each time | 05 | Device → gateway (uplink): one format for Android, another for iPhone. - Android: also Manufacturer Data, Company ID 0xFFFF, data 4456020001. 4456 is DV, 0200 is address 0002, and the final 01 means on. - iPhone: iOS doesn't allow apps to put custom manufacturer data in advertisements, only to change the device name. So set the name to DV0002:1, meaning address 0002, on. Parsing on the gateway side takes only a few lines and accepts both: pub fn uplink(sections: &[(u8, Vec<u8>)]) -> Option<(u16, bool)> { sections.iter().find_map(|(t, d)| match (*t, d.as_slice()) { // Android: manufacturer data FF FF 'D' 'V' address state (0xFF, [0xFF, 0xFF, b'D', b'V', a0, a1, on, ..]) => { Some((u16::from_le_bytes([*a0, *a1]), *on != 0)) } // iPhone: device name DV0002:1 (0x08 | 0x09, name) => { let s = std::str::from_utf8(name).ok()?.strip_prefix("DV")?; let (addr, on) = s.split_once(':')?; Some((u16::from_str_radix(addr, 16).ok()?, match on { "1" => true, "0" => false, _ => return None, })) } _ => None, }) } The gateway program The gateway is written in Rust, using the open-source rs-matter for Matter. Bluetooth on the PC goes through Windows' built-in Bluetooth APIs, so no extra drivers are needed. Once running, the program does three things: 1. Acts as a Matter gateway: it announces itself on the local network and waits for Apple Home to pair. If it hasn't been paired yet, the pairing QR code is printed right in the terminal. 2. Maintains a device table: typing add 0002 Living room light in the terminal adds a light. Each device appears in Matter as a separate bridged device. 3. Sends and receives advertisements: commands from Apple Home become downlink advertisements; uplink advertisements from the phone update the state, which is synced back to Apple Home. The device table and pairing data are saved to local files, so restarting the program doesn't require pairing again. Adding it to Apple Home Scan the terminal's QR code with the Home app on an iPhone. A few things to watch for: - You'll see an "Uncertified Accessory" warning. During development the gateway uses the official Matter test certificates, which aren't certified, so iOS warns you. Choose "Add Anyway". Production units need real certificates issued after certification. - The PC and the iPhone must be on the same local network, and Windows Firewall must allow the program to send and receive network traffic. If pairing times out, check this first. - You need a home hub. Apple Home needs a HomePod or Apple TV as a home hub to control Matter accessories. Once added, Apple Home shows a gateway with "Living room light" and "Study light" behind it, each of which can go into a different room like any other light. Downlink: turn a light on in Apple Home 1. Open nRF Connect on the phone and go to the Scanner tab. 2. Tap "Living room light" in Apple Home. 3. The PC terminal prints BLE TX -> 0002, and the gateway broadcasts the command for one second. 4. A new device appears in nRF Connect's scan list with manufacturer data 0xFFFF and 4757 0200 01 xx, which reads "gateway says: device 0002, on". The PC may use a different Bluetooth address for each advertisement. If it's hard to spot in the list, filter by manufacturer data or signal strength. Uplink: the device tells Apple Home 1. In nRF Connect, create a new advertisement (Advertiser). On Android, enter manufacturer data 0xFFFF / 4456020001; on iPhone, set the device name to DV0002:1. 2. Start advertising. 3. The PC terminal prints BLE RX <- 0002 (Living room light): ON. 4. The living room light shows as on in Apple Home. This simulates someone pressing the switch on the wall. It matters even more than the downlink: if device state can't flow back, what Apple Home shows won't match reality. Pitfalls along the way None of this is complicated, but a few spots are easy to get stuck on the first time. 1. The phone's advertisement turned lights back on. The phone keeps repeating the same packet. At first the gateway updated the state every time it received one, so after turning a light off in Apple Home, the phone's "on" packet switched it back a second later. The fix was to count a report only when its content changes. Real devices need the same thing: repeated messages must be de-duplicated. 2. The iPhone puts its device name in the scan response. When an iPhone advertises, the device name isn't in the first advertising packet but in the scan response. The PC's default passive scanning never sees it; it has to use active scanning. 3. You can't identify devices by Bluetooth address. Phones and PCs advertise with random addresses that change periodically. So the device identity goes inside the advertisement, in those two address bytes. That matches how Mesh works: Mesh devices are identified by their assigned unicast address, not their MAC. 4. Multiple advertisements at once interfere on Windows. Tapping several lights in a row sent several advertisements at the same time, and they overwrote one another. Queuing them, one after another, fixed it. 5. Advertising blocked Matter. Each advertisement on Windows has to run for a while. Calling it directly inside Matter's processing loop meant every other command from Apple Home waited in the meantime. So advertising moved to its own thread. 6. Changing the gateway's manufacturer and model doesn't require re-pairing. Apple Home reads these from the gateway and picks up new values after a restart. It does cache them, though, and there's no telling when it refreshes. If you need to see the change right away, remove and re-add the gateway, but note that removing the gateway removes every device behind it too. Also, the freshly compiled program was fairly large at first. With size optimization and debug symbols stripped, the release build is about 2.3 MB, which fits easily on a gateway board. What the demo proves Proven: - A gateway we wrote is recognized and paired by Apple Home. - The bridged devices can be controlled individually in Apple Home. - Downlink commands and uplink state both work. - After adding or removing devices, or restarting after a disconnect, Apple Home stays in sync. Not yet proven: - Real Bluetooth Mesh provisioning, encryption and networking. - Whether the Silicon Labs module and Telink devices work together. - How it runs on a Linux gateway board. - Behavior with dozens or hundreds of devices online at once. In other words, the Matter half is verified; the Bluetooth Mesh half has to wait for real hardware. The next step is replacing the PC's plain advertisements with a Bluetooth module connected over a serial port. In the gateway program, that's just a different adapter layer. Final thoughts The biggest payoff from this step was confirming the most important thing before spending money on hardware: Apple Home accepts this gateway. Whatever goes wrong later, at least the Matter layer is no longer a suspect. If you're building a similar gateway, or want to get Matter running before you have hardware, I'd be glad to talk. Code details and lessons learned are all on the table: linktr.ee I'm cleaning up the demo code into a smaller version to open-source. I'll add the link to this post once it's out. --- Cover image: Alejandro Escamilla, CC0 1.0. This article was prepared for DEV with AI assistance.
@MunshiShastri i don't use android lol, i use apple, tty logging is literally just done with tee or script, and i really doubt "my code" is anything major here, let's see show me what you've contribbed, i believe you for apparmor but not the rest: project-chip/connectedhomeip android.googlesource.com
The best part of Matter being open. You can find the pull requests where things like commissioning a device before power on exists: connectedhomeip#40783