Why does the short address of the device change

[yuboli]

Hello, everyone, in the process of allowing the network, we found that the short address of the devices that have already entered the network has changed. Sometimes my coordinator doesn't know that the device's short address has changed. Why does the address of the device already in the network change?

Here are the screenshots and packet capture logs of short address changes

Before change 0x70ea

After change 0x0d1d

The attachment is grab bag

[Sebastian_Del_Rio]

Hi Daniel, I hope you're doing well!

The issue seems related to a possible address conflict happening when your device sends a Link Status, causing the device to handle the conflict and changing the Short Address in the process.

 

Maybe some section of code could be assigning the same address to multiple devices.

ZigBee 3.0 automatically handles these conflicts by changing the address of the device.

For more reference, please take a look at the ZigBee 3.0 Stack user guide, here.

Best regards,

Sebastian

[yuboli]

Thank you. I see the short address conflict. I see that it will send device announcements once, but sometimes my coordinator can't handle it and can't receive it. How to maintain the application layer when the short address changes? How is ZigBee 3.0 handled?

[Sebastian_Del_Rio]

Hi Daniel,

For reference on the way the implemented ZigBee 3.0 stack works in JN516x devices, could you please take a look at the ZigBee 3.0 Stack User's Guide?

It can be found in the following page of our website, here, as JN-UG-3113.

Section 2.2.4 talks about the process followed by a node in the case of an address conflict.

Could you please let me know what do you mean by maintaining the application layer when a short address changes?

Please let me know if you need any more information.

Best regards,

Sebastian

[yuboli]

Thank you very much

I want to say that the application layer controls the routing device through the short address. If the short address changes, it cannot control the device; because the application layer does not know that the short address has changed.Application layer still uses the original short address. I don't know how to get the new short address of the device

[Sebastian_Del_Rio]

Hi Daniel,

The new short addresses assigned after an address conflict should be saved by both the trust center and router/end device after the conflict is resolved, so no issue should be happening.

Could you please let me know if you made any changes to the short address generation process?

Also, could you please let me know which Application notes did you base your devices on?

Best regards,

Sebastian

[yuboli]

Thanks, "The new short addresses assigned after an address conflict should be saved by both the trust center and router/end device after the conflict is resolved, so no issue should be happening", Yes, both the trust center and the router / terminal device retain the new address. But I don't know when it changed.

The application note I used was jn-an-1218, and the SDK used 4170, build number 1745. There are 10 routing devices in the network. I reset some of them to factory settings and re-enter the network. Packet capturing found that sometimes it would cause the short address of other routing devices to change, which I found several times. This situation is a little frequent. Is it possible that the SDK version is low?

[Sebastian_Del_Rio]

Hi Daniel,

If there's an Address Conflict error, you should be getting a Network Status packet containing the corresponding error code, 0x0D. If this error code is detected, you could use this value to detect the address change, and perform the necessary execution modifications.

There's currently a newer SDK version available for download (currently, the latest version is 1840).

It can be found on this page of our website, here.

Could you please try updating to the latest SDK version to see if the problem persists?

Please let me know if you need any more information.

Best regards,

Sebastian