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.

ZC can not control ZED

Other Parts Discussed in Thread: Z-STACK, CC2530

Hi TIs,

I’m using CC2530 with z-stack home 1.2.2a. There are 1 coordinator, 1 router, and 1 end device in my network. First, the end device connected to coordinator, and coordinator can send command to control the end device. Now, I power off coordinator, and the end device change to router as its parent. After that, I power on coordinator. I find the coordinator can’t not control the end device because the end device send data request to route, not coordinator. But the end device can send report to coordinator.

1.Why my coordinator can’t send route request itself to update route table when the coordinator is not the end device’s parent?

2.Is there any way to keep correct route table?

3.By the way, I try to send route request myself from the host, but CC2530 can’t send command to air. Why does this happen?

Getmek

Eason

  • I had read several posts that report similar issue. I believe this is bug in Z-Stack so I suggest you to contact TI local representative to help you.
  • Hi Eason,

    Are you making sure that the coordinator is removing the end device from it's association table after it is turned back on? You can achieve this functionality with the child aging mechanism implemented in 1.2.2a, if you are not already using it. One method of child aging works by keeping track of the elapsed time between the last MAC data poll from a child device, and if it exceeds a certain time value the child device will be removed from the coordinator's association table. If the coordinator does not remove the end device from its association table after the end device has changed parents, sending a route request with the address of the end device will fail because the coordinator still thinks it is the parent of that device.
  • Just to be clear here, this behavior is not due to a bug in our stack, but rather the behavior defined by the R20 Zigbee specification. The R20 spec did not include anything that would handle this particular scenario, which is why the child aging mechanism was introduced in the R21 spec. Z-Stack 1.2.2a partially implements this child aging mechanism from the R21 spec, but it must be set up properly. With the eventual release of Z-Stack 3.0, the child aging mechanism (and all other R21 defined behavior) will be fully implemented.
  • This might be caused by unclear definition of Zigbee spec. However, if a device can deliver messages to ZC but ZC can't deliver messages to that device. It is obviously not applicable and end user won't accept it. As I know, there would be other problem if you enable child aging in Z-Stack Home 1.2.2a. You can refer to The Seven's post at e2e.ti.com/.../519168
  • Thanks for your reply.

    Hi JasonB,

    Does TI provide any solution or patch for this issue since enabling aging time makes side effect ?


    Hi YiKai,

    Obviously you met this issue earlier, could you kindly give us any recommended solution ?

    Eason
  • I have no good solution for this. As Jason replied, eventual release of Z-Stack 3.0 should solve the issue unless TI can provide patch to fix this problem on current Z-Stack.
  • Hi Eason

           no matter  whether there is side effect or not with  the child  aging of Zstack 1.2.2a

          Trust me  that is  the only way to solve this problem  until now , Shorten the Enddevice Time out value so that  ZC would update the routing path!

         

  • Hi all,
    This issue have be fixed.
    Thanks
  • Can you share how this can be fixed?