How to Bring Bluetooth Devices into Apple Home with a Matter Bridge
No new chip in every device: one Matter gateway bridges Bluetooth Mesh switches and lights into Apple Home. Our architecture, key choices and next steps.
I’ve been working on a project that brings a range of Bluetooth devices into Apple Home.
The devices themselves are simple: wall switches with one to four gangs, dimmable lights, tunable and color lights, plus a stick-on wireless switch. They form a Bluetooth Mesh network and have always been controlled through our own app, which works fine.
The pressure comes from customers. The question we hear most is: “Can I control it with Apple Home?” Google Home and Home Assistant usually come up next.
Apple, Google and Amazon have all been pushing Matter. People now expect to manage every device in the house from one app, and products without Matter support will only get harder to sell.
This post is the overview for the whole project: why we chose this approach, what the architecture looks like and how far we’ve got. Later posts will cover the chips, the main processor, the protocol stack and certification one at a time.
Two options: new chips in every device, or one gateway
There are broadly two ways to get Bluetooth devices into Matter.
Option one: change the devices. Replace every device’s chip with a Thread or Wi-Fi solution that supports Matter, rewrite the firmware, then certify each model for Matter separately.
Option two: leave the devices alone and add a gateway. On one side, the gateway talks to the devices over Bluetooth. On the other, it joins the home network as a Matter device. Apple Home sees one Matter gateway with a list of switches and lights behind it. The Matter specification calls this kind of device a Bridge.
| Change the devices | Add a gateway | |
|---|---|---|
| Device cost | A more expensive chip in every unit | Unchanged |
| Firmware work | Rewrite for every model | Small device changes; most work is in the gateway |
| Matter certification | Every model separately | The gateway, once |
| Devices already sold | Left behind | Can join after a firmware update |
| Extra purchase for users | None | One gateway |
We have many models, low unit prices and plenty of devices already installed in people’s homes. Redesigning every device wasn’t realistic, so we chose the gateway.
The trade-offs are just as clear. Users have to buy one more box, and if the gateway loses power or its connection, the whole Bluetooth network is affected. Both points have to be addressed head-on in the design.
The architecture
The system has four layers, from top to bottom:
Apple Home / Google Home / Home Assistant
│ Matter (Wi-Fi or Ethernet)
▼
[Linux gateway]
├─ Matter Bridge: each switch and light is a device
├─ Device table: devices, gangs, online status
├─ Mapping layer: Matter commands ↔ Mesh messages
└─ Mesh adapter: drives the Bluetooth module
│ UART
▼
[Bluetooth module] provisioning, Mesh messages
│ Bluetooth SIG Mesh
▼
switches / dimmable lights / color lights / wireless switches- At the top are the smart home platforms. They only speak Matter and don’t know there’s Bluetooth underneath.
- The gateway board runs Linux and a single program. Outwardly it’s a Matter gateway; inwardly it manages every Bluetooth device.
- The Bluetooth module is a separate chip. The Bluetooth Mesh stack runs on the module, and the Linux host sends it instructions over a serial port.
- At the bottom are the devices, using the Bluetooth SIG’s standard Mesh protocol, SIG Mesh.
The main benefit of this split is that the Bluetooth and Matter halves can be debugged and replaced independently. Changing the main processor later doesn’t touch the Bluetooth module or the device firmware; switching Bluetooth module vendors only affects the adapter layer.
The most important layer: translation
The real work happens in the mapping layer. It translates Matter device types and commands into messages that Bluetooth Mesh understands.
| Our device | Shown in Apple Home as | What needs converting |
|---|---|---|
| 1–4 gang switch | One switch per gang (On/Off Light) | Nothing |
| Dimmable light | Dimmable Light | Matter level 1–254, Mesh lightness 0–65535 |
| Tunable white light | Color Temperature Light | Matter uses mireds: 1,000,000 divided by the Kelvin value |
| Color light | Extended Color Light | Hue and saturation use different ranges |
| Wireless switch | Generic Switch | Short, long and double presses become Matter button events |
A four-gang switch appears in Apple Home as four separate switches, each of which can go into a different room or scene. That’s the standard way Bridges work, and it’s also the easiest for users to understand.
The translation itself isn’t hard. Two easily overlooked details are.
The first is physical buttons. When someone presses the switch on the wall, the state in Apple Home has to change too. So every device reports its new state to the gateway whenever it changes, and the gateway syncs it to Matter. Handling “the app controls the device” is only half the job; “the device tells the app” matters just as much.
The second is going offline. If a light loses power at the wall, Apple Home should show “No Response” instead of the last known state. Each device sends the gateway a regular heartbeat, and if several in a row are missed, it’s marked offline.
One more design choice is about user experience: the wireless switch controls the lights directly, without going through the gateway. The switch sends its command to the room’s group address, the lights respond directly, and the gateway just listens in to keep the state in sync. Even if the gateway drops off the network or fails, the switch on the wall still turns the lights on. The gateway should add convenience, not become a single point of failure.
Key decisions
Several parts of the design were settled only after a lot of comparison. Here are the conclusions; the reasoning gets its own posts.
- SIG Mesh between the devices and the gateway, not a proprietary protocol. The standard defines models for switches and lights, so the gateway and the devices can use chips from different vendors and still work together as long as both follow it.
- A Silicon Labs module in the gateway, Telink chips in the devices. For the gateway, documentation and tooling matter most: the Silicon Labs module can run as a co-processor, and its serial protocol is properly documented. For the devices, cost and the Chinese supply chain matter most, which favors Telink.
- The main processor depends on the job. For bridging alone, an entry-level chip such as Rockchip’s RK3506 is enough. With headroom for local automation or a web admin page, choose the RK3562. With a screen as a control panel, move up to the RK3576.
- rs-matter, written in Rust, for the Matter stack. It builds into a single small program and supports adding and removing devices at runtime, which suits a Bridge well.
Where things stand
What’s done so far is a software prototype:
- A Windows PC simulates the gateway and was added to Apple Home by scanning its code.
- A phone simulates a Bluetooth device. The gateway discovers it, and it appears in Apple Home as a controllable device.
- Switching it in Apple Home sends the command to the simulated device. When devices are added or removed, they appear or disappear in Apple Home.
In other words, the Matter ↔ gateway ↔ Bluetooth device chain works in software, and Apple Home recognizes and controls the bridged devices.
What isn’t done yet is real hardware: testing the Silicon Labs module with Telink devices and running everything on a Linux gateway board. The development boards are on order, and that’s the focus for the next few weeks.
Problems still to solve
These questions decide whether the design can go into production, and each will get its own post:
- Do the two vendors’ chips work together? A Silicon Labs gateway with Telink devices should work over the standard protocol, but it needs testing on real boards.
- How many devices can one gateway handle? A few dozen in a home is no problem; commercial installations can easily exceed a hundred and need load testing.
- What if the gateway fails? After a power cut, a reboot or a replaced Bluetooth module, devices that were already set up must come back on their own, without users pairing them again.
- Certification. Matter certification, HomeKit-related requirements and radio certification: what each costs and which comes first.
Final thoughts
Getting Bluetooth devices into Matter is less mysterious than it sounds. The time goes into choosing chips, keeping device state in sync, planning for gateway failures, and the certification work you can’t avoid before production.
I’ll keep writing up this project, topic by topic, from prototype to production, including the wrong turns.
If you have Bluetooth devices you want to bring into Matter, or you’re building a similar gateway, I’d be glad to talk. Design ideas, chip choices and lessons learned are all on the table: linktr.ee/weiyii