Some questions about provisioning with PyACI

Question

Hi, Team 
 Premise: Currently, I'm trying provisioning using PyACI. (I considered switching the provisioning method because in the provisioner sample of light_switch, I think that the degree of freedom is not high due to the maximum number of devices that can be added to the network etc.(depending on the flash size).) I worked with the information from the tutorial and info center, and confirmed that provisioning and configuration can be performed as intended. ・nRF52840 ・Mesh SDK v2.2.0 ・Windows10 
 Questions: 1. Once I have provisioned several devices and exited PyACI, when I resume PyACI to provision another device, the following command will appear to fail. In [1]: db = MeshDB("database/example_database.json")

In [2]: p = Provisioner(device, db)

In [3]: 2019-10-24 11:45:23,901 - INFO - COM60: Success
2019-10-24 11:45:23,904 - ERROR - COM60: None: ERROR_REJECTED
2019-10-24 11:45:23,908 - ERROR - COM60: SubnetAdd: ERROR_INTERNAL
2019-10-24 11:45:23,913 - ERROR - COM60: AppkeyAdd: ERROR_INTERNAL
2019-10-24 11:45:23,917 - ERROR - COM60: AppkeyAdd: ERROR_INTERNAL
In [3]: However, as before, I can provision and configure without problems. Do I have to worry about this output? Or, if there is an appropriate command after the second times, please let me know. (I think there was no description in the tutorial etc.) 2. How do I get a device key handle when I want to reconfigure a device that has been configured? Is there any other way than referring to the LOG file? The address handle can be obtained with the following command, but the device key handle cannot be obtained and will be rejected... (This parameter is required for cc.publish_set ().) In [6]: len(db.nodes)
Out[6]: 50

In [7]: send(cmd.AddrPublicationAdd(db.nodes[49].unicast_address))

In [8]: 2019-10-24 11:55:35,672 - INFO - COM60: AddrPublicationAdd: {'address_handle': 0}
In [8]:

In [8]: send(cmd.DevkeyAdd(db.nodes[49].unicast_address, 0, db.nodes[49].device_key))

In [9]: 2019-10-24 11:56:08,145 - ERROR - COM60: DevkeyAdd: ERROR_REJECTED
 3. When the network information (json file) being backed up is read by another board which mesh serial project written, and try to add a new device, devkey_handle and address_handle become '8' and '1', respectively. Is this behavior correct? Assume this is normal behavior. Is my understanding correct that the value of each handle and the device actually associated with it may not be the same every time? 4. Regarding the parameters defined in nrf_mesh_config_app.h in the mesh serial example. /** Maximum number of device keys */
#define DSM_DEVICE_MAX (10)

/** Maximum number of non-virtual addresses. */
#define DSM_NONVIRTUAL_ADDR_MAX (32)

/** Number of flash pages reserved for the DSM storage */
#define DSM_FLASH_PAGE_COUNT (1)
 If I do not edit the above three parameters from the example, devkey_handle cannot be obtained when I try to provision the 11th device. Suppose I run the mesh serial sample and built a network of about 5 nodes, for example. After that, I wanted to add 10 more devices to the network. I set "DSM_DEVICE_MAX" to "20", rebuild, and flashed to the board. And I started PyACI again and was able to provision and configure all 10 devices (nodes). Similarly, when the network was expanded, the address_handle could not be obtained when the value of "DSM_NONVIRTUAL_ADDR_MAX" was exceeded. The value of this parameter was increased and rewritten on the board and continued provisioning and configuration. Is it a safe way to expand the network in this way? Or is it desirable to set these parameters to some large values from the start? What is the maximum value that can be set for each parameter defined here? In addition, please let me know if there is a recommended value. (Perhaps I expect that "DSM_FLASH_PAGE_COUNT" will need to be increased.) 5. It's just a confirmation that my recognition is correct. I can set (re-generate) the netkey and appkey shown in "example_database.json" by myself, right? I tried to clear my question through browse a lot of other tickets on DevZone, but I couldn't find anything that would help me. Sorry for posting so many questions at once. Thank you in advance for your cooperation. Wataru

Hung Bui · Accepted Answer

Hi Wataru, 
 1. I think this is related to that the nRF52 serial firmware doesn't expect that the COM port will opened again and the keys to be added again. 
 2&3. Also related to #1, the PyACI is made as an demonstration of what you can do with the serial firmware. It's not designed to be a production tool that you can use out of the box. So there are 2 places that the database is stored. One is in the .json file and one inside the nRF52840. Unfortunately, we haven't got the option to restore the database on the nRF52840 after it's reset or if you want to copy the database to other board. This explains the behaviour you see with devkey_handle and address_handle in #3. Or when you reset the board, you won't be able to access those device/handles that you provisioned before. 
 Devkey can't be readded, different to publication address, we don't have a mechanism to check if the address is already added to the database. 
 4. This also related to what I described in 2&3, the database is stored in both the nRF52 device and on PC. The configuration on nRF52 is hardcoded and can't be changed dynamically. 
 
 The solution for all of this is in my opinion is to make a different version of serial firmware that move the location of dsm database from the nRF52 to PC. And the nRF52 would need to access PC to get the database for example the handle of the address, device key. This way it would work when resetting the board, multiple boards, etc. Unfortunately, we don't have the code example doing this yet. 
 
 5. Yes you are correct. You can modify the appkey and netkey on your own. It's added at the beginning when you open the COM port but can't be added twice or modify as in #1.

Some questions about provisioning with PyACI

Top Replies