Hi! I have XBee3 as coordinator of my network. I have recently upgraded to 100A (but noticed the issue in 1009). The network consists of various xiaomi sensors, a xiaomi power relay (works as mains powered zigbee router), and other XBees, including XBee3 and S2C.
The issue is that some of my devices start leaving network after a while (several hours to several days).
It seems that the most affected devices are the endpoints that communicate directly to the coordinator. Routers are either not affected or affected much less. Endpoints that communicate via routers are also either affected less or not affected at all.
I’m sure some of the older firmwares work correctly. However when I’ve tried to downgrade the firmware to test I found it was impossible for some reason.
May be the issue is related to the fact that endpoints (sensors) are not sending any data very often. I have an illumination sensor that sends updates very often, and it works fine despite being an endpoint. At the same time a cube sensor, which only communicates when I interact with the device, is probably the first to disconnect. I will also try switch off one of the xbee3 routers for the experiment to check if it would lose the network or not.
You need to set the sleep times (SP, SN, SO) so that you are setting these timers to a greater sleep time than your longest end points sleep time. Not doing so can cause the end device to become disassociated.
Hi! Thank you for the suggestion! This period is already more than 4 hours, I will try to set it to maximum value, but it is probably already more than the weather sensors update their values. May I also ask you explain why it didn’t happen on older firmware and with endpoints that connect via routers?
This is only a guess as I don’t know what is causing the end devices to leave. It could be they are out of range or are missing poll requests. The best way to see why is to use a zigbee packet sniffer.
I’ve powered off one of the routers (another xbee3) for about a day (longer than the period defined with SP and SN) and it reconnected to the network without a problem
I’ve set SN to 0xFFFF, but my sensors keep loosing network.
I am still sure I did not experience that with some older firmwares, but I am unable to downgrade it using OTA for some reason (is it another bug?)
The Release Notes doesn’t warn the firmware cannot be downgraded OTA, so it looks like a bug.
But I was able do downgrade it with combination of ser2net and ttynvt, and tested with different firmware versions:
1006, 1007 and 1008 do not have this issue.
1009 and 100A have an issue
So it looks like a regression between 1009 and 1008.
I tested them with identical settings in a network with only the coordinator and two sensors.
Some updates on the issue. I’ve done some sniffing on the traffic, and I can see that XBee performs a network key rotation. The routers successfully applied the new key, but the end devices still use the old one.
How the end devices are supposed to receive the new key? Is it failure of their parents?
Why is the key changing? I am upgrading the firmware, bot the network key. Is it because it writes back RK=0? How do I stop the key rotation from happening?
Parents would send the new key to the end devices, but only if it gets online within about 9 seconds. If they don’t, they will have to rejoin. There is no need to enable joining on coordinator for the rejoin, but it’s a job of the end devices to detect this condition and initiate rejoin, and some of them fail to do so.
It looks like setting a static network key with NK command instead of a default 0 could be a workaround.
I have recently been testing with similar results for XBee3 zigbee running FW 1012:
Test setup:
Coordinator running FW 1009
Sleeping end devices (SED) running FW 1012 directly communicating with coordinator.
Routing devices running FW 1012 directly communicating with coordinator.
The SED’s looses it’s coordinator after just som hours. I can see that the PAN ID has changed to “0000000000000000”.
The routers keep the coordinator and does not seem to leave.
We have thousands of devices with the 1009 FW in the field where this is not an issue.
Have you done any new observations or know of stable versions from or above 100D? (lower versions is not supported with hardware revisions M and newer)