Custom Mesh, SIG Mesh and Xiaomi Mesh: How They Relate

When building Bluetooth devices and gateways, one question inevitably appears: which kind of Mesh should we use?

A chip supplier offers a Mesh SDK, a module vendor advertises SIG Mesh, the product team wants Xiaomi Home support, and the developers may already maintain a proprietary advertising protocol. Everyone says “Mesh,” but they may be solving different problems.

In the earlier Matter gateway article, I discussed proprietary protocols and SIG Mesh from the device-integration perspective. This series looks more closely at the Bluetooth side. Custom Mesh, SIG Mesh and Xiaomi Mesh are not three entirely parallel protocol choices.

Custom Mesh describes who designs and controls the networking mechanism. SIG Mesh refers to an open Bluetooth networking standard. Xiaomi Mesh also involves how a product enters Xiaomi Home, is identified, and works through gateways and platform services. Separating those layers makes selection much easier.

First, what does your “Mesh” actually do?

Imagine a controller in the living room and a lamp in the bedroom. At short range, sending a command directly is straightforward. Behind several walls, however, the message may no longer arrive. We want a device in the hallway to forward it. Mesh networking concerns this cooperation between nodes, together with addressing, forwarding and network management.

Broadcasting once to many receivers does not, by itself, create a Mesh network. A custom BLE advertising protocol without multihop forwarding is still a broadcast-control solution. It may suit one room perfectly, but it cannot automatically reach beyond radio coverage.

Conversely, a “Mesh” label does not mean every device forwards messages. Roles, power supply and firmware configuration determine that. Before comparing solutions, ask whether they use direct connections, broadcasting or multihop forwarding—and, in the last case, which nodes relay messages and how endless repetition is prevented.

Custom Mesh: freedom comes with responsibility

There is no single specification for “proprietary Mesh.” Vendors can use different packets, forwarding rules, addresses and enrollment procedures. One implementation cannot represent all of them.

If you own the devices, controller and application, you can tailor the protocol to a focused product. A lighting-only system need not cover a wide range of general device models immediately. Existing products may also require continued compatibility with an older protocol.

Adding relaying brings further questions:

How are duplicate messages identified when they arrive along several paths, and how is repeated execution avoided?
When should forwarding stop, and which devices should relay?
How does a new device authenticate and receive keys? Can a removed device still control the network?
How does replay protection survive a power cycle?
How is radio traffic controlled when many devices report or respond together?

You can implement these mechanisms yourself or buy a module vendor’s proprietary solution. Buying reduces engineering work but creates dependencies: can you replace the gateway, maintain firmware and obtain the protocol documentation? Those questions belong in the initial discussion.

Proprietary Mesh is not inherently faster, cheaper or insecure. Its suitability depends on the implementation, product boundaries and maintenance capacity. Comparing only the time needed to light the first lamp overlooks the following years.

SIG Mesh: common rules for networking, security and behavior

SIG Mesh normally means Bluetooth Mesh, standardized by the Bluetooth SIG. It is based on Bluetooth LE, rather than being a chain of ordinary Bluetooth connections.

The standard covers provisioning, addressing, message delivery, security and application-level device behavior. The official Bluetooth Mesh Networking primer provides a detailed introduction. Three ideas are particularly useful.

Joining a network is followed by configuration

Provisioning securely brings an unprovisioned device into a network, assigns addresses and establishes the necessary security information. Application keys, model bindings, publication and subscription relationships must then be configured.

Discovering, adding and successfully controlling a device are therefore different states. Radio visibility does not mean a device is authorized to receive a particular command.

Relaying a message does not mean understanding its application data

SIG Mesh distinguishes the network key, NetKey, from application keys, AppKeys. The former enables network-layer participation in the corresponding subnet; the latter protect application messages.

A node can consequently relay traffic without receiving control rights for every application. Helping a lighting message reach its destination does not necessarily authorize that node to control the lights. Products must still configure, store and update keys correctly. Standard mechanisms do not eliminate implementation or operational mistakes.

Models give “turn on” a shared meaning

Standard models such as Generic OnOff, Light Lightness and Light CTL define behavior related to switching, brightness and color temperature. Devices can understand messages and states according to common rules, rather than merely receive bytes.

SIG Mesh also permits Vendor Models for functions not covered by standard models. A proprietary application command does not automatically imply a proprietary Mesh network underneath. A device can use standard networking and security while implementing vendor-specific features. Always ask which layer is proprietary.

Why SIG Mesh does not guarantee out-of-the-box interoperability

The earlier gateway article emphasized the value of standard models across vendors. That value depends on the actual capabilities and configuration of the products.

Two lamps may both advertise SIG Mesh. One exposes switching through a standard model; the other also offers special effects through a Vendor Model. A generic controller might operate the basic switch without understanding every effect.

You also need a supported way to provision devices into a network you manage and configure their keys, models and subscriptions. Using a standard does not require a manufacturer to expose all provisioning and management capabilities to arbitrary third-party controllers.

