• State Answer Suggested
  • Locked Locked
  • Replies 15 replies
  • Answers 1 answer
  • Subscribers 61 subscribers
  • Views 3881 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.

Short address change unexpected.

Lyn Maric
Prodigy 60 points

Other Parts Discussed in Thread: CC2530, Z-STACK

Hi friends,

      I set up a 100-node zigbee network by CC2530 with ZStack-2.5.1a, and It works very stable. But after some time, I found a few nodes' short address changed. 

      I have already set NV_RESTORE in option, so short address should not be changed. This thing is bothering me.

      PS: All nodes are router, and they will restart everyday at same time. I just want to know why and how to avoid.

Best

  • 0
    Expert 1240 points

    I am having exactly the same issue. Anyone has ideas?

  • 0 in reply to Kyle Zhou
    Guru 735695 points

    Hi Kyle,

    Would you specify your Z-Stack version and test step to reproduce the problem?

  • 0 in reply to YiKai Chen
    TI__Genius 16570 points

    Hi,

    if the device was kicked out of the network (ie ZDApp.c module received the event ZDO_DEVICE_RESET), then what happens is that the device NV Network database is cleared and then the device is reset.

    Which then triggers, upon restart, that the device will try to attach to the network doing a MAC association again and if the parent has changed or the older parent has cleared the device from its association device list, then the new device will get a new network address.

    The conditions to kick out a device from the network, as specified in the ZigBee specification, are always revolving around an authentication failure, that is the reason why the NIB NWK information base is cleared and this was done in a pretty hard way.

    Recent stack versions who include scenarios where the device can be told to leave the network for other reasons than authentication failures (like a child being aged), would need a more soft mechanism to allow the child to join the network without doing a MAC association.

    This is probably what happens in your case. The parent tells a device to leave the network (because of some aging procedure) and he clears the NV.

    In order to validate this hypothesis, what you can try is to condition the clear of the startup option in ZDApp_event_loop() (when ZDO_DEVICE_RESET is received) to the devState variable, basically avoiding clearing the NV if devState is DEV_NWK_REJOIN, DEV_END_DEVICE, DEV_ROUTER or DEV_NWK_ORPHAN

    If this solves your problem, then this would prove the theory. In such case, then though this may be not the final fix I think we'd have a confirmation of this behavior and that is associated to a network leave command that has nothing to do with authentication failure, as described in the spec.

    Please let us know if this solves your problem and in case I will report this internally.

    Thanks,

    TheDarkSide

     

  • 0 in reply to TheDarkSide
    Expert 1240 points

    Thanks TheDarkSide for the detailed response.

    However, I doubt that it is related to ZDO_DEVICE_RESET.

    When the device changed short address, I found it still maintains its group membership and the related scene still works.

    If it is a 'reset' issue, the group/binding should all be cleared since startup options bit is set.

    BTW, could you please elaborate more on the 'child ageing' procedure? I do remember anything like that in the ZigBee specification.

  • 0 in reply to Kyle Zhou
    Expert 1240 points

    apart from ZDO_DEVICE_RESET, another point I am investigating is 

    ZDO_ProcessDeviceAnnce() in ZDObject.c, where NLME_CheckNewAddrSet() is called, which could cause a short address change.

    Unfortunately, this is a network layer function without source codes. So I cannot peek into it and debug.

  • 0 in reply to YiKai Chen
    Expert 1240 points

    version: z-stack 2.5.1a

    setup: 50 router nodes + coordinator.

    short address of some router nodes change unexpectedly from time to time ( 1 or 2 node per day on average ).

    it seems that the short address changes happen slightly more often when nodes are located farther away from each other, but be sure to have a route between any two nodes.

  • 0 in reply to Kyle Zhou
    Intellectual 290 points
    I agree with Kyle Zhou. This is not a ZDO_DEVICE_RESET thing : I have solid data from many thousands of routers that proves it: the NV Network database is never cleared when the address change occurs. So we can role out that hypothesis.

    Currently, my firm monitors thousands of routers in the field to get an understanding of why this happens. As I see it, this is a pretty important issue since the robustness of ZB takes a hard hit if you can't trust that addresses stay more or less static. Changes every day is not ok and it creates a lot of workarounds and fixes for us application specialists.

    Interestingly, we've never seen address changes for sleeping end devices - always for routers that are always RXON. A hypothesis we're currently investigating is therefore that address change is triggered by outside noise - we all know that the 2.4 GHz band is full of wifi and other stuff and it doesn't seem unrealistic that an outside frame is picked up that partly mimic an address collision annce and then starts a chain reaction. I'll report our findings in this forum as we learn more.
  • 0 in reply to Magnus Bolmsjo
    Expert 1460 points

    Are there any updates on this topic?

    Im also seeing unexpected short address changes and wondering why this happens and how to avoid this or what to do in this case.

    cheers!

  • 0 in reply to Thomas Hartwig
    Guru 735695 points
    Hi Thomas,
    I think this happens on old Z-Stack such as Z-Stack 2.5.1a. It supposes to be fixed in latest Z-Stack such as Z-Stack Home 1.2.2a. Which Z-Stack version do you use?
  • 0 in reply to YiKai Chen
    Expert 1460 points
    Im using Z-Stack home 1.2.2.a-44539 so it seems to me a fairly new version, isn't it?
  • 0 in reply to Thomas Hartwig
    Guru 735695 points
    Yes, Z-Stack Home 1.2.2a is the latest version. Do you mean you still see this short address change issue on Z-Stack Home 1.2.2a?
  • 0 in reply to YiKai Chen
    Expert 1460 points
    Yes I do. I've seen it in person only for a ED so far and not for routers. But I got some reports that some devices would not be controllable anymore which seems to fit the scenario. My application tries to reach them using the "old" address but they somehow got a new short address.
  • 0 in reply to Thomas Hartwig
    Intellectual 290 points
    As pointed out in earlier posts, this is a pretty annoying feature - or lack thereof - of ZigBee's stochastic addressing algorithm. If a new device enters the network and by chance picks the same address as a previous node, both will change their addresses. One would think that only the "intruder" should be forced to change its address, but no - both will change according to the ZigBee specs. Extremely clever! It leaves application specialists with unneccessary headache because often - at least for our product line - it's essential that at least one of the routers has a static address that never changes.

    The way to fix this is - which we found a couple of years back and has worked beautifully on all our installed networks - is to force the sensitive device in question to reclaim it's old address should a change occur. The way to do it is in ZDO_STATE_CHANGE by adding two lines of code:

    _NIB.nwkDevAddress=0x1234; // set my preprogrammed address
    ZMacSetReq(ZMacShortAddress,(byte*)&_NIB.nwkDevAddress); // this will do the trick

    That will force the device in question to always use the fixed address 0x1234;

    Now, this is a practical fix if you only need one or a few routers to have static addresses - else it will be to time-consuming to set up all devices with preprogrammed addresses.
  • 0 in reply to Thomas Hartwig
    Prodigy 205 points
    We are hitting the same issue (Z-Stack version 1.2.1) in the field and it's hard to reproduce it at work desk. Are there some updates to this problem?
  • 0 in reply to Magnus Bolmsjo
    Prodigy 60 points
    It's a good way to fix this problem. I have been looking for a method of using fixed address in ZB device. Thank you！