How to reset a remote node using the Mesh provisioner example in NCS 1.9.1

Hello Experts,

I am trying to realize the following sequence

1) Reset button pressed on the remote node.

2) Remote node intimates the Mesh provisioner node by sending a message to it.

3) Mesh provisioner node initiates a node reset procedure remotely.

Could you please guide me through the process? I am using the nrf52832 DK as a provisioner and nrf52840 Dk as the sensor server/sensor client.

Thank you!

Parents
  • Susheel said:
    The remote node does reset and starts to broadcast unprovisioned beacons.

    At least that sounds promising.

    Could you try increasing the timeout using bt_mesh_cfg_cli_timeout_set and see if that makes a difference?

    Regards,

    Elfving

  • Hello Elfving, I have increased my configuration timeout but, I still see -116 being returned. 

    I have found that my remote node in fact resets due to a hard fault when it receives the reset command. Any idea why?

    P.S sorry for the delayed responses. I am juggling tasks at the moment.

    Update: for the fault, I just had to increase the stack size of the mesh_adv thread. But, I still see the timeout returned for the function call even after increasing the cfg_cli timeout to 4 times the original. Please advice.

  • Susheel said:

    P.S sorry for the delayed responses. I am juggling tasks at the moment.

    Hehe likewise, sorry about the delay.

    Have you gotten any further with this? I understand that if it works, it works, though getting a timeout error was a bit surprising. 

    The config client shall receive a Config Node Reset Status message after sending a Config Node Reset.

    With the hardfault being fixed, is there any other relevant log coming from the node that is being reset? If the node fails to send the status message (and it still resets) it should be observable in the logs.

    Regards,

    Elfving

Reply
  • Susheel said:

    P.S sorry for the delayed responses. I am juggling tasks at the moment.

    Hehe likewise, sorry about the delay.

    Have you gotten any further with this? I understand that if it works, it works, though getting a timeout error was a bit surprising. 

    The config client shall receive a Config Node Reset Status message after sending a Config Node Reset.

    With the hardfault being fixed, is there any other relevant log coming from the node that is being reset? If the node fails to send the status message (and it still resets) it should be observable in the logs.

    Regards,

    Elfving

Children
  • Hello Elfving,

    Apologies for the delay. I was able to get some logs from the provisioner. Looks like the reset status message with opcode 0x804A does get published from the remote node (address 0x006 in the attached pic) to the provisioner (address 0x0001) after receiving the reset request with opcode 0x8049. But the timeout occurs before the status gets received. 

    I tried increasing the cfg_cli timeout by multiplying it by 100 times. You can see the time difference in the log.

    Please advice.

  • I am trying to find what is throwing 116 here. I assume you've added the log for these lines in the SDK? 

    Could you show me where, so that I know where the 116 is coming from.

    Regards,

    Elfving

  • Hello Elfving,

    Sorry about the delay again. 

    This error seems to be coming from line. Please suggest.

  • Also, Please correct me if I am wrong. Since the callback timesout before it sees the reset status message, the provisioner doesn't remove the node from its CDB. Even though there is no chance for an attack(in my case atleast), I am not going to be able to reuse the address used by the node which got reset.

    Is there a way to manually remove the node from the CDB?

  • Could you show me how you are calling bt_mesh_cfg_node_reset? And I assume you are seeing the same issue when you are simply calling it from the provisioner without the first step of the remote node triggering it?

    Susheel said:
    Is there a way to manually remove the node from the CDB?
    Susheel said:
    Since the callback timesout before it sees the reset status message, the provisioner doesn't remove the node from its CDB.

    Well that might depend on the provisioner, but I guess there would be no safe way for it to remove it from CDB without the status message. I do not think bt_mesh_cfg_node_reset does this though, it should be done manually.  Use bt_mesh_cdb_node_del to delete the node from CDB. Then refresh the keys. To perform key-refresh, use bt_mesh_cfg_cli_net_key_update to upload a new key to all nodes, then use bt_mesh_cfg_cli_krp_set to switch key-refresh phase on all nodes.

    It would of course be preferable to find the issue here instead of betting on bt_mesh_cfg_node_reset to function correctly, but giving no response.

    Regards,

    Elfving

Related