multiple clients and one server in Bluetooth mesh application

RE: multiple clients and one server in Bluetooth mesh application

EAn — Tue, 11 Jun 2019 09:21:03 GMT

Bjørn Kvaale, here it is: devzone.nordicsemi.com/.../export-mesh-network-information-mapping-mesh-network-and-nodes-constitution

Regards!

RE: multiple clients and one server in Bluetooth mesh application

EAn — Fri, 07 Jun 2019 17:13:19 GMT

Hi Bjørn Kvaale . I could. I was just trying to avoid duplicating questions, as there are many similar cases and that basically makes the information spread and sometimes conflicting.

I will add a new case as you've requested.

RE: multiple clients and one server in Bluetooth mesh application

Bjørn Kvaale — Fri, 07 Jun 2019 15:32:18 GMT

EAn Could you please create a new DevZone case?

RE: multiple clients and one server in Bluetooth mesh application

EAn — Thu, 06 Jun 2019 17:24:53 GMT

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.

RE: multiple clients and one server in Bluetooth mesh application

EAn — Thu, 06 Jun 2019 17:23:05 GMT

Greetings! Bjørn Kvaale Isn't there a way to achieve this same type of information mapping using, for instance one of the mesh nodes that could act as a client/provisioner to all other nodes and therefore keep all the mesh information which could then be backed up through either a BLE<>cloud gateway, or a WiFi network coprocessor?

If so, what API calls would we need to get the necessary information to be able to reconstruct the network (network key, app keys, device keys, device constitution (elements+models+addresses) etc...) ?

In real-case scenarios you don't always have a device that can speak Python to extract the information in the way you suggest, and in some use-cases you might not want an App that connects via BLE....

Thank you very much!

RE: multiple clients and one server in Bluetooth mesh application

Bjørn Kvaale — Thu, 09 May 2019 12:56:42 GMT

No worries! My guess would be somewhere here.

RE: multiple clients and one server in Bluetooth mesh application

davidm — Wed, 08 May 2019 20:37:37 GMT

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

RE: multiple clients and one server in Bluetooth mesh application

Bjørn Kvaale — Tue, 07 May 2019 14:07:08 GMT

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.

RE: multiple clients and one server in Bluetooth mesh application

davidm — Tue, 07 May 2019 06:25:55 GMT

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.

RE: multiple clients and one server in Bluetooth mesh application

Bjørn Kvaale — Fri, 03 May 2019 07:36:31 GMT

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.

RE: multiple clients and one server in Bluetooth mesh application

davidm — Tue, 30 Apr 2019 03:04:33 GMT

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?

RE: multiple clients and one server in Bluetooth mesh application

Bjørn Kvaale — Mon, 29 Apr 2019 10:00:25 GMT

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?

RE: multiple clients and one server in Bluetooth mesh application

davidm — Thu, 25 Apr 2019 03:19:12 GMT

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?

RE: multiple clients and one server in Bluetooth mesh application

Bjørn Kvaale — Wed, 24 Apr 2019 13:27:45 GMT

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).

[quote user=""]How would I know a message came from this a certain node and element? [/quote]

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;

[quote user=""]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?[/quote]

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