Nodes Changing Network Address Daily

Seems as your devices does random reset. Pretty sure that's what causes your problem. Check the hardware for the root cause of why devices does a reset. Does the hardware include power amplifier? If yes, check for current spikes / voltage drop when the device sends. Alternatively, check the battery specs - can the battery generate sufficient power fast enough when the device sends? Internal resisitance of the battery? Current limit protection cicuits you might use?

Do you use the compiler directives  NV_RESTORE and NV_INIT?  Those directives should cure most of the address change problem due to reset, although I have seen rare cases when address changes still occur after reset despite these directives are in place. It shouldn't be possible one might think, but the reality is that address changes may still happen in the 2.5.1 stack - not very often but you need to consider that it may happen and that your applicaiton can cope with it.

Sudden address changes can be pretty nasty to cope with depending on the application. A well functioning broadcast mechanism is sometimes very needed for those situations. The 2.5.1 zstack weakest point one needs to be aware of is that the stack doesn't handle end device broadcasts well - in fact it doesn't handle it at all. So with zstack you can't broadcast other end device nodes that I no longer have the short address other nodes  might think I have. That's in my mind a real poison pill and a pill that few from TI's design team speaks about.  

Can anyone from TI comment on this?/ Thanks.

Hi Michael,

I agree with the option from Magnus. It seems that your device reboot regularly and you need to check this first. Also, Do you use the compiler directives  NV_RESTORE and NV_INIT? If not, the short address might change after reboot.

Yes, NV_RESTORE and NV_INIT are enabled.  As Magnus had mentioned and apart from possible hardware issues, what are the conditions, if any, where the Zstack will reset clearing defaults?

There are two kinds of cases that ZStack will reset.

1. When a device receives a network leave request. You can search "ZDApp_LeaveReset" in your project to check it.

2. When you use SECURITY network and the device is unauthenticated. You can search "ZDApp_ProcessNetworkJoin" in your project to check this.

By the way, the device might be reset because your application doesn't function properly such as memory leak.

There is one more thing you could consider. I quote from Google:

Zigbee 2007 PRO uses "Stochastic Addressing" which is a fancy way of saying that each node gets a randomly generated Short Address when it joins another node. This could be a problem though - what if two nodes receive the same Short Address when joining? To prevent this problem, when a node joins it broadcasts a Device Announcement message containing the node's long address and short address. If another device has the same short address then a router on the network will broadcast an "Address Conflict" message, and all devices that have the conflicting short address stored will change their short address. When the conflicted devices change their short address they will broadcast a new Device Announcement message.

End device address conflicts are handled by their parent; with the parent sending the end device a "Rejoin Response" message. When the ED receives this message it changes its short address and the end device broadcasts a "Device Announce" message.

When any node on the network receives a "Device Announce" message the node updates their association and binding tables with the new short address."

Think about the underlined part: if an address conflict occur - both the one that causes the conflict and the "innocent" node will change their addresses, respectively. So in you case with hundreds of nodes, suppose one  of them is faulty and resets itself prestine all the time (with prestine I mean the stack resets itself from scratch (there are ways to do that)) the chance you'll get address conflict starts to build up and when it happens - you'll get the symptom you describe.

What to do about it? It depends on the application. In most cases I've encountered, it doesn't matter if an end device changes it's address because usually end devices are servers that pushes data to routers, not the reverse. If it is critical that your application stay static - I wouldn't trust the stack but instead preset the addresses directly in firmware or with a commissioning tool.  

Good luck with the hunt. Will be interesting to see what you come up with. Might be that you've observed the weak spot of stochastic addressing.

Best reg Magnus B

if for some reason another node in your network does a prestine reset (i.e. starts from scratch, .e.g if the device is new to the network) there is a slight chance that it's short address (which is randomly generated) will collide with an already existing short address.

You can have a list to keep both short and IEEE address when there is an end node announcement. After you receive a n end node announcement, you can check if the IEEE address is already in the list. If yes, update the short address. If not, add a new item into the list.

Hi YiKai,

That's risky business in my opinion. I wouldn't do that. With hundreds of nodes and distance to carry - the risk is too high that the node keeping such a table doesn't always get the announcements due to e.g.interference, noise, power failure etc - there are lots of reasons why a message can be missed. If your application needs the short address to be static for some reason - its safer to just hard-set the short address once and for all for the critical nodes.

best reg Magnus B

Thanks Yikai and Magnus.

To sum up the conversation the possibilities include:

1. NV_RESTORE / NV_INIT not enabled.

2. Hardware sensitivity.

3. Memory leaks.

4. When a device receives a network leave request.

5. When you use SECURITY network and the device is unauthenticated.

6. Address conflicts.

Of these six, #2 and #6 could be possibilities. I'll look into these and get back. Thanks again.

Hi Michael,

Please keep us posted. I sense you have touched a property of ZigBee which is important for us all to understand in depth, especially how to mitigate possible negative impact of sudden address changes. There are many lessons-to-be-learned here.

Good luck Magnus B

Hi Michael, have you solve the problem?

If you get the answer, please post it, thank a lot.

Now i am puzzled about the "shortAddr changed", please help me thks...

Z-Stack 2.5.1 is obsolete and I would suggest you move to Z-Stack home 1.2.

Z-stack 2.5.1 is still offered by TI as their high-end ZigBee stack. I'm of the impression that "home 1.2" is just a sub-version specifically tuned for the home automation profile. 

Anyone that can bring clarity?

Hi Magnus,

No, ZStack home 1.2  is not a subversion. It supports the latest Zigbee pro spec so I suggest you using it.

Hi YiKai，

I am using Z-stack 2.6.1 （from Home 1.2.0 >> SampleSwitch）

When I enable NV_INIT & NV_RESTORE，the RT device might change it's shortAddr occasionally.

I have about 70 RTs in my network( no End Device) .

There might be 3~4 RTs changing it's shortAddr daily. 

Please give me some suggests ,Thanks a lot.

Hi Jerry,

I suggest you use packet sniffer to log the RF data and contact your local TI FAE for support.