Adding nRF52 DK to gitHub mesh demo for thingys

[Michael_K]

Hello everyone, 

I`ve 4 thingys and ran the https://github.com/NordicPlayground/Nordic-Thingy52-mesh-demo. That works well. 

Now I`m trying to add the nRF52 DK as a Node to the bluetooth mesh network in order for it to receive the periodic messages sent by the sensor nodes. 

As a first step, I was trying to program the light_switch_example_server_nrf52832_xxAA_s132_3_1_0 from the nRF5 SDK for Mesh v1.0.1 onto the Chip (using SEGGER Embedded Studio) to see whether it is being provisioned by the bridge. Unfortunately it is not. 

My question is: Why doesn`t the nRF5 DK get provisioned by the bridge? And what do I have to change to add it to the mesh and to receive the messages of the thingys? 

Best regards, 

Michael

[Jui-Chou (Rick) Chung]

Hello Michael,

Great to hear that the Thingy mesh demo works well.

The reason why the nRF52-DK with "light switch server" cannot work with "Thingy bridge" correctly is that:

1. The "Thingy bridge" will do provision for the unprovisioned device and then do the configuration
2. During the configuration, Thingy bridge will try to bind the AppKey to the "simple Thingy server model" (the code is in here)
3. However, the "light switch server" is using the "simple on off server", which is different
4. So the configuration will fail

Basically, if you want your nRF52-DK works with "Thingy mesh demo", you have to add the "simple Thingy server model" into your project which running on nRF52-DK.

Also, since "Thingy mesh demo" is quite old (using nRF5 Mesh SDK v1.0.1), I would like to suggest you try the project "Thingy mesh provisioning demo"  which made by Hung :)

Best regards,

Rick

[Michael_K]

Thank you very much for your fast response, Rick!

I`m not sure what adding simple thingy server model in detail means. I added simple_thingy_server.c and ...server.h to the light_switch_project and additionally added the include directories for the preprocessor, which means building the project works fine now. 

Furthermore I have initialized the simple_thingy_server and bound it to an element. What else do I have to do to get my nRF52 DK provisioned?

[Michael_K]

Hello Rick, 

This is the log I get by debugging the thingy with the bridge software while I have a thingy with node and the development kit with my modified code ( which can be seen in my previous response). 

This is the log I get from the thingy node: 

And this is what the debugging of the dk with the simple_thingy_server results in: 

Both the thingy server and the dk server initialize the simple_thingy_server-model, however, only the one implemented in the thingy is provisioned. Say you were right and the problem would be during the configuration process, shouldn`t then the provisioning process be successful and the following configuration process report an error? 

Since the provisioning process doesn`t even start (at least in the log I cannot see that it starts) I think the problem is already located in the provisioning process.

I then checked the configuration parameters used to configure the node with nrf_mesh_node_config() and they are similar as well. (Same authentication key and static, same setup_callback() etc.). I finally realized that during the initialization of the provisionee model different bearer types are used. Might that be the reason, why the bridge doesn`t even seem to recognize the dk?

Regards Michael

[Jui-Chou (Rick) Chung]

Hello Michael,

May I know how you create the project for running "simple Thingy server" on the nRF52-DK? E.g. Are you using the workspace base on the "Thingy node" project in Thingy mesh demo, or are you using the example project in the mesh SDK v1.0.1?

And would you please explain more about the "different bearer types" mentioned in the previous message? :)

[Michael_K]

I`m using the light_switch_server-project from the examples of the mesh sdk v1.0.1. 

While configuring the mesh node using nrf_mesh_node_config() the provisionee-model is initialized using setup_provisionee(). In this process, public and private keys for the provisioning cryptography are generated, the provisionee is initialized with a so called provisioning context, which contains important information for setting up the provisionee. One of these characteristics is the bearer type, which I believe has to be similar to the one of the bridge. And right now it apparently is not, which might be the reason why the bridge doesn`t recognize the dk. 

Regards Michael

[Jui-Chou (Rick) Chung]

Hello Michael,

Since you are using the example based on the mesh SDK 1.0.1. I would like to suggest you check this thread. In the example workspace in mesh SDK v1.0.1, the default bearer access address is not the one defined in the specification, And that may be the reason why the bridge cannot scan the beacon from your unprovisioned server device. 

Hope this can do help :)

[Michael_K]

That was it! 

Thank you, Rick. It works now. 

Now the DK gets provisioned by the Bridge