Tags
- BGM13S22F512GA
- RF Hardware
- Bluetooth Low Energy Reference Designs
- BGM11S12F256GA
- Modules
- Audio and Radio
- BGM123A256
- Bluegiga Legacy Wi-Fi Modules
- Bluetooth Low Energy Kits
- EFR32BG1B232F128GM48
- BLE112
- Blue Gecko Bluetooth Low Energy SoCs
- Mighty Gecko Modules
- Bluetooth Low Energy
- Starter Kits
- Bluetooth Classic
- BGM121A256
- Wi-Fi
- Bluetooth SDK
- bluetooth-low-energy-accessories
- Bluetooth Low Energy SDK
- User Guides
- Schematic and Layout Files
- Communications
- Knowledge Base Articles
- BGX13S22GA-V21
- MGM13S02F512GA
- Simplicity Studio
- Thunderboard Sense
- Blue Gecko Bluetooth Low Energy Modules
Top Authors
Archives
- 2015 August
- 2015 October
- 2015 November
- 2015 December
- 2016 January
- 2016 April
- 2016 May
- 2016 June
- 2016 July
- 2016 August
- 2016 September
- 2016 October
- 2016 November
- 2016 December
- 2017 January
- 2017 February
- 2017 March
- 2017 April
- 2017 May
- 2017 June
- 2017 July
- 2017 August
- 2017 September
- 2017 November
- 2017 December
- 2018 January
- 2018 February
- 2018 March
- 2018 April
- 2018 May
- 2018 June
- 2018 July
- 2018 August
- 2018 September
- 2018 November
- 2018 December
- 2019 January
- 2019 February
- 2019 March
- 2019 April
- 2019 June
- 2019 July
- 2019 September
KBA_BT_0501: BT Mesh embedded provisioner example
Introduction
This article includes a code example that implements a Bluetooth mesh provisioner that can be run on one of our Bluetooth capable development kits.
To understand how the provisioning and configuration of mesh nodes works, it is recommended that you first try out the mesh Android app as explained in the quickstart guide QSG148.
The example presented in this article can perform the same operations as the mobile app but it is more autonomous and requires only minimal input from the user. When the provisioner sees an unprovisioned beacon, it prints the UUID of this device to the debug console and then you can either:
- push button PB1 to provision and configure the device (*
- push button PB0 to ignore this beacon and continue scanning for other beacons (*
*) Alternatively, you can press key 'y' / 'n' on the terminal to provision or ignore the found device (starting from version v6)
The purpose of this example is to show how the Silicon Labs BT mesh stack can be used in provisioning mode. The main steps in provisioning and configuration are summarized below, along with a list of related API calls.
NOTE: This example is intended only for small scale experimental use. It is not meant to be used as a basis for any production use and the code.
Known limitations:
Provisioning and configuration basic steps
The main steps included in provisioning a device into the network and configuring the node are summarized in the following table. This is just a compact list of what operations and API calls are involved in the process. More detailed information about provisioning and configuration in Bluetooth mesh can be found in:
gecko_evt_mesh_prov_initialized_id
gecko_cmd_mesh_prov_create_appkey
gecko_evt_mesh_prov_unprov_beacon_id
gecko_cmd_mesh_prov_provision_gatt_device,
gecko_evt_mesh_prov_device_provisioned_id
gecko_cmd_mesh_config_client_get_dcd,
gecko_evt_mesh_config_client_dcd_data_id,
gecko_evt_mesh_config_client_dcd_data_end_id
gecko_cmd_mesh_config_client_add_appkey,
gecko_evt_mesh_config_client_appkey_status_id
gecko_cmd_mesh_config_client_bind_model,
gecko_evt_mesh_config_client_binding_status_id
gecko_evt_mesh_config_client_model_pub_status_id
gecko_evt_mesh_config_client_model_sub_status_id
Code example
The sample code is attached in a zip file. The zip file includes a readme.txt file that explains step-by-step how this code can be installed on top of one of the examples in the Bluetooth mesh SDK.
Version history:
Modified to work with Mesh SDK 1.4.0.
Max number of SIG models increased to 16.
Some sanity checks added.
Option to provision using PB-GATT,
Option to use fixed application and network keys
Update (28th Feb 2019): added package prov_example_v6_SDK-140_new_API.zip . The example code has been modified to use the new config client API introduced in SDK 1.4.0 (deprecated calls removed from the code).
Latest code package attached, small modifications to make this work with Mesh SDK 1.4.0 (+ some sanity checks added).
Updated code package, modified to work with Mesh SDK 1.3.0.
Hey Jaakko,
I noticed that you specifically avoid calling gecko_cmd_mesh_prov_model_app_bind() on Model ID 0x0000 (Configuration Server). Attempting to do so results in an error. Should this always be followed? Why do we not need to bind model id 0x0000?
Thanks,
Bobby
Hi Bobby,
to be honest, I did not pay any attention to the Configuration Server model. Now that you asked, I checked the BLE mesh profile specification and it says on page 195: (4.4.1 Configuration Server model)
So the reason you don't need to bind this model is because it implicitly uses the device key for app.level security.
Hello,
I'm having problems while using this code (v4 on MESH SDK v1.3.1). This is the error I get when attempting to provision a node:
Sometimes, it simply gets stuck at:
Can you tell me what can be wrong?
Thanks,
TC
@Tiago yes, the code is originally written to support up to 8 SIG models and up to 4 vendor models. I thought it would be enough for most basic use cases, but based on your log you had 9 models in your DCD which slightly exceeds the limit.
I will add a note about this in the "known limitations" section, thanks for pointing this out!
@JaakkoV Thanks for this provisioner code.
I have merged the switch and light examples into one and everything appears to be working fine after provisioning with this code. However, the nodes "loose" their subscriptions after a reset and stop receiving messages from other nodes which are sending requests . This does not happen when I use the mobile app to provision the nodes, although the app has other limitations (with the app, a node can only be a light or a switch, but not both at the same time). Is this a known issue?
@Tiago no, this is not a known issue. I suspect it may have something to do with high number of sub/pub settings you are using.
In the memory configurator, there is an option to control the maximum number of subscriptions, see following screenshot:
Please check that your combined light/switch node is not exceeding this limit and adjust if needed.
Have you monitored the debug prints from the node when you do a reset? Is there any error reported there? After reset, is the node still provisioned or does it lose all configuration data? (I.e.. does it return to unprovisioned mode?)
@JaakkoV Yes, but I'm currently only using 2 APP Binds, 2 PUBs and 2 SUBs per node. Nevertheless, increasing the max subscriptions and max app binds in the memory configurator was my first approach. However, I had no luck. The subscriptions are lost when the nodes are reset.
On reset, the node does not print out any error (do I need to enable any special debug flag?).
When I first merged both examples, the nodes would loose all configuration data upon a reset (they would become unprovisioned). But after removing additional stuff from the code now I have this weird behavior of missing subscriptions.
Do I need to adjust any other memory settings, like stack or heap (I've also already increased these) ?
I have tried using latest example prov_example_v4_SDK-130.zip. My observation is that this example worked only for provisioning one device.
Then for next device ,it gets stuck. Is it already known behaviour ?