Remote provisioning from all devices on the mesh

[rmarques]

I am using mesh SDK v4.2.0.

I read the documentation of the remote provisioning example (pb_remote) and took look at the code.

My first feeling was that the remote provisioning in this example is done through a specific device on the mesh that implements the pb_remote_server and is chosen to start the process using the device that implements the pb_remote_client, most likely the provisioner device.

Before a detailed reading of this example, I thought the provisioner just flooded the mesh with provisioning messages and all devices repeated those messages and could add a new device to the mesh. While the provisioning data is indeed passed through the mesh as I expected to, only one specific device, the one chosen by the pb_remote_client, seems to be able to convey the message on the last jump to the new unprovisioned device.

How can the provisioner know beforehand the best device to choose as the final messager? Is it possible to activate many pb_remote_servers at the same time? Do we need to alternate which device is scanning for unprovisioned devices periodically? I think there might be many ways of doing this, so I am asking for advice, or correction if I understood something wrong.

[Mttrinh]

Hi, 

Sorry for the late reply. 

You are correct, a specific remote provisioning server is used for actually provisioning each unprovisioned device. There is nothing stopping you from having a lot of these in the network however, possibly on every node. In addition, choosing the "best" server for provisioning a new device is not really neccessary, any device which picks up the unprovisioned beacon should do.

[Mttrinh]

Hi, 

pb remote client can work only with one pb remote server at a time. Dynamically changing publication address of the client will lead to incorrect state of both the server and the client. You can only change pb remote client publication (and thus run provisioning on another pb remote server) when it's state is IDLE.

So what you can do is that you can set publication to one server and do scanning through that server. Once scanning is finished (either by canceling scanning or if server reaches the limit of maximum stored UUIDs defined by PB_REMOTE_SERVER_UUID_LIST_SIZE), you will get PB_REMOTE_EVENT_SCAN_CANCELED event on the client. Now you can change the publication address to another server or start provisioning. If the provisioning process is started, you can't change the client's publication address until the provisioning is completed.

[rmarques]

I'm calling pb_remote_client_remote_scan_cancel in a timer handler that is triggered 30 seconds after I start the scan from the first server but I'm getting NRF_ERROR_INVALID_STATE since p_client->state != PB_REMOTE_CLIENT_STATE_IDLE obviously. Is it safe to force it to PB_REMOTE_CLIENT_STATE_IDLE before calling pb_remote_client_remote_scan_cancel?

I don't mind experimenting and customizing the SDK to my needs, I'm just asking so I don't lose time implementing a workflow that was already well thought by you guys. Thanks!

[rmarques]

My mistake, the client should be in PB_REMOTE_CLIENT_STATE_IDLE when the server is scanning. The problem was in my application, I was determining the mesh address of the servers wrongly, and the client did not receive the ACK message from the server because there was none in that address, so it was permanently in the wait for ack state.

[Mttrinh]

Glad it worked out for you :)