Question	What must be checked
Can it join and participate in the network?	Provisioning method, management rights, keys and required node features
Can it perform a particular operation?	Matching models, messages, states and configuration
Can it work in the target platform over time?	Platform integration, device identity, function mapping, firmware maintenance and support

The SIG primer discusses optional features, configuration flexibility and interoperability, and introduces Bluetooth NLC device profiles that further constrain device behavior. Standards provide common foundations; product compatibility still needs validation for the intended functions.

Xiaomi Mesh adds the Xiaomi Home integration system

Treating Xiaomi Mesh as a wireless protocol unrelated to SIG Mesh misses the relationship. Xiaomi’s public Bluetooth Mesh integration guide distinguishes SIG Mesh models and messages from MIoT Spec, Xiaomi’s description of product services, properties and operations. The gateway translates between them.

Its color-temperature lamp example includes standard models such as Generic OnOff Server and Light Lightness Server alongside Xiaomi models. Standard Mesh and ecosystem extensions can coexist in one device.

That is an older guide: its chip lists and procedures should not be treated as current development requirements. The current BLE Mesh basics documentation still describes Spec-to-Mesh translation and specifies product templates, firmware configuration and property reporting requirements.

Using SIG Mesh and joining Xiaomi Home are therefore separate objectives. The first concerns technical foundations; the second also involves product identity, platform definitions, provisioning and binding, gateway support and presentation of functions.

Renaming an ordinary SIG Mesh device will not make it appear in Xiaomi Home. Likewise, buying a Xiaomi Home Bluetooth Mesh lamp does not guarantee that your own generic gateway can take over all its functions.

Before choosing a chip or writing application code for a Xiaomi Home version, confirm current support for the product category, SDK access and target gateway capabilities. These requirements shape the product; integration is usually more than a final interface added before release.

“Works without a gateway” and “works offline” are different questions

Properly configured SIG Mesh nodes can exchange local messages without sending every switch command to an internet service. The intended function must actually be implemented in the nodes and local configuration.

A finished product depends on its control path. Xiaomi’s current BLE Mesh guide says remote control requires a Mesh gateway, while Bluetooth direct control can be developed for use without one. “Can be developed” does not mean every shipping product includes identical direct-control capabilities.

The same guide says non-low-power devices can relay messages but cannot control each other in the described solution. Relaying helps a message arrive; control requires application functionality. Do not generalize this statement into an unchanging rule for all Xiaomi products and versions.

I would test three situations separately:

Disconnect the internet while keeping the router, gateway and devices powered. Does local control and automation continue?
Turn off the gateway. Which physical switches, device interactions or nearby phone controls remain available?
Restart devices and the gateway. Are states and control relationships restored correctly?

These are different failures. One successful offline switching test cannot establish that the whole system is independent of gateways and cloud services.

Node counts and latency do not provide a ready-made ranking

Capacity and response time matter, but a Mesh label alone cannot answer either question.

Classic SIG Mesh forwarding uses Managed Flooding, which is not unconditional repetition by every device. Relay configuration, TTL and message caching regulate it. Mesh 1.1 introduced Directed Forwarding, using path-related mechanisms to improve efficiency. Support and activation depend on the stack and configuration.

Battery-operated devices should not be assumed to act as constantly available relays. Low Power and Friend mechanisms let low-power nodes reduce continuous reception while a Friend temporarily stores messages. Saving energy affects delivery timing, so battery life must be considered alongside interaction requirements.

Device placement, reporting frequency, relay count, retransmissions and application load are more useful than an isolated maximum-node number. A few devices reporting frequently create different pressure from many lamps occasionally receiving a group command.

Later articles will examine concrete arrangements, messages and metrics. Without common test conditions, there is no defensible ranking of which solution is faster or more reliable.

Choose what you need to control and maintain

Direction	Main purpose	Responsibility or prerequisite
Custom/proprietary Mesh	Tailor communication and networking to a product	Protocol quality, security, maintenance, supplier dependence and integration costs
SIG Mesh	Use common networking, security and device-model standards	Stack capabilities, model compatibility, provisioning, configuration and interoperability tests
Xiaomi Mesh integration	Bring eligible devices into Xiaomi Home	Current platform process, product definition, SDK, identity, binding and gateway support

This is not necessarily an exclusive choice. A product can use SIG Mesh and implement Xiaomi Home requirements, use SIG Mesh with a privately managed gateway and application, or retain a proprietary solution for existing products and specific needs.

For our Mesh-to-Matter gateway, standard models provide useful boundaries: define the Bluetooth device behavior first, then map devices and states into Matter. That mapping must handle supported functions, state changes and recovery. Similar model names do not finish the bridge for us.

If the objective is integrating existing Xiaomi Home products, start with their permitted integration methods and available capabilities. If you also own device firmware, you can design models, key management and gateway interfaces together. Those starting points imply very different workloads.

Next: what must be added to a custom Bluetooth broadcast protocol to build a real multihop Mesh? We will examine duplicates, forwarding limits, acknowledgements and security before deciding whether to build it ourselves.

If you work on Bluetooth devices, lighting or gateways, get in touch. Device counts, power arrangements and the intended platform make a more useful starting point than “I want Mesh.”