nRF5 SDK for Mesh: Send status message with acknowledgement

RE: nRF5 SDK for Mesh: Send status message with acknowledgement

strudel — Wed, 17 Oct 2018 13:58:45 GMT

Hi,

I was able to implement sending messages from the server model with ACK from the client. It seems to be working well.

Thanks for your help!

RE: nRF5 SDK for Mesh: Send status message with acknowledgement

Edvin — Mon, 15 Oct 2018 11:23:20 GMT

Hello,

There is a feature in Bluetooth Mesh called low power node, which requires a friend node.

Low power nodes are not yet supported in the Mesh SDK (not listed in the supported features). It is currently being worked on, but I can't say anything about when it comes.

When you have a low power node with a friend node, the friend node will store all messages for the low power node until it wakes up. This is currently not supported.

However, if your sensor nodes are only sending data, and it doesn't need any data from other nodes, other than ACKs, then it should be possible to implement this the way that you describe.

All Mesh nodes work the same way. There are no actual difference between "servers" and "clients". A mesh node is told by the provisioner during configuration what channels to subscribe to, and what channels to publish on. As mentioned, you just need to use the message with ACKs, as it is done in the light_switch client example. Look at that example on the SDK version that you use.

Best regards,

Edvin

RE: nRF5 SDK for Mesh: Send status message with acknowledgement

strudel — Fri, 12 Oct 2018 14:06:28 GMT

Hi,

Thanks for getting back to me! I haven't yet looked into the sleeping part. Where did you learn that the SDK doesn't currently support sleeping? This will be important for our application. Also, do you know if Nordic has plans to add support for this in the foreseeable future?

The problem is with sending status updates. The way we currently have it setup is that the sensor nodes use a "sensor server model" and spontaneously publish their status to another node. I presume we could do it the other way around, i.e., have the client model be on the sensor nodes and use acknowledged set messages for sending the status (sensor reading). However, this seems backwards, i.e., it seems more natural to me for the sensor nodes to use the server model. The Sensor Server root model also seems to be intended to work that way.

So the question boils down to: Is it possible for a server model to spontaneously (without the client using "get") publish their status and get an acknowledgement from the client model? If so, how do I configure that?

Thanks!

RE: nRF5 SDK for Mesh: Send status message with acknowledgement

Edvin — Fri, 12 Oct 2018 10:47:00 GMT

Hello,

The functions that you refer to is from the PyACI libraries, which is the scripts used for provisioning/configuration, right?

Whether or not to require an ACK is up to the nodes application. Nordic's Mesh SDK does not officially support sleepy nodes yet, but I guess it is possible to do some custom implementation of this, which is probably what you are trying to do.

If you look in the light_switch examples, in the client application's main.c there is a function called button_event_handler(), which can send both messages that both require and don't require ACKs.

These functions are generic_onoff_client_set() and generic_onoff_client_set_unack(), respectively. Note that these names are from the nrf5_SDK_for_Mesh_v2.2.0_src, and I believe they have different names in earlier versions of the Mesh SDK, however, they should still be in the button_event_handler().

These are the functions to send messages to specific addresses that you find during configuration. Is the problem that you can't get the sleeping node configured, or that you want to get certain that the message from the node is ACKed before going back to sleep?

It is also possible to do some sort of ACKing in the application layer. Just send a message from the sleepy node to the receiving node, and send a message back to the sleepy node when the message is received. Then don't go to sleep before you get this message.

Best regards,

Edvin