• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 58 subscribers
  • Views 1315 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Problem in update to Association table with Coordinator & Router in the network

Arul
Prodigy 205 points
Other Parts Discussed in Thread: CC2530

I'm developing an application with a zigbee coordinator, 5-10 routers and around 20 end devices and facing a serious problem at the moment in the customer site. 

Settings:  CC2530 with zstack version 2.3.0.1.4.0 with stack profile as ZigbeePro,  NV-RESTORE enabled for all devices.

Scenario to reproduce the issue:

Assume the setup with following devices: 

EndDevice (E1) is connected to Coordinator (C) and Router (R) with End Device (E2). The E1 acts a light device and E2 as the switch device. All the devices are switched-on and working fine. Child count in Coordinator is now 2 (Router (R), End Device (E1)

Step 1: Switch OFF the Coordinator (C)

Result: The End Device (E1) now gets re-connected to Router(R). Router forwards Device Announce request packet to all devices in the network. [ Coordinator is not aware of this packet, as it's switched off). Communication with R, E1 and E2 is working fine.

Step 2: Switch ON the Coordinator (C)

Issue 1: Coordinator doesn't update its Association Table (still E1 remains in the table).

Issue 2: Child count in Coordinator is stil 2 (Router (R), End Device (E1)

Issue 3: When a management application issue a command(to turn on light to E1)  via Coordinator, the End Device (E1) doesn't receive the request from the Coordinator.

The issue 3 is a serious issue in my application, as anytime the routers or coordinator (A/c powered) can go down and disturb the communication in the network. As the result, the remote applications (from ethernet or gsm used in the coordinator) can't communicate to the end devices.

Please quickly respond.

 

Regards,

Arul

  • 0
    TI__Genius 9325 points

    Hi Arul,

    This problem is common in ZigBee network, not especially on TI Z-Stack. This happens when a child end device(non-RX-on-idle) rejoins another parent while the original parent is powered off and can't receive the device announce from the end device as you described. Since the former parent still thinks the end device as its child, it doesn't send out the messages heading to the end device over the air and waits for data request(poll) from the end device while the end device will poll the new parent.

    There can be two kinds of workaround to remove the former child from the association list and we are working on them: 

    1. Checking network/MAC source addresses
         This method is useful in case that the former end device sends messages to the former parent first. The implementation scenario would be as following:
          - When a router/coordinator receives Data Indication, it checks if the network source address and the MAC source address of the incoming message are the same. If they are different, the message is not from a 'direct' child. If the originator is not a direct child and the network source address(in case of ZigBee Pro) indicates it is an end-device child of the router/coordinator, the router/coordinator needs to remove the originator from its association list.
          - To avoid being affected by repeated broadcast messages, the messages with MAC/network broadcast destination address should be disregarded.

    2. Using fake device announce from the new parent
         This method is more general. This is applicable not only for the above case but also for the case that the former parent is supposed to send to the former child first and the former child never sends anything to the former parent before it receives. This workaround would be under the following scenario:
          - The former parent(any router/coordinator) that has just re-powered up sends a broadcast private message. Let's name this massage 'DeviceAnnceReq'. The destination would be 0xFFFC(all routers and coordinator) and the message should contain the number of end-device type children and the network addresses(in case of ZigBee Pro) of them.
          - When existing routers get DeviceAnnceReq, they check if there are any children in there association list, duplicated with the list in DeviceAnnceReq. If there are, the routers send DeviceAnnce containing the network address and the extended address per each of duplicated children. This 'fake' DeviceAnnce is not the same as the one that has been repeated when the new parent has received a DeviceAnnce from its new child because the network source address of the DeviceAnnce message is different. However the DeviceAnnce still has effect as long as it delivers the correct network address and extended address in the payload.
          - When the former parent  receives the fake DeviceAnnce about the former child, it will remove the former child from its association list. You don't need to implement this step because it will be done by the stack.

    - Cetri

     

  • 0 in reply to Cetri
    TI__Mastermind 19350 points

    Indeed, this shortcoming to FFD's parenting, adopting, and acting as foster parents to RFD's is endemic to ZigBee, and not specific to the ZStack per se. I have opened a bug report for this observation and recommended a fix that whenever a RFD changes parents in its lifetime, then it shall always have to set a reload timer for some reasonable period and periodically repeat its device announce for the rest of its life. The former parent missing the device announce can be caused by interference and other factors, not just by the parent being off altogether. So, in the meanwhile, a very simple fix for this problem is to add code to a ZED Application to send a device announce whenever its AF_DATA_CONFIRM_CMD is not ZSuccess.  Sending a device announce is pretty painless:

    (void) ZDP_DeviceAnnce(_NIB.nwkDevAddress, aExtendedAddress, _NIB.CapabilityFlags, FALSE);

    So something like this in the Application layer

    UINT16 GenericApp_ProcessEvent( byte task_id, UINT16 events )
    {
      afIncomingMSGPacket_t *MSGpkt;
      afDataConfirm_t *afDataConfirm;

      // Data Confirmation message fields
      byte sentEP;
      ZStatus_t sentStatus;
      byte sentTransID;       // This should match the value sent
      (void)task_id;  // Intentionally unreferenced parameter

      if ( events & SYS_EVENT_MSG )
      {
        MSGpkt = (afIncomingMSGPacket_t *)osal_msg_receive( GenericApp_TaskID );
        while ( MSGpkt )
        {
          switch ( MSGpkt->hdr.event )
          {
            case ZDO_CB_MSG:
              GenericApp_ProcessZDOMsgs( (zdoIncomingMsg_t *)MSGpkt );
              break;

            case KEY_CHANGE:
              GenericApp_HandleKeys( ((keyChange_t *)MSGpkt)->state, ((keyChange_t *)MSGpkt)->keys );
              break;

            case AF_DATA_CONFIRM_CMD:
              // This message is received as a confirmation of a data packet sent.
              // The status is of ZStatus_t type [defined in ZComDef.h]
              // The message fields are defined in AF.h
              afDataConfirm = (afDataConfirm_t *)MSGpkt;
              sentEP = afDataConfirm->endpoint;
              sentStatus = afDataConfirm->hdr.status;
              sentTransID = afDataConfirm->transID;
              (void)sentEP;
              (void)sentTransID;

              HalLcdWriteStringValue("AF Cnf", sentStatus, 16, HAL_LCD_LINE_3 );  //ggg
              // Action taken when confirmation is received.
              if ( sentStatus != ZSuccess )
              {
                // The data wasn't delivered -- Do something

                // Ok then, I'll do something like re-send my device announce!

               (void) ZDP_DeviceAnnce(_NIB.nwkDevAddress, aExtendedAddress, _NIB.CapabilityFlags, FALSE);

              }
              break;

  • 0 in reply to Dirty Harry
    Intellectual 645 points

    Folks,

    Was there any official work around implemented for this? I have a similar case but not sure same. ZED keeps polling ZR and no messages come from co-ordinator like setting up reporting interval etc. But in my case even if I reset the end node in which case it generates device announce, the problem doesn't get solved. Am I missing anything?