Remote provisioning from all devices on the mesh

RE: Remote provisioning from all devices on the mesh

Mttrinh — Tue, 11 May 2021 16:06:05 GMT

Glad it worked out for you :)

RE: Remote provisioning from all devices on the mesh

rmarques — Tue, 11 May 2021 11:52:52 GMT

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.

RE: Remote provisioning from all devices on the mesh

rmarques — Mon, 10 May 2021 17:19:51 GMT

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!

RE: Remote provisioning from all devices on the mesh

Mttrinh — Thu, 06 May 2021 16:27:14 GMT

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.

RE: Remote provisioning from all devices on the mesh

rmarques — Mon, 03 May 2021 15:46:18 GMT

Hi, I returned to the development of the remote provisioner and while I got it working, I cannot start multiple remote scans at the same time. From my interpretation of the code, this is not natively possible.

Currently I am cycling through all active nodes in the mesh network, first setting/changing the publish address of the pb_remote_client with the dsm to the address of the pb_remote_server in that node and then initiating the scan with pb_remote_client_remote_scan_start.

pb_remote_client_remote_scan_start only returns NRF_SUCCESS if the client state is PB_REMOTE_CLIENT_STATE_IDLE, returning NRF_ERROR_INVALID_STATE otherwise. After the first scan is ordered, an event of type PB_REMOTE_CLIENT_EVENT_SCAN_START is sent for processing, which will trigger pb_remote_client_event_scan_start_cb and change the client state to PB_REMOTE_CLIENT_STATE_WAIT_ACK_SCAN. On ordering the second scan from the second node, client state is no longer PB_REMOTE_CLIENT_STATE_IDLE, but PB_REMOTE_CLIENT_STATE_WAIT_ACK_SCAN. This will trigger the NRF_ERROR_INVALID_STATE error and prevent me from initiating remote scanning on the second node.

I imagine this is done because the remote client does not change its publish address dynamically, depending on the address of the server that links with the unprovisioned device. Am I on the right track? Thank you.

RE: Remote provisioning from all devices on the mesh

Mttrinh — Mon, 08 Mar 2021 13:46:35 GMT

Hi,

[quote user="EAn_BN"]Imagine we have more than one remote provisioning server. When one starts a provisioning/configuration session with an unprovisioned device that beaconed it. Would that unprovisioned device also be hearing and replying to other remote provisioning servers?[/quote]

Any unprovisioned device will have at most one provisioning link open at one time. I.e. the device will at some level "hear" the other servers, but it will open a link to at most one of them at a time and the actual provisioning process will only communicate between these two devices.

[quote user="EAn_BN"]How would the original provisioner device handle the information of the other nodes being remotely provisioned by other remove provisioning server? For instance, we are using the nodes UUID as a sort of login identifier in our cloud gateway, is that info relayed back to the original provisioner?[/quote]

With remote provisioning, the pb-remote client is in charge of the actual provisioning and as such has access to all information normally available during e.g. provisioning over the advertiser bearer. The pb-remote server(s) and the rest of the mesh network only really exist to relay the messages for the provisioning process between the pb-remote client and the provisionee.

RE: Remote provisioning from all devices on the mesh

EAn — Fri, 26 Feb 2021 15:35:06 GMT

Greetings Mttrinh , rmarques , and DevZone community.
I am currently working on this also. At the moment I have two questions still standing concerning this:

- Imagine we have more than one remote provisioning server. When one starts a provisioning/configuration session with an unprovisioned device that beaconed it. Would that unprovisioned device also be hearing and replying to other remote provisioning servers?

- How would the original provisioner device handle the information of the other nodes being remotely provisioned by other remove provisioning server? For instance, we are using the nodes UUID as a sort of login identifier in our cloud gateway, is that info relayed back to the original provisioner?

Thank you very much for all support,

Best Regards and stay safe
//EA

RE: Remote provisioning from all devices on the mesh

Mttrinh — Fri, 26 Feb 2021 14:33:07 GMT

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.

RE: Remote provisioning from all devices on the mesh

rmarques — Fri, 26 Feb 2021 10:51:07 GMT

Hello, do you have any news on this? I am not expecting hand holding on implementing any new stuff, just confirmation that I understood this correctly and, if possible, further recommendation on the general direction to go.