Make a mesh provisioner node visible through GATT

[Peseur]

Hello all,

I am working on an application that involves two types of device inside a mesh network: devices that have to be provisionned (server) and devices that provision (client). Servers are also visible through "classic" BLE (GATT) and can be DFUed using OTA. I believe that this happens "magically" thanks to mesh_provisionee_prov_start method. i don't know exactly what make the node, "broadcasts" its name inside the method. On the other side, the client devices use the "provisioner_init" method, from the prov_helper file. But when I Init the provisioner, I can't see its name broadcasting. I want to be able to OTA my servers. How can I make a device at the same time provisioner and broadcasting its name in GATT ?

Thank for you help

[tesc]

Hi,

It sounds like there is some confusion here. There are some different concepts:

The first concept is provisioner / provisionee. The provisioner is used for creating a mesh network, and for provisioning other devices into the network. We call the device a node when it has been provisioned. In order for a network to use multiple provisioners, those provisioners must share the configuration database of the mesh network. Bluetooth SIG has specified a json format for sharing the mesh configuration database, but there is no specification for how to share this file. Our nRF Mesh app for iOS and for Android can export and import this format, but we do not have an implementation for the SoC.

All Bluetooth mesh devices must support the provisionee role, which means they can be provisioned into a Bluetooth mesh network and become a node. This role is automatically handled by the mesh stack, and you should not change the provisionee behaviour of the node.

The second concept is node configuration. All Bluetooth mesh devices are required to have a configuration model server, which is used for configuring the node. Some devices (usually the provisioner) have a configuration client, which is used for configuring other nodes. For accessing the configuration server of a node, one must have the device key for that node. This key is known to the provisioner.

The third concept is DFU. DFU support has nothing to do with mesh_provisionee_prov_start, which rather is related to the process of becoming provisioned into a network, in nRF5 SDK for Mesh.

Please note that for new projects we recommend the nRF Connect SDK. The older nRF5 SDK and nRF5 SDK for Mesh are now in maintenance mode. Read more about the SDKs and their state in our nRF Connect SDK and nRF5 SDK statement.

For more on mesh concepts, see https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/ug_bt_mesh_concepts.html

For more on DFU, see https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/mcuboot/readme-ncs.html

Regards,
Terje

[Peseur]

Thanks for your response,  I thought I had roughly understood concepts around the mesh, but you provided me some useful points, that have leaded me to better specify what I am trying to achieve.

I can't move to nRF connect SDK because my app relies on older nrf5 SDK and nrf5 SDK for Mesh.

My main goal is to DFU OTA my provisioner using nRF connect app.

My previous issue was that I was unable to find my provisioner in the scan result using nRF connect app. At the office, there are a lot of BLE devices that advertise, making the scan result quite noisy. My target device was actually present in the list, but was hard to find because of other devices and because its name was not set. So nothing to do with the mesh_provisionee_prov_start as you said.

So I can see my device in the list but I have two issues right now:

- The GATT name of the device is "N/A", while I have called the sd_ble_gap_device_name_set method during init.
- nRF connect does not offer a connect button for my device

I have already implemented many times DFU on nRF devices and the point 2 is quite surprising for me. I will check out again my buttonless DFU services/characteristic implementation.

In contrast, for the point 1, I have no idea. Maybe could you point me in the right direction ?

Thanks for your help

[tesc]

Hi,

1. (GATT name): If this is from the scanning, then it could be related to advertising settings/flags. You should be able to check the advertising packet using e.g. nRF Connect for Desktop BLE app, or use nRF Sniffer for a sniffer trace, to see what is sent in the advertising packet.

2. (No connect button): There might be something wrong with the characteristics on the device. Using nRF Connect for mobile or nRF Connect for Desktop BLE app you should be able to see the services and characteristics on the device. If there is a DFU service, then the apps should show a DFU button, but if there is no DFU service or there is something wrong with it then the button will not show.

Regards,
Terje

[Peseur]

Hello, yes my 2 devices have very diferent advertising flags.

The first screenshot is the device that work as intended, the second device is the one I can't connect toand whose name is not set. I understand the problem is at a lower level but I am suprised it is so hard to get an available GATT device when the device is provisioner.

[tesc]

Hi,

The one sending a "Beacon type: Secure Network" is a device which has been provisioned into a network. Nodes on a Bluetooth mesh network send secure network beacons such that collectively, at any place in the network, you are expected to see one such beacon every 10 seconds (on average).

The one sending a "Beacon type: Unprovisioned Device" is a device which has not yet been provisioned into a network. It therefore is in a different state, where it is not (yet) part of a Bluetooth mesh network.

If one is working and the other is not, then you might have succeeded in your implementation for one state, but not for the other.

By the way, neither of the two advertisements shown in your screenshots look like advertisements for a DFU service. How do you connect to the functioning device, for performing the DFU?

Regards,
Terje