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.

How can I remove offline(unknown or obsolete) node in a remote router's assocdevlist?

Other Parts Discussed in Thread: Z-STACK, CC2530

How can I remove offline(unknown or obsolete) node in a remote router's assocdevlist?

I am working on home automation system. Generally there is a gateway device with ZNP module as a ZigBee coordinator. Serveral router or enddevice radios integrated on controllable or reporting device (such as lamp, sensor, switch etc.). The problem is found in my testing setup and I believe it will be also a issue in future production stage.

Okay, the following are the details. When ZNP is started up, 1 or more (assume 3 and numberred 1, 2, 3) router device may join the PAN formed by ZNP. So 1 coordinator and 3 routers are in the current ZigBee network. And assume there is a situation that router 1 is close to ZNP and just associated with ZNP directly. But router 2 and 3 have some distance from ZNP, so they are both joined the network as children of router 1. The network topology is actually very simple. ZNP has one child which is router 1 and router 2 has two children which are router 2 and 3. Then for some reason, router 3 is just powered down and never powered back as a normal ZigBee device. The the issue comes, router 3 is always existed in the assocdevlist of router 2. Everytime when the gateway application performs device discovery with IEEE_ADDR_REQ there is no response from the router 3 (because it doesn't existed in the network anymore, I call it offline or obsolete). Worse than that, if there are too many offline or obsolete devices, router 2 may not accept new joining device. That means those offline devices occupy the assocdevlist space in router 2.

So the question is how to remove theose obsolete node(s) from assocdevlist in a remote device (always router type)?

I considered some possible solutions but not reasonable under all conditions.

(1). Send ZdoMgmtLeave request, but this request needs a known IEEE Address. IEEE address may be looked up through Z-Stack Address Manager when access ZNP directly. That means we may get the IEEE address of device in the assocdevlist on ZNP but not other remote router device in network.
(2). Send MGMT_LQI_REQ to discover device in network instead of sending IEEE_ADDR_REQ. Yes, this may avoid waiting response from offline device(s). But it doesn't solve the issue that router 2 may not accept new joining if its assocdevlist is full of obsolete devices.

Could anyone figure me out how to implement a workable solution? All I description is based on Z-Stack Home 1.2.1 and CC2530 radio (ZNP or devices).

  • You can deploy ZIGBEE_CHILD_AGING in Z-Stack Home 1.2.1. The parent node with this capability would age out non-polling device from association list after KEEPALIVE_TIMEOUT_MAX+1. You can do the following setting to enable ZIGBEE_CHILD_AGING.
    1. enable “ZIGBEE_CHILD_AGING” on compile option
    2. shorten KEEPALIVE_TIMEOUT_MAX
    3. set “zgChildAgingEnable = TRUE” in the file ZGlobals.c.
  • Hi YK,

    Thanks for your reply. Just did some search on "ZIGBEE_CHILD_AGING" topic, and still get some questions.

    1. What does non-polling mean? Does it count network link status udpate frame or any other message polling?
    2. In case the child is timed out, will it be removed from network or just the associated list of its parent device?
    3. If the a timed out child comes back (let's say it is powered up after a long time), can it restore the network state and automatically work just as a joined device? Or does it need perform another network-join procedure?
  • 1. No, it only counts polling.
    2. It only remove the non-polling device from association list.
    3. The device use rejoin to connect back. It won't do association again.
  • So it is intended for sleepy End-Device applications. If there are all routers and one router is taken away, is there a way to remove a nwkaddr ( ieeeaddr maybe unknown since it's offline) item from assocdevlist of a router (not ZNP itself)?
  • Yes, it is only for sleeping end devices. For router, you have to use leave request and wait for leave response.
  • As I described in my original post, the "Mgmt Leave Request" needs a known IEEE address. But sometimes, if the target is offline or taken away, we cannot get its IEEE address. So removing a node with nwkaddr-known-only is really the pain for me now.

    Currently, the only way is to make its parent reset the network state. But this method has many side effects such as it will also clear all other children association info, ZCL group/scene data and require a network rejoin.
  • Any updates on how you solved this ?
  • You can try to use APIs in AssocList.h to remove it.