What is the best practice approach for a mesh of many low power nodes and one client?

RE: What is the best practice approach for a mesh of many low power nodes and one client?

Hung Bui — Mon, 11 Feb 2019 13:38:41 GMT

Hi Sloth,

You are right, we only provided a precompiled hex file for Friend node. But the source is available on Zephyr project (not from Nordic). We are working on providing the Friend role in our stack in the next SDK release v3.2

There are a few alternatives for Low Power Node:

- Using advertising packet to send data to relay node. This is similar to the Enocean example we have in the SDK. The sensor node (low power) only wake up to broadcast data and then sleep again. But this solution doesn't provide acknowledgement to the sensor if the relay receives the data or not.

- Establishing a connection then send data and the disconnect and sleep again. This actually similar to friendship, but you implement it on GATT connection.

- Simply put the normal node to sleep. There is no obligation in the spec that the node have to be active all the time. You can sleep up to 96 hours without the need to update the IV index number. But this solution doesn't cover the caching of the data for the LPN node on the relay node. However the node can simply query the client if there is any data.

RE: What is the best practice approach for a mesh of many low power nodes and one client?

sloth — Fri, 08 Feb 2019 22:08:25 GMT

Nordic has not provided the friend node feature to my knowledge, only a precompiled binary which I cannot implement into my application. The project I am working on was based around using this feature.

Since I cannot use this feature, I need an alternative approach.

Can a client model publish to many different addresses?

RE: What is the best practice approach for a mesh of many low power nodes and one client?

Hung Bui — Fri, 08 Feb 2019 10:07:09 GMT

Hi Sloth,

Could you explain a little bit more on when the friend node is not available ?

The current mechanism of LPN and friendship is that the FN (friend node) cache data for each LPN it handles in a separated buffer. When the LPN wakes up it will query that, at the same time sending any data that it needs to send to the client. The friendship is established when setting up the network, prior to entering sleepmode. Each LPN should only have one FN at a time. LPN doesn't talk to any other node when it's in a friendship.

Regarding the model, it's upto the application to design the model. There is no obligation on that as long as you don't use the standard Bluetooth SIG model. You can implementing your own model, or even choose not to use model at all, simply use the access layer directly.

RE: What is the best practice approach for a mesh of many low power nodes and one client?

sloth — Thu, 07 Feb 2019 19:14:50 GMT

Hi Hung,

There is one client node in the network, possibly some router nodes and then a large number of low powered nodes. It is a fixed network once installed.

My question is mainly about what the setup should look like for this situation while the friend node is not available. The client cannot query data from the servers because they spend most of their time asleep and not listening, so what is the best practice to get the data back to the client? (And also do things like send settings from client to low power node.)

For receiving data on the client can I just have one client model and all the servers wake up and send data to this model on a regular interval? This is what I mean by 'push' having the servers send data.

If each node has a unique address and I want to send settings to an individual node. Do I need a separate client model for each node? I thought the publish address was part of the model. Is there an example of a similar setup?

RE: What is the best practice approach for a mesh of many low power nodes and one client?

Hung Bui — Thu, 07 Feb 2019 15:00:49 GMT

Hi Sloth,

Could you clarify, how many client node in your network ? Is it a fixed one or movable ? If there is only one client, how would it cover the large area that the LPN node distributed ?

Note that the LPN nodes wouldn't do any relaying, hence you can have a mesh network with just LPN nodes and one client node. If 's a start network you are thinking of, I would suggest not to use mesh.

Please be aware that LPN is provided in our SDK from v3.0, the only thing missing is the Friend node. We do have Friend example provided as a hex but it's from Zephyr repository (you can access to Zephyr, it's a public project).

What do you mean by "push type method" ? Each LPN node has an unique address and it can has any model on it. On the client side, you don't need one client model for each of the LPN. You can have a single model that can handle data from all the LPN node. You just need to use the address of the LPN node to ID them. I'm talking about proprietary model.

RE: What is the best practice approach for a mesh of many low power nodes and one client?

sloth — Thu, 07 Feb 2019 02:21:16 GMT

As a bit of an extension to the question, Since client models publish to a fixed address. If I want to support 16 nodes does the client have to have 16 models, each bound to a server address?