Ble Mesh : being a provisioner and say light switch server

[Mahendra Tailor]

I have analysed the light switch client and server example apps where the light switch is also the privisioner. They both start and initialise a bit differently although both start off by calling nrf_mesh_init(), nrf_mesh_enable(), dsm_init(), access_init().

Then they deviate.

One calls config_client_init() and the other calls config_server_init()

What if, I add to the light_switch example app a custom model which is say a proximity model in a secondary element which will obviously get its own node address.

Question. I think I can speculate that the node address will be just +1 of the address it will assign itself.

However how does it get a publish address and say the application key?

In a sense, I am asking is it 'legal' to call config_client_init() and config_server_init() in the same build?

I ask because I work for Laird who supplies module with an onboard interpreted programming language and so by definition I do not know what our customers will be doing and so have to expose as flexible event driven API as I can.

Look forward to hearing from one and all.

To complicate matters the SDK uses the file "nrf_mesh_config_app.h" which is used to specify the maximum number elements and models per element as #defines. And I cannot use that as that #define is a compile time value and by the time our customers play with our Mesh module, the firmware has already been compiled.

[Hung Bui]

Hi Mahendra,

If you are going to use the server on the provisioner, I don't see any problem adding an extra element and a server model on it. As you might already see, we configure the clients manually inside access_init(). Subscription/publication address and application key is binded to the clients model manually in the function.

You can do the same to the server.

But if you want to add another element on the server, you may have a trouble because the provisioner on the light switch example doesn't support provisioning multiple element on one device. Have a look here.

You will have to think of creating a generic provisioner that can do more flexible provisioning and can can be dynamically customized by the end user.

[Mahendra Tailor]

Thank you for confirming what I suspected would be the case. The Nordic Mesh is evolving and I appreciate Nordic allowing us early access to the SDKs. Is there a timeline for releases. For example, for a production ready Mesh SDK, which quarter should I be planning for?

Although just like Nordic, we at Laird plan to do something similar and release engineering firmware releases that mirror the functionality in your SDK, but exposed in an easy to use interpreted programming language.