Provisioner example

The provisoner example is the default Mesh network configurator. It works in a fixed, predefined way and can be used as the static provisioner with the following examples:

• Dimming examples
• EnOcean switch translator client example
• Light switch example
• Light lightness example
• Light LC server example
• Light CTL example

Table of contents

• Usage of Mesh APIs
• Hardware requirements
• Setup
  • LED and button assignments
• Testing the example

Because of the asynchronous nature of the provisioning and configuration process, the provisioner is implemented as a multi-layered state machine. The application provisions and configures devices when it receives unprovisioned beacons from them.

Every supported example has a unique Uniform Resource Identifier (URI) included in the beacons. The provisioner example uses URI hash to understand the type of example being provisioned and select the suitable configuration to be applied to the node after provisioning. For this reason, this provisioner can provision devices only with the known URI. The list of URIs is predefined.

The static provisioner has its own limitations and is provided as a tool to evaluate SDK examples without the need to use a mobile application provisioner. If you are using a mobile application for provisioning, you can see the models present on the device and configure the nodes accordingly. Moreover, you can also use more sophisticated automated provisioners that can use the UUID, URI, and the device composition data to understand which devices are being provisioned and configure them automatically.

The device being provisioned is configured depending on whether it has the client or the server part of the models:

• For client, two instances of the models are instantiated on different elements. The first model instance is subscribed to the odd group address (0xC005), and the second one is subscribed to the even group address (0xC004). Similarly, these model instances are assigned publish addresses of 0xC003 and 0xC002 respectively.
• For server, only the subscription and publication addresses are set, depending on whether the unicast address of the node is even or odd. Models on the nodes with even address publish to 0xC004 and are subscribed to the address 0xC002. Models on the nodes with odd address publish to 0xC005 and are subscribed to the address 0xC003.

The following diagram shows how the provisioner configures Mesh examples.

Typical configuration of Mesh examples by the provisioner

The following diagram shows the typical state transitions of the provisioner while provisioning and configuring a light switch client.

Light switch client state diagram

For more information on how a provisioning process works, see the provisioning guide.

---

Usage of Mesh APIs

The provisioner uses the following set of APIs:

• Application support API modules
• Management API module
• Core mesh stack API
• Provisioning API
• Configuration client API

The provisioner role is much more complex than the provisionee role, both in terms of resource requirements and application complexity. For these reasons, there is no simple API for the provisioning and configuration process.

However, for a specific use case, the API usage can be reduced into a set of simple steps, as implemented in the provisioner example:

1. Initialize:
   1. Core mesh stack.
   2. Device state manager.
   3. Access layer.
   4. Load provisioner persistent data.
2. Listen for unprovisioned beacons.
3. Provision the device.
4. Configure the device.
5. If more devices should join the network, go back to step 2.

In the example code, this behavior is split between the following modules:

• examples/provisioner/src/main.c – deals with the initialization and setup of the mesh stack.
• examples/provisioner/src/provisioner_helper.c – deals with the provisioning process.
• examples/provisioner/src/node_setup.c – deals with the configuration process of the node once the provisioning is completed.

The following figure shows the details of how provisioning and configuration are implemented with the provided APIs. Note that the figure may simplify some API calls to provide a clearer picture. See the relevant source files for details.

Provisioning and configuring devices

---

Hardware requirements

You need one of the supported boards for the provisioner, in addition to the boards required by the example you are using the provisioner with.

See Compatibility for the supported boards.

---

Setup

You can find the source code of the mesh provisioner in the following folder: <InstallFolder>/examples/provisioner

LED and button assignments

The buttons (1 to 4) are used to initiate certain actions, and the LEDs (1 to 4) are used to reflect the status of actions as follows:

• Button 1: Start provisioning.
• Button 4: Clear all the states and reset the node.
• LED 1: Reflects the state of the provisioning.
  • LED ON: Provisioning of the node is in progress.
  • LED OFF: No ongoing provisioning process.
• LED 2: Reflects the state of the configuration.
  • LED ON: Configuration of the node is in progress.
  • LED OFF: No ongoing configuration process.

---

Testing the example

There is no standalone testing procedure for the provisioner example. You need to use this example together with one of the examples that use the static provisioner example.

After building the example by following the instructions in Building the mesh stack, see the following sections, depending on the example you are using:

• Evaluating the light switch example using the static provisioner
• Evaluating the experimental dimming examples using the static provisioner
• Evaluating the EnOcean switch example using the static provisioner
• Evaluating the light lightness example using the static provisioner
• Evaluating the light LC server example using the static provisioner
• Evaluating the Light CTL example using the static provisioner