• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 57 subscribers
  • Views 613 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC1352P: Remove "old" device from the network

Randy Gómez
Intellectual 525 points
Part Number: CC1352P
Other Parts Discussed in Thread: Z-STACK

Hello Ryan

We are working on an application based on the CC1352P and Z-Stack 5.20.00.52. When we remove a device that is OFF, the device is successfully removed from the network. When this device is powered up again after some minutes, it announces itself to the network, and continues to send messages. The device is not on the Linux Zigbee server, but it is linked to the Coordinator. Is there any automatic way to remove devices that are advertised on the network and have been removed previously and which are not in the device database anymore?


BR,

Randy

  • 0
    Guru 735545 points

    When you receive device announcement from unknown or unwanted device, you can send leave request to ask the device to leave your network.

  • 0
    TI__Guru**** 209487 points

    Hello Randy,

    As you've observed, a ZDO_MGMT_LEAVE_REQ does not remove all device information (keys, binding and association/routing/neighbor table entries, etc).  Instead, the ZNP waits until ZDO_LeaveCnf (status == ZSuccess) or ZDO_LeaveInd to call ZDApp_LeaveUpdate, which will not happen while the device is offline.  You could try using ZDO_SEC_DEVICE_REMOVE, ZDO_REMOVE_LINK_KEY, and/or ZDO_EXT_SEC_APS_REMOVE_REQ commands from your gateway to manually force removal of this information locally, or you can modify the ZNP code to alter it's behavior towards your intended goal.  The other option, as YiKai suggested, is to wait until the device comes back online to retry.  You will just want to make sure that the gateway's device database stays in sync with the ZNP's stored network information, otherwise the misalignment will cause issues when attempting to send device commands.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Expert 1350 points

    Hi Ryan,

    Just taking over as Randy will come in later today: if we would change the ZNP behavior not to wait for the leave confirmation and, in case the deleted device would send further messages, it will automatically get a "Remove" back as its ID is not the module's database anymore?

    If yes, then we would not need to wait for it to come back and then delete again.

    Regards
    Peter

  • +1 in reply to Peter Hoyer
    TI__Guru**** 209487 points

    Hi Peter,

    Unfortunately, so long as the device has the NWK key it will be able to continue communicating on the network.  The APS key is removed so it would not be able to further process APS packets involving key handling.  So you would need to either update the NWK key using APS encrypted requests (would have to be unicasted to each device on the network and confirm reception with an APS ACK) or wait for the device to come back online and trust that it leaves when requested.  These security concerns are partly why Install Codes were introduced to Zigbee 3.0.

    Regards,
    Ryan