BLE Mesh LED onoff example issue

[m10817012]

I use the LED onoff example of the Nordic BLE Mesh template (Version : 5.0), using two nodes (One Client, One Server). The nodes are already Provisioned.

I want to know why the Client node sends Get function (generic_onoff_client_get) to the Server node once and receives two response packets from the server?

If it is sent twice, can it be adjusted to send it once? How to modify it?

[tesc]

Hi,

In Bluetooth mesh you have "transmit count" which is a publication configuration for number of repeated transmissions for packets. This has to do with redundancy in the network, to ensure that all packets arrive at the destination. On the access level, this will be handled as one packet (so on the access level you should see the packet only once.) If this is what you see, then the best option is to let it be as is, as it significantly reduces the risk of not receiving the message.

Also, when you send a set message, you will get a status message back. In addition, if the server model is configured to publish status messages, a message is sent to the publish address for those status messages. If it is addressed to the client model or to an address for which the client model subscribes, then the client model will get both the status message as response to the set message and the published status message. If this is what you see, either do an unacknowledged set (for which you will not get back a status response, only the general status publish) or do not subscribe to the status publications (or not configure the status publication addressed to the client model.)

Regards,
Terje

[tesc]

Hi,

I need to correct myself on this one. There are two levels of transmit count.

One is on the network layer, and the message counts as one message. It only controls the number of retransmissions for the first, initial, hop.

One is on the access layer, and each repeat sends an additional message (with new sequence number). This means if the model is configured with retransmissions on the access level, then this will result in multiple messages received in the other end. Mesh messages should preferably be idempotent for this reason. Idempotent messages have the quality that no matter how many times they are repeated, the end result is the same. A "turn off" event is idempotent, because the end result (state set off) is the same no matter how many times you repeat it. A "toggle" event is not idempotent, because the end result (state set either on or off) depends on how many times you repeat it.

I am sorry for any confusion caused with my initial answer.

Regards,
Terje