Delay parameter in Mesh

[Paulo.Zacarias]

Hi,

Quick question:

I read in this article on the section "A tough world of lighting controls" it states the following:

"Let's say that five messages are spaced 20 ms apart. The first one goes out at T=0 with the Delay set to 100 ms. The second is sent at T=20 ms with the Delay set to 80 ms. The scheme repeats until the fifth message is sent at T=100 ms with the Delay set to 0. Now, regardless of which one is picked by a given light, all lights will turn on at exactly the same time. "

Does the nRF5 SDK for Mesh have such implementation?

Thank you in advance.

Regards

[FormerMember]

If the goal is to turn on lights at the same time, you can use group functionality. When a number of nodes are included in a group, that group can be controlled as one "unit", to turn on the light for all members in a group, it is sufficient for transmit one message (to the group). Each group member will not receive the message at the exact same time, but for most practical usecases it will be more that good enough.

You can a little about groups in this blog post and about group addresses in the "Address" section here.

 

[leonwj]

hello Kristin,

FYI... Indeed, the Bluetooth Mesh v1.0 spec does include specific functionality for this... see section 1.4.1 State transitions of the Mesh_Model_Specification v1.0 document.

The delay parameter on supported messages is closely tied to models which support a transition time (period of time taken to get from a current state to a desired state) and is specified as the number of 5 ms intervals to delay before starting the state transition. Additionally, a different delay value can be specified on a series of related messages e.g. one use case in lighting applications is to avoid the 'popcorn' effect of related lights each turning on at differing times. By using different delay values, a client model in a mesh switch could ensure that lights in the related group were turned on 'relatively' at the same time (at least without any discernible difference to the human eye).

@Paulo, the Mesh_Model_Specification v1.0 contains models which are beyond the foundation models required for Bluetooth SIG Mesh conformance and hence each stack vendor can implement these over time based upon internal priorities/market pressures. From looking at the Nordic stack, it is my understanding that these models have not been introduced as yet and I have no visibility on delivery dates (although a basic search of the forum will show that the intent to introduce them fairly soon is there).

Regards,