Some requests in a Zigbee SED always return a success status instead of waiting for a response.

[Jorge Alves]

Dear ST,

I am developing an end device to my solution with the ability to report some measured values every minute.

The device successfully enters and exits a standby status and reports back.

Now I am trying to devise some kind of network management to the devices (join new networks, leave old ones, detect if there is a coordinator in the network etc.). They way I achieved this in my non-sleepy devices was through route discoveries to the coordinator. If a route is found, it is still a valid network. The problem arises in my sleepy end devices where some request responses (including a Route Discovery) seem to be ignored and the IPCC triggers the callback always with a success status.

As I understand it the messages are pooled and managed by the parent, but I thought it would still trigger the callbacks when received even if blocking the application.  

I tried to set the RxOnIdle capability to true, but this seems to not fix the issue.

Then I thought it was because of the RFD firmware implementation changing the flow of execution to return a success status instantly, so I tried running the same code with an FFD device. This felt like a bad idea, and it didn't fix the issue.

I tried to use a NlmeRejoin, but this throws an invalid request when the device startup from persistence. In this case, I thought a Startup from persistence means that a device is technically in a network and only resends a device announce. Why does it throw an invalid request when the only change in the execution flow is the startup from persistence?

What is the proper way to detect if a device still has a valid working parent?

I didn't use end device timeouts (It's set to 0xFF on network join) because I found it messed with my low power configuration, power cycling and reliable communications.

I'm waiting on a sniffer which maybe could help me understand better each function, for now I am lost.

[Ouadi]

Hello @Jorge Alves,

As I understood from your description, your main issue is how to detect the lost of the parent from the sleepy end device side, the proper way is to register a filter callback at the startup with the right indication status.

Actually, when the parent is lost, the stack trigger a ZB_NWK_STATUS_CODE_PARENT_LINK_FAILURE through the callback when the filter is enabled, on the reception of this information, the end device may perform a rejoin process. 

Please find on this post the indication to implement this feature.

Kind regards,

Ouadi

[Jorge Alves]

Hi, Thank you for the quick answer.

I would have to send a request to check if the parent is lost, right? The SED will be on just to report values for now. I disabled end device timeout so it won't be sent.

And is the route discovery request callback firing instantly always with a success status intended behaviour? Even when I know the target doesn't exist? Or should it trigger a ZB_NWK_STATUS_CODE_NO_ROUTE_AVAILABLE?

Sorry for the volume of questions.

[Ouadi]

Hi @Jorge Alves

To detect a parent lost properly with no additional power consumption I recommend to follow the steps described previously, no need to send continuous messages for the check. 

ZB_NWK_STATUS_CODE_NO_ROUTE_AVAILABLE is raised when the device fails to route a data packet. 

Regards,

Ouadi

[Jorge Alves]

I tested it, and it works yes.

How does it check if the parent is lost? Is it at startup from persistence? I thought it didn't

[Ouadi]

Hi @Jorge Alves 

The parent link failure detection mechanism is managed by the stack once the network is established between the parent / end device, when the parent is lost, polling requests will fail successively leading to raise the flag of parent link failure, the stack passes then the indication to the application through the network status. 

Regards,

Ouadi