LAUNCHXL-CC1352P: Z-stack 1.2.2a End device can send data but could not receive data in some case.

It will take some time to change routing path. Do you wait a while to see if the routing path will be reconstructed?

I am waiting about 15 minutes, nothing happen. I sniff the packet and see route request send to the router address but seem it not respond.

With 44 devices on the network, how much time you expected it to finish reconstructed?

Can you provide sniffer and elaborate your issue on it?

I will build a network with less device and try to sniff when issue happen.

How can i send you in private? There are some sensitive data i  don not want public here.

I am not TI employee so if you have any concern, please don’t send any sensitive data in private.

I have send you all the logs

I need your network key to decrypt your sniffer log and can you elaborate your issue on sniffer log?

The key is: 01:03:05:07:09:0B:0D:0F:00:02:04:06:08:0A:0C:0D

0x5722 is the address of the CC2652 ZR,

From packet 1900 i unplug the ZC, ZED connect to the ZR.

Focus with 0xbb2e (CC2630), on packet 2424 it rejoin network through the ZR.

When ZC back on and network started, packet 11252 it send back status when i press on/off button on the device.(Can send data normally, but it could not receive )

Packet 50445, ZC can send on/off command to device 0x6827(CC2630) it connect directly to the ZC, not through ZR.

On the packet 19018, ZC send Route request because it could not send on/off command to 0xbb2e (connect through ZR 0x5722 ) but without the reply.

I am waiting and continue to try on packet 222630

According to end node announcement on packet 2424, IEEE address of end device 0xbb2e is not the same as route request command on  packet 19018 which you claim "ZC send Route request because it could not send on/off command to 0xbb2e (connect through ZR 0x5722 ) but without the reply."

Yes, true, that IEEE address is of the ZR 0x5722, coordinator send Route request to the router because device 0xbb2e is connected to it. My idea is right?

Or you mean ZC must send route request like in packet with destination address is 0xbb2e?

You can see on the packet 50445 it send to itself but device 0x6826 connected direct to  ZC.

So this is Z-stack bug or what causing it?

I apply the patch here for fix broken route: e2e.ti.com/.../883629

Version of the SDK is 3.40.

For 1.2.2a devices how can i set End Device Timeout for specific zigbee/z-stack version? In the ZNP/ZR firmware or by the application?

The patch here: . I both try enable and disable Child Aging by set zgChildAgingEnable in zglobals.c

For Z-Stack 1.2.2a, you have to enable zgChildAgingEnable to TRUE for the NLME_SendEndDevTimeoutReq to be sent during ZDApp_AnnounceNewAddress.

Disabling child aging for the Z-Stack 3.0 devices most likely explains why there are no Parent Annce messages to resolve the child conflict.

Regards,
Ryan

I will send you the log of the zgChildAgingEnable = True in pm

I have no further information to provide based on the sniffer log.

Regards,
Ryan

So how about my previous question about End Device Timeout for version 1.2.2a?

I read in the zglobals.c:

//=======    Child Aging PARENT ROUTER (ZR/ZC) configuration   ========
// You can setup a router to support Child Table Aging in 1 of 2 modes of
// operation.  The first mode is NWK_PARENT_INFO_END_DEVICE_TIMEOUT_MSG and it
// expects end devices to use End Device timeout message periodically as a means of a keep-alive
// notification to the parent.  The other mode is NWK_PARENT_INFO_MAC_DATA_POLL
// which uses the end device's MAC POLL request as the keep-alive notification.
// The first method is preferred for new devices that will be RxOnIdle = FALSE as
// it does not requires constantly sending data request frames other than needed by polling data from parent.
// The second method is compatible with older end devices without the need for
// specific child aging support.
//
// The method supported by the router (or coordinator) is determined at build time
// by setting zgNwkParentInformation to either NWK_PARENT_INFO_END_DEVICE_TIMEOUT_MSG
// or NWK_PARENT_INFO_MAC_DATA_POLL.
//
// End device built with Child Table Aging support both methods, the method is
// determined by the parent and communicated at run-time.

About z-stack 1.2.2a, you may wrong. I read the code of: ZDApp.c. It does send the child aging time out i set (10 seconds in this case) in ZDApp_AnnounceNewAddress. The sniffer is the firmware with child aging enable. I know this version not update, but the cc2630/cc2650 still an active products

void ZDApp_AnnounceNewAddress( void )
{
#if defined ( ZIGBEEPRO )
  // Turn off data request hold
  APSME_HoldDataRequests( 0 );
#endif

  ZDP_DeviceAnnce( NLME_GetShortAddr(), NLME_GetExtAddr(),
                     ZDO_Config_Node_Descriptor.CapabilityFlags, 0 );

#if defined ( ZIGBEEPRO )
  // Setup the timeout
  APSME_HoldDataRequests( ZDAPP_HOLD_DATA_REQUESTS_TIMEOUT );
#endif

  if ( ZSTACK_END_DEVICE_BUILD )
  {
    if ( zgChildAgingEnable == TRUE )
    {
      uint8 coordExtAddr[Z_EXTADDR_LEN];

      // Send the message to parent
      NLME_GetCoordExtAddr( coordExtAddr );
      NLME_SendEndDevTimeoutReq( NLME_GetCoordShortAddr(), coordExtAddr,
                                 zgEndDeviceTimeoutValue,
                                 zgEndDeviceConfiguration );
    }
  }
}

