How to deal with a variable number of elements?

[Marius Heil]

Hi,

as I know from the mesh spec, the number of elements cannot change after a device was provisioned. Nordic even went so far as to define the number of elements during compile time. I have now done a lot of research but could nowhere find an answer to this question.

Now, let's say that I want to create firmware for a DALI controller. By design, the controller will not know how many light bulbs are attached without enumerating them first. The user could also decide to add / remove the bulbs at any time and re-enumerate them.

What is the best and most standard way to deal with a situation like this? I see two options:

- During provisioning, enumerate the DALI devices and generate the appropriate number of elements before the provisioning is done. In order to do another DALI search, the device must do another search and must afterwards be reprovisioned.

- Provide the maximum number of elements at all times and figure out some (non-standard?) way to tell the user which lightbulbs are currently available and which are not. This would be a bit weird if the device is e.g. a DMX device with support for up to 512 lightbulbs.

Thanks,

Marius

[Mttrinh]

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. 

[Mttrinh]

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.

[Marius Heil]

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.