Bluetooth Mesh Provisioning Succeeded—Why Won’t the Light Respond?

A device appears in scan results. Clicking Add displays a successful log entry, and the gateway receives a new entry. Expectations are high, but sending an On command yields no response. The temptation is to attribute the issue to radio coverage, chip compatibility, or serial framing. However, in SIG Mesh, a critical consideration arises before attempting a solution: joining a network does not guarantee the device is configured for application participation.

The previous article examined transforming custom advertising into a multihop network. Now, we revisit the standard process, following a controller adding a light through discovery, provisioning, key management, model binding, and publish/subscribe. This explanation aims to clarify the mechanisms involved, rather than providing a finished hardware test report or a vendor-specific guide.

Discovery alone indicates a device's presence. An unprovisioned device can broadcast an Unprovisioned Device Beacon, prompting discovery by a phone or gateway. The component serving as the Provisioner then initiates the provisioning process. The Provisioner role is not limited to a phone or bound permanently to the gateway. One product may combine provisioning, configuration, and everyday control within a single application, but separating these responsibilities aids in understanding the protocol.

Identifying an advertisement does not confirm the device's intended light. The installer must still perform identity confirmation and the correct security procedure among several identical lights in proximity. Buttons, product-supplied information, or supported input/output authentication may be necessary for selection.

Provisioning involves more than merely setting a password. The Provisioner and device exchange capabilities, select a mutually supported authentication method, perform public-key exchanges, and achieve the necessary authentication to securely join the network. Proper input/output capabilities, authentication choices, and implementation all play crucial roles.

Even with encrypted communication, confirming the device's intended identity remains essential. Following the establishment of identity, the device becomes a Mesh node with an initial NetKey, IV Index, allocated unicast addressing, and its DevKey. The DevKey is derived independently by both sides and does not travel as plaintext.

Its purpose differs from the shared NetKey, serving to protect configuration communication for that specific node.

While treating NetKey, AppKey, and DevKey as interchangeable Bluetooth passwords simplifies troubleshooting, it can lead to confusion. Each key serves distinct purposes: the NetKey ensures network/subnet security and processing, the AppKey safeguards application messages and supports model binding, and the DevKey protects configuration communication for that particular node.

Recognizing their separate responsibilities helps avoid troubleshooting pitfalls. Relaying traffic does not imply the node possesses the authority or correct model to execute commands. An AppKey Index appearing in logs represents an index, not the key itself. Matching indices in different contexts do not confirm identical key material or context.

Verification of mappings should be done using trusted configuration records, ensuring real keys and their proper context remain undisclosed in ordinary logs or screenshots.

Understanding the composition of elements, their models, and relevant capabilities is crucial before attempting to control a device. One enclosure may contain multiple elements, each implementing various models. In a multichannel controller, carefully inspect the actual composition rather than assuming every channel resides in the primary element or that an OnOff command from the primary address controls all outputs.

Proper address allocation must reserve space for elements and prevent collisions between nodes. In our example, identifying the light's element and verifying its implementation of the Generic OnOff Server is necessary. The Configuration Client communicates with the node's Configuration Server to inspect and modify settings. The composition data clarifies elements, their models, and relevant capabilities.

Each node, element, and model represents a distinct level, and one enclosure may contain several independently described elements, each implementing multiple models.

For a multichannel controller, inspecting the actual composition is essential. Avoid assuming every channel exists in the primary element or that the primary address plus an OnOff command controls all outputs. Allocation of addresses must ensure adequate space for elements and prevent collisions among nodes. In our example, identifying the light's element and confirming its implementation of the Generic OnOff Server is necessary.

The controller must send corresponding messages and handle the required status responses. Discovering or provisioning a device does not guarantee support for the desired application model. Increasing transmit power cannot resolve a model mismatch. The AppKey Add and Model App Bind operations must be performed separately. Adding the required AppKey to the target node with the correct NetKey association is the first step.

Subsequently, binding that AppKey to the application model that necessitates it completes the process. Neither step can replace the other. A stored key does not automatically grant permission to every model to process its protected messages. Binding the incorrect element or model may alter configuration without rendering the intended light controllable.

The sender must also possess the appropriate key and model configuration. Configuring only the lamp does not establish the comprehensive communication relationship. Similarly, not every model utilizes AppKey binding. Configuration models rely on DevKey and should not be treated like lighting models. The Silicon Labs Configuration Client API separates adding an AppKey and binding a model into distinct steps, providing result events for each.

Although a successful host function return does not automatically signify completion of every subsequent stage, careful attention to the selected SDK's result handling and verification of node, element, model, and status are essential. A timeout indicates an uncertain outcome, requiring further investigation.