So the ZC has timed out the ZED and the ZED has rejoined the ZR while the ZC is off.  The ZC therefore has no knowledge that the ZED is active but typically will send a route request when attempting to send a ZCL command indirectly, and I would expect the ZR to reply with the updated route.

Ryan

No, in my test, first let all the ZED connected to ZC, pair the ZR in the last, then power off the ZC.

ZED will send orphan and rejoin to  ZR (those error ZED, not all), now i power back the ZC (ZNP) and then start the network.

I has seen the Route request ZC send the 0xfffc or ZR (destination address is ZR) and some time destination address is uncontrollable ZED, but after that problem still exist.

All ZED connect directly to ZC have no problem. I can reproduce this issue with only 3 devices: 1 ZC CC1352, 1 ZR CC2652 and 1 ZED CC2630, the first time it may not occur, but repeat some and it happen.

This is the real world problem after power outage, reboot/update server etc, but after many time/ many try I still could not fix it, you can some of my post here mention this.

This bug rarely happen because it not occur with 1 way ZED sensor, only send data but not receive command, for my devices is a light switch, it 2 way device.

DzungPV said:

I do see the Route request ZC send the ZR (destination address is ZR) and some time destination address is uncontrollable ZED, but after that problem still exist.

Can you provide a small/partial sniffer log capture which demonstrates this?

DzungPV said:

first time it may not occur, but repeat some and it happen.

Is there any network behavior which controls whether the issue occurs or not?

How many devices are bound to the ZC and do you increase NWK_MAX_BINDING_ENTRIES accordingly?  What is the POLL_RATE of the ZED and NWK_INDIRECT_MSG_TIMEOUT of the ZR?  Have you sought Koen Kanters advice on this matter since he has developed the zigbee2mqtt firmware that you are evaluating?

Regards,
Ryan 

I ask Koen Kanters about the issue, he take some help but not success.

One question ask earlier about router request send to 0xfffc address instead of ZR address or ZED address, what is that address for?

I think about problem with the ZR, it is ZR_light for CC2652. We still trying to fix the issue

Can you please provide a screenshot example of the route request in questions?  Typically a 0xFFFC network destination indicates a message broadcast to all routing devices.

Regards,
Ryan

This is the route request send when zigbee2mqtt failed to control the ZED, it does send to it short address but not answer from the ZR, you have any idea about it?

Yes, you can see in the screenshort.

For a non-MTO Route Request, if the ZR is within radio range then it should send a Route Reply if it contains the destination device address as a child (confirmed in my tests) or re-broadcast the Route Request for other routing devices in the network to process.

MTO Route Requests are broadcast throughout the network and you can learn more about this protocol in the Z-Stack User's Guide: http://dev.ti.com/tirex/content/simplelink_cc13x2_26x2_sdk_3_40_00_02/docs/zigbee/html/zigbee/z-stack-overview.html?highlight=many%20one#many-to-one-routing-protocol 

Regards,
Ryan

It in radio range, ZC can receive report for state. But not reply from the router with Route Request.

You test with ZED HA1.2.2a or 3.x?

3.x ZED but as we have discussed this appears to be an issue with the 3.x ZC/ZR routing devices.  If the ZC receives a route reply from the ZR then it will update its routing table and send the intended command packet, this should all occur automatically inside Z-Stack source but first the ZR should act upon the Route Request.  Please let me know what you discover from your ZR investigation.

Regards,
Ryan

The ZED i use running HA 1.2.2a, may be it cause the problem, i will try to test with 3.x ZED soon, but it seem cause by Z-stack, i see someone in the forum have problem with power lost and router too, but i could not find the link now.

The ZC send many router request but it not get reply for ZED devices connect to ZR, you can see it in my packet sniffer send to you by pm.

You can see in the screenshot below, ZED send data to ZC over the ZR, mean it include ZED record, but this device ZC could not send on/off command to it.

ZR is 0x4246 running 3.4 zr_light_cc2652, 0x3afc connected to ZR and send on/off report to ZC over it, but ZC could not send on/off command to it, that is the problem. Koen Kanters try many way to send AF command to get Route/control device but it not reply, and ZED not receive the command.

I would expect a 3.x ZED to behave in the same manner but it would be good to verify this as I've already mentioned that the ZR acted correctly when tested on my setup.  I did check your sniffer log and did not see any non-MTO Route Requests from the ZC which were not responded to.  Unfortunately, data reports from the ZED will not update the ZC's route table.

Regards,
Ryan

>  I did check your sniffer log and did not see any non-MTO Route Requests from the ZC which were not responded to.

Could you explain what the difference is and what to use in which use case?

Currently options: 0 is provided, AFAIK it maps to this, right?

options 0: MTO route request

options 1: Non-MTO route request

Hey Koen,

Route Request: http://dev.ti.com/tirex/content/simplelink_cc13x2_26x2_sdk_3_40_00_02/docs/zigbee/html/zigbee/z-stack-overview.html#route-discovery-and-selection 
MTO: http://dev.ti.com/tirex/content/simplelink_cc13x2_26x2_sdk_3_40_00_02/docs/zigbee/html/zigbee/z-stack-overview.html#many-to-one-routing-protocol 
MTO Route Request discovery period is CONCENTRATOR_DISCOVERY_TIME: http://dev.ti.com/tirex/content/simplelink_cc13x2_26x2_sdk_3_40_00_02/docs/zigbee/html/zigbee/network_configuration.html 

Regards,
Ryan

Thank you for the help. I have find the root cause of the problem: It is Child Aging