General Purpose Provisioner

[Patrik]

Hi,

I found out, that in the light switch example (SDK for Mesh v.1.0.1) after adding second element with Simple OnOff model in the light_switch_server, it is not possible to provision that second element. After searching in DevZone, I found out, that the provisioner implemented in light_switch_client is not general purpose provisioner. Therefore I want to make some changes to the provisioner.c file to be able to provision that second element. I will have to use the number of elements of the device returned in NRF_MESH_PROV_EVT_CAPS_RECEIVED event (p_evt->params.oob_caps_received.oob_caps.num_elements).

I have a pair questions to do that general purpose provisioner:

1) The Configuration Client Model communicates just with the Configuration Server Model and then the Configuration Server Model configures the rest of the elements?

2) Each element in the device posseses one DevKey? I ask because I don't know if to call functions dsm_devkey_add(...), config_client_server_bind(...) and config_client_server_set(...) for each one element in a node.

[David Edwin]

Use the pyACI python interface to run the provisioning and configuration. This would allow to to understand things better by running it from the command line.

Switch to the next release of the Mesh SDK (after 1.0.1) when it gets released as the pyACI has a bit more features in the configuration stage.

(1) is generally true.

(2) Typically a single device key is obtained during provisioning, the device key is per device. Configuration support is better on the pyACI in the newer release that comes after 1.0.1 Mesh SDK.

 

 

[Patrik]

One more question. Can be the Configuration Client Model bound with the AppKey? If yes, which function to use? Because in the light switch example if I'm right, it is bound just with the DevKey. 

[David Edwin]

Why would you want to bind to the AppKey ? The configuration client is configuring individual nodes so it would use the devkey of the node that is being configured.