Mesh Model

What Is a Mesh Model?

A Mesh Model is a standardized specification that defines the behavior, states, and messages for a specific function within a Bluetooth Mesh node. Models are the application-layer building blocks of mesh functionality -- they determine what a node can do (turn a light on/off, report a temperature, control a motor) and how it communicates those capabilities to other nodes.

Model Types

Bluetooth Mesh defines three categories of models:

SIG Models -- standardized by the Bluetooth SIG with assigned 16-bit Model IDs. These ensure interoperability across vendors. Examples:

Vendor Models -- custom models defined by a specific company, identified by a 32-bit Model ID (16-bit Company ID + 16-bit Model ID). Vendor models allow proprietary features while coexisting with SIG models on the same node.

Foundation Models -- special SIG models present on every mesh node:

• Configuration Server (0x0000) -- manages NetKeys, AppKeys, subscriptions, and publications. The provisioner communicates with this model to configure the node.
• Health Server (0x0002) -- reports fault conditions and responds to attention requests (e.g., blinking an LED to help identify a physical node).

States and Messages

Each model defines one or more states (e.g., "OnOff" with values On/Off, "Level" with -32,768 to 32,767) and the messages used to get, set, or subscribe to those states. Messages follow a consistent naming pattern:

• Get -- request the current state (e.g., Generic OnOff Get).
• Set -- change the state with acknowledgment (e.g., Generic OnOff Set).
• Set Unacknowledged -- change the state without acknowledgment.
• Status -- the response to a Get or Set, also used for publish-subscribe status updates.

Model Composition

A mesh node is composed of one or more elements, each containing one or more models. A single element cannot contain two instances of the same model, but different elements on the same node can. For example, a dual-channel dimmer has two elements, each with a Light Lightness Server model.

The Composition Data page (read via the Configuration Server) describes all elements and models on a node, allowing the provisioner to understand the node's capabilities programmatically.

Model Bindings

Models interact with other models through state bindings. When two models share a bound state, changing the state through one model automatically updates the other. For example, the Light Lightness Server binds its Lightness state to the Generic Level Server's Level state. Setting the level to 50% through the Generic Level Client also sets lightness to 50% through the Light Lightness Server.

AppKey Binding

Each model must be bound to at least one Application Key (AppKey) before it can send or receive messages. This binding is configured by the provisioner after provisioning using the Model App Bind message. A model can be bound to multiple AppKeys, and the same AppKey can be shared across models. This mechanism provides fine-grained access control: a lighting AppKey can be separate from an HVAC AppKey, even within the same node.