multiple clients and one server in Bluetooth mesh application

[davidm]

What I want to accomplish

I want to create a bluetooth mesh application. I want one board  to act as a server and 12 or more other boards acting as clients. Each client will have 4 buttons and upon pushing one button on the client,will send send a ON status should  to the server. So basically all the clients will send messages to the server when a button is pushed.

 

My understanding/Assumptions

Please correct my understanding if is wrong..My understanding is since the documentation mentions each element acting as a virtual entity in the mesh with its own unique unicast address  and  only one model instance per element can implement a handler for a specific message opcode(in this case  SIMPLE_ON_OFF_OPCODE_SET)

So for my 12 client nodes (each with 4 buttons) I would need to declare 4 elements in each node.That means for 12 client nodes each with 4 elements, On a server node I will have to instantiate 48 elements each implementing a handler for OPCODE_SET.

Questions

How would I know  a message came from this a certain node and element? 

How would this work at the time of configuration, in other words will I have to give one publication address for all 48 elements or just 12 nodes?

I am sure there is a better way to do it, please advise.

[Bjørn Kvaale]

You will need to instantiate one element for each of the 4 buttons in each client node. However, you will not need to instantiate 48 elements on the server node. An element is essentially a controllable part of your device.

To simplify things, if you want pressing the same button (e.g. button 1) on each client node to turn the server light on or off, then you only need one element on the server node. This one element would then control when to turn the light on the server on or off.

If you want each of the 4 buttons on the 52 DK to turn on one of the server LEDs (i.e. button 1 on client turns on LED1 on server, button 2 on client turns on LED2 on server, etc...), then you would require 4 elements on each client & 4 elements on the server.

I created an example here which sets up multiple elements in a Bluetooth Mesh example. In this case, I used the server example to turn on multiple LEDs on the nRF52 DK. You can most likely follow the same procedure if you want to use the newest mesh sdk (which I recommend).

How would I know  a message came from this a certain node and element? 

 Mesh messages are sent with a source address, so you can see which node sent the message. See this struct in access.h:

/** Metadata for received messages. */
typedef struct
{
    /** Source address of the message. */
    nrf_mesh_address_t src;
    /** Destination address of the message. */
    nrf_mesh_address_t dst;
    /** TTL value for the received message. */
    uint8_t ttl;
    /** Application key handle that decrypted the message. */
    dsm_handle_t appkey_handle;
    /** Core RX metadata attached to the packet */
    const nrf_mesh_rx_metadata_t * p_core_metadata;
    /** Network key handle that decrypted the message. */
    dsm_handle_t subnet_handle;
} access_message_rx_meta_t;

How would this work at the time of configuration, in other words will I have to give one publication address for all 48 elements or just 12 nodes?

 You can just set the publication address to the unicast address of the server node.

[davidm]

Got it. Thank you so much Bjørn Kvaale   That was very helpful.

Now, on the server node I want to be able to have a list of source addresses in advance for mapping(like map  0Xabcd to kitchen,0xdef to the living room and so forth....) that way I know this message came from a certain part of the house.(Practically I would have at least 20 client nodes). I am assuming this will be during provisioning,Is this possible for server to access all clients Unicast addresses during provisioning?If yes how? 

[Bjørn Kvaale]

The provisioner will know the unicast addresses of all of the clients & the servers. The server does not have access to this information the way our mesh sdk is setup at the moment. Are you planning on using the nRF Mesh app for provisioning, the provisioner example or the interactive python script?

[davidm]

Honestly, I am open to use any of the provisioning method you mentioned above.To get started I was thinking of using nRF mobile App.I know at the time of provisioning with the mobile App I would be able to identify/associate which address/client is located where. But since I don't have control of the App I won't be able to programmatically send the clients addresses mapping to my own server. That is why I was hoping if I could access clients addresses on the server node, I could interface it with wifi chip and send the mapping to the server. What provisioning method do you propose in this case?

[Bjørn Kvaale]

Regarding the nRF Mesh app, the source code is available here & here. You could update the source code to send the client addresses to your server. If you don't want to do this, I would recommend looking at the interactive python script. Whenever you provision a node, that node gets added to the "example_database.json" file. All you then need is a nRF52 DK running the mesh serial example to act as a connectivity chip between your computer running interactive python & the mesh network. You could then easily send the relevant data to your server. That backup file contains all of the relevant data for your network, so you want to make sure the data is sent securely to prevent anyone else from having access to your mesh network.

[davidm]

Thank you Bjørn Kvaale   I will go with mesh mobile App. Do you happen to know where in the library they save the provision nodes and I will pick up from there.

[Bjørn Kvaale]

Are you referring to the nRF Mesh iOS or Android app? I will take a look once I know which app you want to know more about.

[davidm]

My apologies I thought I mentioned. I mean nRF Mesh Android App.

[Bjørn Kvaale]

No worries! My guess would be somewhere here.

[EAn]

I'd like to know this for the Android App (in any case for a consumer application it would be important to develop for both OSs ...) . Thank you Bjørn Kvaale, for your assistance.