How to deal with a variable number of elements?

RE: How to deal with a variable number of elements?

Marius Heil — Wed, 29 Apr 2020 09:27:29 GMT

Hi, thank you. I thought there might be a standard way to do this as the SIG mesh was mainly targeted at lighting and DALI is one of the standards of todays lighting industry that will not go away in the near future. But this helps to clarify that I have to choose a vendor specific way of dealing with that. Thanks.

RE: How to deal with a variable number of elements?

Mttrinh — Wed, 29 Apr 2020 09:21:36 GMT

Hi,

1. Do you mean that the guidelines be presented in the nRF5 Mesh SDK documentation? or somewhere else?

2. This seems like a very product-specific issue. I understand what you are trying to do here. Given the current framework of things and the mesh specification requirements that the device composition cannot be changed once the device is provisioned, is creating chicken-and-egg situation here.

The aspect of searching for devices on the DALI bus seems to a key thing here. This appears to be fairly vendor-specific. If that is the case, I would solve this problem in the following way:

Assumption: End-user with a mobile phone is in direct radio range of the unprovisioned device connected to a DALI Bus.

Define an advertising channel PDU with some manufacturer-specific data byte to be sent as a signal to the device to enumerate DALI bus. Let us call this "Special ADV PDU".
This PDU can be intercepted by the application running on an unprovisioned device nRF Mesh SDK's scanner callback API. When the unprovisioned device receives this PDU, it will enumerate DALI bus and determine which models to be initialized by writing some user-defined information in flash, and reboot the device.
When the device reboots, the application will check this information saved in the flash and initialize the models accordingly.
The ability to change DALI enumeration related information in the flash should be unlocked only when the device is unprovisioned. Otherwise, the application will ignore all incoming Special ADV PDU.

Note this just an example of how things can be done. You can build on top of this idea to encrypt manufacturer-specific data in these PDUs if required and employ good security practices considering the end-use case of your devices.

A bit more complex way could be:

Define a custom BLE service that can trigger the DALI enumeration, and use this service for triggering enumeration when the device is unprovisioned. The device can be made to advertise this service only when it boots up as an unprovisioned device.

RE: How to deal with a variable number of elements?

Marius Heil — Tue, 07 Apr 2020 17:07:32 GMT

Hi, thank you. This is one possibility. I wonder why there are no guidelines for that as I expect that different vendors will use a different approach.

However, there is one crucial problem: For DALI devices, there are typically different search modes that can be triggered (Find only new, Clear and Search, ....). How would the user be able to trigger a search on the device, if it is not provisioned? It looks like it would need to be provisioned, then the search could be started, then it has to be unprovisioned so that the number of elements can be changed. Finally, it has to be provisioned again.

Is there a better possibility?

RE: How to deal with a variable number of elements?

Mttrinh — Tue, 07 Apr 2020 15:44:05 GMT

Hi,

This is the response from our team:

Having a variable number of elements in a node is not compatible with Mesh Specification v1. Further, the stack does not seamlessly support a dynamic change of device composition data. Even if it could be made possible somehow, having such a node that can instantly change its composition after provisioning can be detrimental for the entire network and can cause functionality breakdown in the network.

I can think of following way in which customer's requirement can be satisfied while still observing Mesh Profile and Mesh stack restrictions:

Pre-allocate a sufficient number of elements, model instances, the total number of virtual/non-virtual addresses, total number of subscription lists, app keys and net keys.
Then, in an unprovisioned state, when such a mesh device is connected to the DALI bus for the first time this device can enumerate DALI devices and store this information (say, for example, the number of lights present on the bus) in flash as a user application information.
Based on this information, necessary models can be initialized in the model_init_cb() of the main application. You, as a manufacturer of this device, can define the point of frozen composition as - enumeration of DALI devices by the mesh device in an unprovisioned state. If the end-user needs to change the number of attached DALI devices, then he can unprovision the mesh device first, change the number of devices and then re-provision the mesh device.
The only pitfall of this method would be, having to bear with empty elements on the device. But this looks like it is unavoidable.