Unprovisioning the nodes based on RSSI

[tysonp]

My current implementation is based on light switch example and I am currently using nrf52832 kit with Mesh SDK v5.0.0. I have a mesh network setup with a client and two server nodes. My client also does the provisioning(borrowed the client provisioning concept used in SDK v1.0.1). I want to unprovision one of my server node as it moves away from one of the nearest server node and I guess getting information of RSSI or link budget is one way to go. 

Can you guide me to any example and provide any suggestion how this can be implemented? Where in the current code that I must search for?

[Hung Bui]

Hi Tyson, 

It's correct that you can base on the RSSI to detect the distance of a node to the other nearest node. However, RSSI is not a very reliable source to calculate distance. It can be affected largely by the environment for example if a person cover the device, it will affect the actual RSSI. I would suggest to collect the RSSI for long period of time and get the average before you decide that the device has moved away. 

Could you give some more information about your application and why you want to remove the node when it's moving away (but still in the range ? )

Regarding RSSI, for each packet arrived in the access layer, you can find the rssi value inside nrf_mesh_rx_metadata_scanner_t struct inside access_message_rx_t struct of the message. 

To unprovision a node, you can use the configuration client to send a node reset config_client_node_reset() to the node. The node then will erase provisioning information and becomes unprovisioned. Please be noted that to make sure the node is actually excluded from the network you would need to black list the node and update the network with new netkey. The reason for that is that we wouldn't know if the node actually erase provisioning information or not. 

[tysonp]

Hi Hung,

Thanks for the prompt reply. So, we are planning and thinking of an application where we take away the node from one mesh network and automatically gets added to another mesh network. So, before being added to another network, it need to get unprovisioned from its previous network and vice versa and I want the server nodes to be unprovision itself based on rssi from its nearest node, here unprovisioning should happen independent of the provisioner. 

So,as you have added each time a nodes gets unprovisioned or in this case moves away from my network. Then, I should also update the netkey of all other nodes in the network with my provisioner? I guess that I should also track my nodes which is moved away. So, what steps I need to do at configuration client side to refresh netkey for all the other nodes which is already part of the network. What are the steps in the code for key refresh procedure?

[Hung Bui]

Hi Tyson, 

There is a process called "Key Refresh" where the network key can be updated. If you choose to not update a node, it will be black listed and can't join the network after the key refresh process is finished. 

This to ensure that the node to be removed can't re-connect to the network even thought it doesn't erase the provisioning information as requested in the node_reset command. 

Please have a look at this discussion .

In your case, if you want to unprovision the node itself, you can just execute what inside handle_node_reset() (disable proxy first, then do apply_reset()). In that case, when a node unprovision itself, I don't think you would need to blacklist the node. 

[tysonp]

Hi Hung,

One final question. I need a heartbeat messages to be broadcasted periodically from the client. Usually its done by the configuration server model when the provisioner sends an opcode. But, in my case the client and provisioner are same. So, this question is just to check if I am right. So, since my client and provisioner are same, I could setup my current device(client + provisioner) to send heartbeat message by heartbeat_init(), heartbeat_publication_set(). Am I right? Anything else needs to done?

Thanks,

Tyson

[Hung Bui]

Hi Tyson, 

Yes I think calling heartbeat_publication_set() to send the message to itself should be OK. 
Otherwise you can follow what we do inside  handle_heartbeat_publication_set() in config_server.c to configure heartbeat manually.