I want to recover control provisoned device, when I reopen the PyACI script and reset the 52840 DK

[oplinux]

Dear friends,

When I reset 52840 DK and reopen the PyACI script , then, reloading the DB(database/example_database.json), I found the provsioned device can't be controled again.

I refrence this case ，however,  we can't get any data from the provsioned device, attach my test code:

db = MeshDB("database/example_database.json")
p = Provisioner(device, db)
device.send(cmd.DevkeyAdd(db.nodes[0].unicast_address, 0, db.nodes[0].device_key))
device.send(cmd.AddrPublicationAdd(db.nodes[0].unicast_address))
cc = ConfigurationClient(db)
device.model_add(cc)
cc.publish_set(8, 0)
cc.composition_data_get()

and the test log:

E:\bluemesh\fortest\nrf5_SDK_for_Mesh_v2.2.0_src\scripts\interactive_pyaci> C:\Users\admin\AppData\Local\Programs\Python\Python38\python.exe interactive_pyaci.py -d COM4

    To control your device, use d[x], where x is the device index.
    Devices are indexed based on the order of the COM ports specified by the -d option.
    The first device, d[0], can also be accessed using device.

    Type d[x]. and hit tab to see the available methods.

Python 3.8.6 (tags/v3.8.6:db45529, Sep 23 2020, 15:52:53) [MSC v.1927 64 bit (AMD64)]
Type 'copyright', 'credits' or 'license' for more information
IPython 7.23.1 -- An enhanced Interactive Python. Type '?' for help.

In [1]:

In [2]: db = MeshDB("database/example_database.json")
   ...: p = Provisioner(device, db)

In [3]: 2021-07-02 17:32:31,468 - INFO - COM4: Success
2021-07-02 17:32:31,469 - INFO - COM4: Success
2021-07-02 17:32:31,473 - INFO - COM4: SubnetAdd: {'subnet_handle': 0}
2021-07-02 17:32:31,481 - INFO - COM4: AppkeyAdd: {'appkey_handle': 0}
2021-07-02 17:32:31,482 - INFO - COM4: AppkeyAdd: {'appkey_handle': 1}
In [3]:

In [3]: db.nodes[0].unicast_address
Out[3]: 0010

In [4]: device.send(cmd.DevkeyAdd(db.nodes[0].unicast_address, 0, db.nodes[0].device_key))
   ...: device.send(cmd.AddrPublicationAdd(db.nodes[0].unicast_address))

2021-07-02 17:32:46,728 - INFO - COM4: DevkeyAdd: {'devkey_handle': 8}
2021-07-02 17:32:46,729 - INFO - COM4: AddrPublicationAdd: {'address_handle': 0}In [5]:
In [5]:
In [5]: cc = ConfigurationClient(db)
   ...: device.model_add(cc)
   ...: cc.publish_set(8, 0)
   ...: cc.composition_data_get()

2021-07-02 17:32:56,990 - INFO - COM4: Success
In [6]:

In [6]:

In [6]:

In [6]: cc.composition_data_get()

In [7]: 2021-07-02 17:33:17,492 - INFO - COM4: Success
In [7]:

In [7]:

Could you give me some advice for realize this functionality?

Thank you in advance.

[oplinux]

Thank you Hung,

I have read Section 3.10.6. There are two questions:

a)  Which serial command can listen to the Secure Network Beacon?  in the tutorial, I only found Provisioning commands has a "Scan Start" option which is used to scan unprovisioned beacons.

b) Similarly, Which command can I called to start the procedure of update IV Index? the existing mesh network's IV index  is 287454020, the new provisioner's IV index is 0.

My 52840 DK flashed serial example(nrf5_SDK_for_Mesh_v5.0.0_src\examples\serial)

Best regards,

Oplinux

[Hung Bui]

Hi Oplinux, 
Please note that we are talking about Secure Network Beacon, not the unprovisioned beacon. This beacon is sent automatically by other mesh nodes in the network. The node should be able to catch this beacon after a few minutes. But only if it has joined the network properly. 

It's also possible to update the IV index manually from the node. We provide an API on the serial interface that you can call from the Python side: SERIAL_OPCODE_CMD_MESH_NET_STATE_SET (0xAE) 

Following are the info you need to feed in the call: 

typedef struct __attribute((packed))
{
    uint32_t  iv_index; /**< The IV index to set.*/
    uint8_t   iv_update_in_progress; /**< Value indicating the phase of the IV update process. */
    uint16_t  iv_update_timeout_counter; /**< Timeout counter for IV update process. */
    uint32_t  next_seqnum_block; /**< The first sequence number block which is not yet allocated. */
} serial_cmd_mesh_net_state_set_t;

You would receive SERIAL_OPCODE_EVT_MESH_IV_UPDATE_NOTIFICATION after the IV index is updated. 

But I would suggest to verify that your new provisioner can actually talk to the network without doing IV index (reinitialize the network so that IV index is 0). Just to verify that everything else works, then you can start updating the IV index. 

[oplinux]

Thank you Hung,

I have been tryed this command "SERIAL_OPCODE_CMD_MESH_NET_STATE_SET", it works well, however, you konw, this process should manually operate. I want to use IV index recovery procedure to automaticly finish it. so, I faced two questions:

a) In the provisoner side, how to scan secure network beacon to get IV index value, which serial API can be used to realize this purpose? I have tested new provisioner can't  talk to the network without doing IV index.

b) For start IV index recovery procedure, which serial API can be used to?

Best regards,

Oplinux

[Hung Bui]

Hi Oplinux, 

As I mentioned earlier, the Secure Network beacon scanning and the IV index recovery procedure should be done automatically by the mesh stack. You don't need to call a function to scan or do anything to recover the IV Index. It's the same as when a node is inactive for too long it should recover automatically without the need of a call from the application. 

Have you tried to leave the new provisioner for a few minutes ? But you need to make sure that it has the correct network key. 

[oplinux]

Thank you Hung,

I'll try it again. The new provisioner has been assigned the correct network key. However, when the new provisioner sends messages to other nodes, those nodes can't parse it, because the IV index value of the mesh network is 287454020, the IV index value of the new provisoner is 0.

For the mention "the Secure Network beacon scanning and the IV index recovery procedure should be done automatically by the mesh stack.",

Could you tell me this process will take about how long it will take to finish?

The only thing I need to do is wait?

Best regards,

Oplinux