Zigbee - how to check for disassociated / powered off Coordinator (ZC)

I am in final stage of pre-production code and would like the associated indicator LED to go to OFF

when the coordinator is lost or powered down. I can detect it joining ..

The following works for turning on the association status router LED but when I disconnect the

power from the coordinator it does not turn off the LED. Obviously I need to do this differently.

This runs inside the while loop of a supervisory task

while(1)    {    if (ZB_JOINED())

                                 {     zb_status_led_on();

                                 }

                          else       zb_status_led_off();

                          vTaskDelay(pdMS_TO_TICKS(5000);

                     // Other code here

                    }

Can someone tell me a reliable method to detect that the coordinator is no longer

communication or powered off ?

Regards

Rob

Parents
  • *Actually* what I need to check is that a send from a ZR device to the gateway ZC is successful. Association check should only reveal whether there is another router joined to the ZR.

    I am not seeing the send status report as failed when the ZC is removed, for the last attribute sent. Is there a flag set somewhere that shows the send status for the last outgoing message to the ZC ?

  • Hi Rob,

    I am sorry for the delay. Due to public holidays in Norway the office has been closed for a few days.

    The device should be aware that the packet failed if it expects some sort of ACK or response. For attributes this will be APS ACK, and you can see that the device is aware that it failed if you look at a sniffer log, as the device will retry the packet. However, much of this is handled internally by the stack, so there is no easy way to get a flag that it failed for attribute reports as far as I know. You can use NLME status indication to handle receiving an NLME status indicating an error. For this you can add the signal ZB_NLME_STATUS_INDICATION to the zigbee stack event handler (zboss_signal_handler). You will then have to check what the status is and handle accordingly. You can find the different types of network status codes in zb_nwk_command_status_t , which is defined in zboss_api_nwk.h.

    Another option is to check the neighbor table for the ZC. If the ZC is a neighbor of the ZR it will have an entry in the neighbor table of ZR. If the ZC becomes unreachable then this entry will become stale after some predefined time.

    Best regards,

    Marte

Reply
  • Hi Rob,

    I am sorry for the delay. Due to public holidays in Norway the office has been closed for a few days.

    The device should be aware that the packet failed if it expects some sort of ACK or response. For attributes this will be APS ACK, and you can see that the device is aware that it failed if you look at a sniffer log, as the device will retry the packet. However, much of this is handled internally by the stack, so there is no easy way to get a flag that it failed for attribute reports as far as I know. You can use NLME status indication to handle receiving an NLME status indicating an error. For this you can add the signal ZB_NLME_STATUS_INDICATION to the zigbee stack event handler (zboss_signal_handler). You will then have to check what the status is and handle accordingly. You can find the different types of network status codes in zb_nwk_command_status_t , which is defined in zboss_api_nwk.h.

    Another option is to check the neighbor table for the ZC. If the ZC is a neighbor of the ZR it will have an entry in the neighbor table of ZR. If the ZC becomes unreachable then this entry will become stale after some predefined time.

    Best regards,

    Marte

Children
No Data
Related