Network No Route For End-Device Connected To Repeater.

The counting of the position is like the array counting starting from 0, which means that the 5th bit is the 6th element or it starts from one, meaning that the 5th bit is actually the 5th element?

Looking at AF.h i see the following line:

#define AF_DISCV_ROUTE                     0x00   // This option is no longer available, and is included for backwards compatibility

It would have been the fifth bit of zero through seven.  Good point Ayman, I had only thought that the latest Z-Stack would have performed route discovery automatically.  What device and Z-Stack version are you using?  This does not invalidate the capability to perform route discovery manually.  Can you provide a terminal and sniffer log of the transaction?  You can also search the forum for similar E2E threads.

Regards,
Ryan

I'm using ZStack 3.X.0.

I can send you the log of the repeater which causes me no route problems and a sniffer log of the repeater that doesn't cause me the no route problem.

Develco is the problematic one.

Can't append them to the reply, any email I can send them to?

So the issue only concerns certain repeater (ZR) models?  It would seem that you should be contacting these manufacturers for more information.  Or perhaps the Zigbee2MQTT forum has experienced similar behavior before and can provide more assistance.  You can compress the logs to a zip file and attach them to your reply if that is the concern.  I would prefer to keep this investigation on the external forum.

Regards,
Ryan

Here are the logs:

Sniffing Log.rar

I've tried performing ZDO_EXT_ROUTE_DISC with NwkAddress of the end-devices and option = 0x01 but nothing has changed. I receive status:SUCCESSS in the answer but doesn't seem to change anything.

Thanks for sending the logs, however they are encrypted as no NWK key has been provided.  I would also like to know what packet range I should be referring to since the logs cover thousands of messages.  The ZDO_EXT_ROUTE_DISC options are shown below and I am not sure of your intended effect as it depends on your ZC settings.  You should also ensure that the broadcast radius is sufficient.

//Route request command option
#define MTO_ROUTE           0x01       // Used in option of NLME_RouteDiscoveryRequest() and rtgTable[]
#define NO_ROUTE_CACHE      0x02       // Used in option of NLME_RouteDiscoveryRequest() and rtgTable[]
#define RTG_RECORD          0x04       // Used in option of rtgTable[]
#define MTO_ROUTE_RC        0x08       // Sender has route cache. Used in option of rtgTable[]
#define MTO_ROUTE_NRC       0x10       // Sender doesn't have route cache. Used in option of rtgTable[]
#define DEST_IEEE_ADDR      0x20       // Used in option of route request command frame
#define MULTICAST_ROUTE     0x40       // Ued in all three places

Regards,
Ryan

Thank you for providing the NWK key.  The Develco 0x8bbd is broadcasting the ZC Route Request but not responding with a Route Response/Record.  I've also noticed that 0x7560 (Philips) appears to be the parent of 0x1c38, not 0x8bbd.  It appears that the neighbor connection between 0x0000 and 0x8bbd/0x7560 is recovered after some time, although I find it odd to not see any Link Status messages from the ZC in the sniffer log.  Please make sure all devices are close enough to the sniffer so that you can capture all packets.  You will need to contact the Develco/Philips device manufacturer to further determine why the device is behaving in this manner, given that other Routers are reported to act as expected.

Regards,
Ryan

Hi Ryan,

Thank you so much, I'm in contact with develco regarding the no routing issue but with no avail yet.

I get a "No ACK Layer APS" any idea what this mean? What consequences does it have?

What is the context of the "No ACK Layer APS"error?  How does it appear within your system?  APS ACKs exist when enabled, as discussed in the End to End Acknowledgements section of the Z-Stack User's Guide.

Regards,
Ryan

Last Question before marking the Thread closed.

Does the ZigBee Specification explicitly forbids an end device from sending route requests?

The No Route Error was caused because my end-device sent route requests when the coordinator is turned off and the Smart Plug changes its relationship to the thermostat as if it were a router and this obviously causes the communication to break down.

This is not normal behavior for end devices and something I only expect from routers

Zigbee End Devices should be capable of sending Route Requests just like other Zigbee nodes types (Routers and Coordinator).  It could be challenging to provide a Route Response/Reply in cases where the ZED rarely requests data from its parent node (i.e. infrequent polling).  ZED children can change their Router node parent if it can no longer find its original, this is a process known as Parent Lost procedure.

Regards,
Ryan