The previous post got the Matter half working with nothing more than a PC and a phone. Next comes the other half of the gateway: what protocol should the gateway and the Bluetooth devices actually speak?
Our devices originally used a Bluetooth advertising protocol we defined ourselves, controlled through our own app. It had run for a long time without trouble. So early in the project, someone on the team asked: do we really need SIG Mesh?
That question deserves its own post, because "skipping SIG Mesh" can mean two very different things with very different consequences.
First, what does "skipping it" mean?
Option one: don't use the SIG Mesh protocol. The devices keep their proprietary advertising protocol, and the gateway speaks it too.
Option two: use the SIG Mesh protocol but skip Bluetooth SIG qualification. Technically follow the standard, just don't register or pay with the SIG.
The first is a technical choice; the second is a compliance question. A lot of debates go nowhere because they mix the two up. Let's cover the technology first and qualification later.
Four ways to connect devices to a gateway
| Approach | Coverage | Number of devices | Interoperability | Security | Effort |
|---|---|---|---|---|---|
| Proprietary advertising | Around the gateway only, no relaying | No hard limit | Only your own products | All on you | Small |
| Direct BLE connections (each device connects to the gateway) | Around the gateway only | Limited by concurrent connections, usually a dozen or so | Fair | Standard encryption | Medium |
| Home-grown proprietary mesh | Relaying possible | Depends on implementation | Only your own products | All on you | Very large |
| SIG Mesh | Relaying, whole-home coverage | Hundreds of nodes are fine | Works across vendors | Standard encryption and replay protection | Medium, mostly in the chip SDK |
Proprietary advertising is the simplest: to turn on a light, the gateway broadcasts a command and the device acts on it. But there's no relaying. If the gateway is in the living room, the bedroom light may never hear it. Provisioning, encryption and replay protection all have to be designed and maintained by you.
Direct BLE connections work like a phone and a pair of Bluetooth earbuds. Encryption is standard, but a gateway can only hold a limited number of connections at once, nowhere near the dozens of switches and lights in a typical home.
A home-grown proprietary mesh means reinventing SIG Mesh. Controlling relay storms, de-duplicating messages, rotating keys, protecting sequence numbers against replay: every one of them is a trap. Plenty of vendors built their own mesh in the early days; most have since moved to SIG Mesh.
SIG Mesh is the Bluetooth SIG's standard. Devices relay for each other and cover the whole house, the security model is already there, and, most importantly, it defines a standard set of device models.
Where SIG Mesh really pays off: standard models
SIG Mesh specifies how common devices such as switches and lights are described and controlled:
| SIG Mesh model | Device | Matter equivalent |
|---|---|---|
| Generic OnOff | Switches, plugs | On/Off Light |
| Light Lightness | Dimmable lights | Dimmable Light |
| Light CTL | Tunable white lights | Color Temperature Light |
| Light HSL | Color lights | Extended Color Light |
This table matters enormously for a gateway. Matter has device types that map almost one to one, so the translation is very direct. With a proprietary protocol, you'd have to define that mapping yourself and revisit it for every new device type.
Standard models bring two more benefits:
- The gateway and the devices can use chips from different vendors. Our gateway uses a Silicon Labs module and our devices use Telink chips. As long as both follow the standard models, they work together, and no single chip vendor locks us in.
- Other ecosystems become easier to join. Xiaomi's Bluetooth Mesh, for example, is built on SIG Mesh, and its light and switch templates use these same models. A Xiaomi version later on could reuse most of the application code, replacing mainly the provisioning and authentication layer.
What SIG Mesh costs you
SIG Mesh isn't free; most of the cost has simply been paid by someone else already.
The protocol is complex. Provisioning uses ECDH key exchange, messages are encrypted at both the network and transport layers, and there's segmentation, sequence numbers and the IV Index. All of that lives in the chip vendor's SDK and has already passed SIG testing. On the device side, use the SDK; don't write your own.
Network size has limits. SIG Mesh forwards messages by flooding relays, so the more nodes in one area, the more crowded the air gets. As a rule of thumb, a network performs best with a few hundred nodes or fewer. Commercial lighting with thousands of points needs to be split by floor or zone into several networks and gateways.
The gateway can only store so many nodes. This is easy to overlook:
- Telink's official gateway firmware stores up to 200 nodes by default, or 110 with remote provisioning enabled. A four-gang switch counts as one node, not four.
- If you build a gateway on Nordic's Zephyr stack, the default configuration allows only 8 nodes, with a replay-protection list of just 10 entries. Leave it unchanged and messages from the 11th device will start failing.
Two hundred nodes is plenty for a home, but check these numbers during design.
A device belongs to only one network. The same light can't be managed by our gateway and by a Xiaomi hub at the same time. Supporting both ecosystems means two product versions, provisioned separately.
Can you skip SIG qualification?
Back to the second meaning of the original question: using SIG Mesh without Bluetooth SIG qualification.
Technically it makes no difference. The devices work normally and interoperate with other SIG Mesh devices. The risks are elsewhere:
| Risk | Details |
|---|---|
| Patent license | The SIG patent license only covers qualified products |
| Sales channels | Amazon and other platforms, large retailers and overseas distributors often ask for a Bluetooth qualification ID |
| SIG enforcement | The SIG notifies unqualified products and asks for qualification or withdrawal |
| Trademark | You can't use the "Bluetooth" name or logo on packaging or marketing |
A common misunderstanding: going back to a proprietary protocol doesn't avoid SIG qualification. Any product that uses Bluetooth needs qualification to be sold, Mesh or not. Without Mesh, you simply skip the Mesh-specific tests.
The good news is that qualification doesn't necessarily mean retesting. If you use a stack the chip vendor has already qualified, without modifying its qualified parts, you can reference their qualification and just submit a declaration and pay the fee. If the Bluetooth design of the switches, lights and wireless switches is identical, they can share one design and one fee.
Note also that radio certifications such as SRRC, CE and FCC are legal requirements and separate from SIG qualification. Without them, the product can't be sold legally. A later post will cover certification costs and order.
On the gateway side, where does Mesh live?
On the devices, using the chip SDK is uncontroversial. On the gateway, the Mesh stack can live in one of three places:
| Approach | How it works | Pros and cons |
|---|---|---|
| Implement Mesh in the gateway program | Use the Linux board's own Bluetooth to send and receive Mesh advertisements | One chip fewer, but thousands of lines of protocol stack to write and your own qualification testing |
| Bluetooth module as a co-processor | The Mesh stack runs on the module; the main program sends commands over UART | Proven stack and the vendor's qualification can be referenced; one extra module |
| Module as a plain Bluetooth controller | The module runs standard HCI; Mesh runs on Linux (for example BlueZ) | Off-the-shelf module firmware, but no development on Windows |
We chose the second: a Bluetooth module as a co-processor. The hardest, most qualification-sensitive part of Mesh stays with the chip vendor, and we handle only the serial commands and the Matter translation. Which vendor's module makes the best co-processor is the subject of the next post.
Final thoughts
So, can you skip SIG Mesh?
- Not using the SIG Mesh protocol: possible, but you lose relaying, standard security and cross-vendor interoperability, and you still need Bluetooth qualification.
- Using SIG Mesh without qualification: functionality is unaffected, but exports, online marketplaces and major retail channels are effectively off-limits.
For us, the biggest value of SIG Mesh isn't the word "standard". It's a set of device models that map almost one to one onto Matter. That keeps the gateway's translation layer simple and leaves us free to choose our chips.
If your devices still use a proprietary protocol and you're weighing a move to SIG Mesh, or you're already building a Bluetooth Mesh gateway, I'd be glad to talk: linktr.ee/weiyii
Cover image: Japanwikisan, CC BY 4.0.
This article was prepared for DEV with AI assistance.
