I am working on a BT mesh network where nodes are mostly sleeping (to conserve power) when they wake up, they need to send a sensor reading to another node (which is always on and in transmit range) and then go back to sleep.The way it currently works is that the nodes have a custom server model and use "status_publish" to send the sensor reading. I used the PyACI to add a subscription as follows:cc.model_publication_set(addr, MODEL_ID, mt.Publish(1, index=0, ttl=7))This works, i.e., the main node (unicast address = 1) is receiving the messages. But there is no guarantee and I get no feedback on the sending side if the message was received. So it seems like the messages are sent without being acknowledged. I tried adding a retransmit parameter:cc.model_publication_set(addr, MODEL_ID, mt.Publish(1, index=0, ttl=7, retransmit=(7, 0)))But this doesn't seem to change anything. Does it just mean the messages are always transmitted 7 times but not acknowledged?So, the question is: How do I configure a node to send status messages that are acknowledged by another node? Thanks!
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.
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!
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.