Mesh Pub/Sub

Publish-Subscribe

<\/script>\n
'; }, get iframeSnippet() { const domain = '{ SITE_DOMAIN }'; const type = '{ embed_type }'; const slug = '{ embed_slug }'; return ''; }, get activeSnippet() { return this.method === 'script' ? this.scriptSnippet : this.iframeSnippet; }, copySnippet() { navigator.clipboard.writeText(this.activeSnippet).then(() => { this.copied = true; setTimeout(() => { this.copied = false; }, 2000); }); } }" @keydown.escape.window="open = false" @click.outside="open = false">

Embed This Widget

Theme


      
    

Widget powered by . Free, no account required.

Bluetooth Mesh addressing model where nodes publish messages to group addresses and other nodes subscribe to receive them.

Also known as: Pub/Sub

What Is Publish-Subscribe in Bluetooth Mesh?

Publish-Subscribe (Pub/Sub) is the addressing and message-routing model used in Bluetooth Mesh to decouple message senders from receivers. Nodes publish messages to designated addresses, and other nodes subscribe to those addresses to receive them. This decoupling enables flexible, scalable automation without requiring nodes to know each other's unicast addresses.

How It Works

Each mesh model on a node has a publication address -- the address to which it sends state changes or status messages. The publication address can be a group address, a virtual address, or even a unicast address. Independently, other nodes configure their models' subscription list with one or more group or virtual addresses. When a publishing node sends a message to a group address, all nodes subscribed to that address receive and process it.

Example: Smart Lighting

Consider a commercial office with 50 light fixtures and 10 wall switches:

  1. The provisioner creates a group address 0xC001 for "Floor 3 Lights."
  2. All 50 light fixtures subscribe their Generic OnOff Server models to 0xC001.
  3. All 10 wall switches set their Generic OnOff Client publication address to 0xC001.
  4. When any switch publishes a "Turn On" message to 0xC001, all 50 lights receive it and turn on.

No switch needs to know the unicast address of any light. Adding or removing lights requires only updating their subscription, not reconfiguring the switches.

Group Addresses vs. Virtual Addresses

Feature Group Address Virtual Address
Size 16-bit (0xC000 -- 0xFEFF) 128-bit ATT">UUID, hashed to 16-bit
Capacity 16,128 addresses Virtually unlimited
Configuration Assigned by provisioner Generated from UUID
Use case Simple zone/room grouping Fine-grained, cross-vendor interop

Group addresses are sufficient for most deployments. Virtual addresses are useful when multiple independent systems share the same mesh network and need non-colliding address spaces.

Publication Parameters

Each model's publication settings include:

  • Address -- the destination for published messages.
  • AppKey Index -- which Application Key encrypts the message.
  • TTL -- the initial Time-to-Live for published messages.
  • Period -- optional periodic publishing interval (e.g., sensor reports every 30 seconds).
  • Retransmit Count/Interval -- how many times and how often to retransmit each published message for reliability.

These parameters are configured remotely via the Configuration Client model after provisioning.

Scalability Benefits

The Pub/Sub model scales elegantly. A single sensor can publish temperature readings to a group address, and any number of display panels, HVAC controllers, and cloud gateways can subscribe independently. Adding a new subscriber requires no change to the publisher. This loose coupling is a fundamental advantage over point-to-point BLE connections, where adding a new consumer requires firmware changes on the data source.

Related Terms

Frequently Asked Questions

Our glossary covers 90+ BLE technical terms organized by category. Each term includes a definition, related terms, and links to relevant chips and guides.