This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Bluetooth mesh group reply

Hi!

In a Bluetooth mesh, we would like to get a feedback message from a group of nodes, via a reply message, after sending a message to the group.

The Bluetooth blog writes:
"Messages may be sent as replies to other messages, or they may be unsolicited messages. When a model sends a reply message, it uses the message originator’s source address as the destination address. When sending an unsolicited message, it uses the model’s publish address as the destination address."
blog.bluetooth.com/the-fundamental-concepts-of-bluetooth-mesh-networking-part-2

However, in our mesh where we use devices equipped with NRF52832:
when a node is sending an acknowledged message to group of 5 nodes, all nodes seem to try to reply,
but almost every time there is at least one reply message that is not arriving to the original sender node.

To mitigate the situation, we tried the following:
- say the sender node is called S
- say the group of five nodes are subscribing to (members of) group address C001
- let one of the nodes, P, in group C001 have a publish address set to another group address: C000
- let S subscribe to C000
- have S send an unacknowledged message to C001, at which point node P is publishing its feedback message to C001, which is then received by S

This approach works, but is problematic:
- Quite a lot of deliberate configuration is needed
- How is the situation handled if the publishing node P is lost or replaced

///
Questions

Is there any more established, idiomatic way to handle feedback from groups?

We've also experienced (in general) that some replies are not received by a mobile app connected to a proxy node.
Are there any restrictions or special configuration that is needed for replies to reach a proxy node? (e.g. will relayed messages always arrive)

  • Hello.

    I'm trying to understand what you setup looks like, but I might be misunderstanding.

    - have S send an unacknowledged message to C001, at which point node P is publishing its feedback message to C001, which is then received by S

    If Node S sends an unack'ed message to C001, Node P (subscribing to C001?) will publish a feedback message back to C001?
    Do you want the other nodes subscribing to C001 to relay the message to Node S?

    However, If you want to send something to a group, you should use access_model_publish (unreliable message). You still can receive response from multiple nodes if you configure those nodes to publish to your unicast address or to the group address you subscribed to.

    How is the situation handled if the publishing node P is lost or replaced

    I would handle this by having more than one single node sending a response. That way, if the node is lost, there is still other nodes sending a response.

    Best regards,
    Joakim

  • Hi Joakim!

    Thank you for your answer. You're right, P is supposed to send feedback back to S and I wrote the wrong address for feedback, it should be C000, i.e.:

    - have S send an unacknowledged message to C001, at which point node P is publishing its feedback message to C000, which is then received by S

    ----

    Let me rewrite the question: In short, we would like to get feedback from a group of nodes back to the sender.

    We tried two cases for feedback when the nodes in a group received a message:

    - let all nodes in the group simply reply to sender

    - let all nodes in the group publish to another "feedback group", which the sender is subscribing to

    But in both cases, the problem seems to be that feedback messages are not arriving from every node in the group (even with as little as 5 nodes in the group, at least one message may be lost). So how can we ensure that this conflict does not occur? Even though we're reducing the number of nodes in the group that send a feedback message, how many would be too many?

    I suppose our question boils down to a more technical solution to avoid message congestion.

    - Could it help to send messages at random delays from multiple nodes shifted? (which we've tried without much success)

    - Is there any lower-level support for resending a message if it doesn't arrive (even though it's unacknowledged)?

Related