• State TI Thinks Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 1 answer
  • Subscribers 57 subscribers
  • Views 1727 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.

CC2530: End device Re-Pairing

Yves L'Ortye
Prodigy 20 points

Part Number: CC2530
Other Parts Discussed in Thread: CC2531, Z-STACK

Currently i'm working on a product which contains a CC2530 module running ZNP firmware. This device is configured as coordinator and a couple of routers and end-devices are connected to it. The network is fairly stable and runs ok most of the time.

My issue starts when the master device (containing the CC2530 Coordinator) reboots for some reason (update, power loss, could be anything). Sometimes when the coordinator reboots the end-devices have hopped to routers and have a new short address. This results in the coordinator being unable to find the devices and the only solution that we currently have is re-pair the end devices.

When sniffing the network with a CC2531 module I found the following behaviour:

  • CC2530 Turns off;
  • End devices send a lot of unanswered data requests;
  • End devices send a Rejoin request, ack is given by router;
  • CC2530 Turns back on;
  • End devices are unreachable by CC2530 Coordinator.

Now my question is, can the coordinator be configured that no end devices are lost? Or could a complete network ping help with this solution? I'm unsure on how to approach this, but I am sure that pairing the devices is not the best approach.

When searching online for this problem, I couldn't quite find someone in the same situation so I'm curious if this forum can help me.

  • 0
    TI__Guru**** 222447 points

    Hi Yves,

    It appears that you are working from a deprecated Zigbee Specification, as Z-Stack Home 1.2.2a and Z-Stack 3.0 have improved child management features.  It is also not standard for child devices to change short addresses when locating a new parent within the same Zigbee Network.  Assuming that the firmware of routers and end devices cannot be upgraded for improved Zigbee Specification behavior, the ZNP acting as a coordinator will need to perform network discovery (possible through Management LQI and Network Address Requests) to discover prior children (specifically looking for IEEE extended addresses, which are constant per device).

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 20 points

    Hello Ryan,

    Thanks for the quick reply. I went and checked what version is currently flashed on the CC2530 module, and it should be Z-Stack 3.0.x taken from the zigbee2mqtt project (https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/Z-Stack_3.0.x/bin).

    Like you mentioned, I tried sending a Network Address Request (zdoNwkAddrReq) but this fails when the short address of the device has changed. Also, I'm seeing no output on the sniffer when this request is sent which leads me to believe that zdoNwkAddrReq only requests the address from the address table in the coordinator, not from the network. Could this be the case?

    Greetings,

    Yves

  • 0 in reply to Yves L'Ortye
    Guru 735695 points

    Actually, zdoNwkAddrReq will send Network Address Request over the air. How do you send Network Address Request?

  • 0 in reply to YiKai Chen
    Prodigy 20 points

    Oh, that's odd. My sniffer didn't quite catch it. However, I sent the request over the serial interface to the CC2530. The request consists of the device IEEE address field (set to the IEEE address of the end point), Request type field (set to 0) and start index field (set to 0).

  • 0 in reply to Yves L'Ortye
    Guru 735695 points

    Maybe the byte order of IEEE address in your ZDO_NWK_ADDR_REQ is reversed.

  • 0 in reply to YiKai Chen
    Prodigy 20 points

    Well, I thought the same. However, the reply comes back OK when the device still has the same address, so I'm guessing it is not reversed. I'm currently doing another session with the sniffer attached, and all "Network Address Request" packets can be seen when the device has the same address. One reboot and a change of address later, and the packets can no longer be seen. I'm wondering if my routers are messing up the network.

  • 0 in reply to Yves L'Ortye
    Guru 735695 points

    Usually, network address shouldn't change. If it changes, I suppose it would send device announcement packet which would include device network and IEEE address. Do you see device announcement packet when your device changes network address?

  • 0 in reply to YiKai Chen
    Prodigy 20 points

    Yes, I can see the packet. The problem is that the coordinator is offline at that point and misses the packet. When reading online I saw some that the only option was to manually re-pair the end device, but I thought that this was not the way that the Zigbee standard intended.

  • 0 in reply to Yves L'Ortye
    Guru 735695 points

    When you send "Network Address Request"  and don't see it is send, do you see route request is sent in the sniffer log?

  • 0 in reply to YiKai Chen
    Prodigy 20 points

    Sometimes I can see route requests when a Network Address Request should be given indeed.

    On another note, I now have a network in the same situation as described, but when sending the "zdoNwkAddrReq" to the router, I can see the end-devices in the "associated devices" under the router. That seems nice, but when trying to reach this associated address directly the device is still unreachable. Thats odd.

  • 0 in reply to Yves L'Ortye
    Guru 735695 points

    If routing path to the device is missed, you might need to wait a while for routing path back.