Mesh configuration

[Serge.Ayer]

Dear support,

We have built a ble mesh network running the light_switch_client/server application (mesh sdk 3.1.0). We are using the Android application for provisioning the nodes and configuring the network. From the Android application, we are trying to modify some of the Model Publication state parameters (namely publish period state, publish retransmit count).

We first have a number of questions regarding the specifications (MshPRFv1.0.1 document):

- we understand the Publish Retransmit Count (4.2.2.6) to be the number of times a relaying node will retransmit a message after it receives the original message.

- we understand the Network Transmit Count (4.2.19.1) to be the number of times a node is sending a message after a state change.

- we understand the Publish Period (4.2.2.2) to be the period (interval) at which status messages are published by a node (no need for a state change).

QUESTION 1: is this understanding correct ?

Based on this understanding, we have questions regarding the Android mesh application (used for provisioning). In this application, it is possible to configure some of the node states. Some questions about the application:

QUESTION 2: does "Publication Period" in the configuration screen mean "Publish period" as defined in 4.2.2.2 ?

QUESTION 3: does "Retransmission" implement Publish restransmission as defined in 4.2.2.6 ?

QUESTION 4: it seems that it is not possible to configure the Network transmit count as defined in 4.2.19.1. It this correct ?

Finally, we have questions regarding the source code for the client application:

QUESTION 5: when pressing button 1, the function generic_onoff_client_set() is called. By following the code, we end up in a function that calls access_publish_retransmission_message_add(). We don't understand why retransmission is used here ? Does not message retransmission relate to the number of times a relaying node must retransmit a message received from another node ?

QUESTION 6: we observed that configuring the Publish Retransmit Count from the Android application modifies the number of messages that are sent by the client node. Again, we have no explanation for this. Furthermore, we could not find any clear relation between the value set and the number of messages sent by the client node.

We are sorry for the large number of questions, but we believe that it is more efficient to post all questions related to the understanding of the example in a single post rather than several ones. We thank you in advance for your help.

Best regards,

Serge

 

[Joakim Jakobsen]

Got some feedback from our developers. 

Question 2: Yes, they mean the same, however the latest app to be released will have the names inline. 

Question 3. It does set the configuration to the node, and it should work. You need to verify this on the node side. 

Question 4. This should work. Could you elaborate on why you believe that "it seems not possible".?

Best regards, 
Joakim

[Serge.Ayer]

Thank you for your answers.

Since to our understanding the "Network transmit count" is not the same as the " Publish Retransmit Count", then only the "Publish Restransmit Count" can be set from the Android application. But this is somehow related to the other questions and also to the implementation of the sdk, for which answers are still expected.

[Joakim Jakobsen]

Publish Retransmit Count

 So, this is not related to relay-nodes. 

It's about the Access model publication, and you can find the use of it in access.c: line 1256, inside access_model_publish(). 

We check if m_model_pool[handle].model_info.publication_retransmit.count > 0 and the call to access_publish_retransmission_message_add() i made. 

Furthermore, we could not find any clear relation between the value set and the number of messages sent by the client node.

 I don't understand what you mean by this. Are you not seeing the number of retransmissions to match the "Retransmit Count"?

Best regards, 
Joakim

[Joakim Jakobsen]

I suggest that you take a look at the Publish Retransmit Count definition in the latest version of the Spec. (v1.0.1). The "original message is received" part is removed, and it should be less confusing. 

Best regards