Some questions about provisioning with PyACI

[wataru_m]

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]

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. 

[wataru_m]

Hi, Hung

Thank you for your reply.

1.  Is it safe to assume that doing this is not a problem just because you don't expect the key to be added again?
     Without this process, I think that no other way to add devices to the network when using PyACI.

2, 3, 4.  PyACI misunderstood that it was provided as an out-of-the-box production tool.
             Sorry, I've gone and jumped to conclusions.

             I want to move dsm database to a PC, in other words,
             try an approach that can manage network information with a single database (On PC),
             but what kind of place should be reconsidered specifically? Are there any hints?

             Or, if such discussions and examples are already handled in some DevZone cases, etc.,
             I would appreciate it if you could give me that information.

5. Thank you, I was relieved that my understanding was correct.
    I will keep that (cannnot change or add keys) in mind.


Best regards,
Wataru

[Hung Bui]

Hi Wataru, 

1. I don't see any problem if the keys being added and rejected. 

2. We currently don't have an example or discussion on how to achieve that. Actually it's possible to restore the database in the NRF52, you would need to call AddrPublicationAdd, DevkeyAdd etc, to add the keys/address back to the database on the nRF52. The draw back is that there is a limitation of the size of the database on the NRF52. 

The better solution in my opinion is to avoid using the dsm database on the NRF52. What the NRF52 does is to simple do the provisioning and send the information, handle, keys back to PC without storing any handle. But this would require refactoring the code of the serial example, the provisioner etc. 

[wataru_m]

Hi Hung,

I see, thank you.
It might be an extreme analogy, but let me know if I'm wrong. 
Even, I am not thinking this is the best policy (In the sense that using DSM,).

Assuming I have a .json file with mesh network information.
If I want to reconfigure a node who participating in the network,
or if I want to add a new device to the network,
It may be no problem to prepare a new NRF52 which flashed mesh serial project each time and restore the database to NRF52.



I agree with your opinion.
I know I need to refactor, but I don't have any idea at the moment which source files are for.

Are the files listed in the "Serial" folder and the files listed in the "Provisioning" folder in the .emProject file subject to editing?

I also need to edit other Python files, right?
I think it will take time, but I would like to achieve this if possible.

Best regards,
Wataru

[Hung Bui]

Hi Wataru, 

For approach #1, keeping the dsm, I don't think you would need to modify the code (in nRF52 and pyACI). I haven't tried myself but my understanding is that you need to add the address, the device key, to the nRF52 to restore the database. What is missing is the code in python to automate the process. 

For approach #2, removing the dsm, the part that affect is not provisioning part but the configuration part where we use the configuration client to configure the server on the provisionee. The modification would require large code modification of the access layer and the model layer. I would suggest to go for approach #1. If it works for you we can avoid spending too much work on approach #2.