I have a ZigBee End Device connected to the SmartThings hub through a Router (Smart Plug). When I disconnect power from the Router, the End Device attempts to rejoin directly to the SmartThings hub, but the hub tells the End Device to Leave. So the End Device is unable to rejoin the network. Why is this so?
Are you sure you have child slots available on the hub?
Yes. I tested this with only 2 devices - 1 router + 1 end device.
Brand and model of the end device?
I have my Z-Stack 3.0 based end device. I am wanting to know what might cause such a problem. I see that my device keeps sending rejoin requests while the hub keeps sending Leave requests.
There are several things that can cause that, but the most obvious would be if you had insecure rejoin disabled.
If I kept insecure rejoin enabled, would I just have to enable security on my device’s rejoin requests?
And also the reason I face this problem is that ZigBee 3.0 removes this security because “ZigBee 3.0 specification removes this potential vulnerability” right?
When I try to enable insecure rejoin, the app just automatically disables it. I am able to do it on IDE however. Why doesn’t it work on the app?
That’s right. When devices need to rejoin I’d recommend the following
- Secure rejoin on same channel for some period of time
- Secure rejoin on all channels
- Alternating secure rejoin and unsecure rejoin on all channels
In most cases the first option should succeed if there are any devices capable of being a parent on the network within range.
Zigbee 3 adds the ability securely join a device to the network using the device’s unique link key. However once the device is on the network and needs to rejoin it can choose whether to use secure joins or unsecure joins. We expect SmartThings certified devices to do secure rejoins and will likely default all hubs to only allow secure rejoins at some point in the future.
I just was just able to toggle the setting back and forth a few times from the app. I suggest you contact SmartThings support to let them know you’re running into problems and hopefully they can help solve it or report the problem to the correct team.
I enabled insecure join and tested again, but I still get the same problem - the device keeps sending rejoin requests while the hub keeps sending Leave requests.
I should also mention that the period of rejoin & leave requests only happens for about 5 seconds before the end devices gives up and just stops.
These are my test scenarios + sub scenarios:
I tested the same scenarios with an Echo Plus (includes ZigBee hub inside), and I don’t see the same issue as in the SmartThings hub. Why is this so? Could it be due to a bug in the recent SmartThings firmware update? I remember that a long time ago that this wasn’t an issue for me before.
Does the ZED use a
Rejoin Request when it tries to connect to the Coordinator after the Router is turned off? The coordinator would send a Leave request to a ZED if that device just sends a
Data Request and it isn’t in its child table. In that case the rejoin flag in the Leave request would be set to true.
Yes. The ZED sends a Rejoin Request. This is what I see with a ZigBee sniffer :
This is what I see from a SmartThings multipurpose sensor :
Can you show the message contents of the
Rejoin Request from your ZED and the
Leave from the hub?
Below is a screenshot of my ZED’s rejoin request. I’ve asked the TI community, and they’ve said there isn’t any difference between the rejoin request of my ZED and the SmartThings multipurpose sensor.
ST multipurpose sensor rejoin request :
And here is the Leave request from the hub in response to my ZED :
So the ZED may be in the router’s association list but not the hub’s association list. And the hub can send leave with rejoin=TRUE to ZED and ZED should be able to rejoin to hub without problem. The only strange thing is that the hub keeps sending leave with rejoin=TRUE to ZED so ZED keeps leaving and rejoining.
I found out that in the below scenario does my problem go away. It seems that the hub doesn’t know that the ZED has left the network if I turn it off first and then remove the ZED which is why my problem exists. Can you explain why this is so?
ZC = ZigBee Coordinator (hub)
ZR = ZigBee Router
ZED = ZigBee End Device
On the Setup Scenarios above, I actually “Re-Uploaded the program to ZED” instead of “Factory reset ZED”. When I actually did “Factory reset ZED” instead of ”Re-Upload the program to ZED", the ZED worked in both scenarios. The problem didn’t show up anymore. Same thing with the ST sensor.
I am guessing that perhaps when I upload the program, there is some kind of default ID that the hub recognizes on the default ZED program, and when the removal process is incomplete, when the ZED attempts to rejoin with the re-uploaded program (meaning same default ID), then the hub tries to tell the ZED Leave. However, when I factory reset the ZED - not re-upload the program - the default ID is changed, so even though the removal process was incomplete, the hub doesn’t recognize the new ZED, and therefore it won’t tell the ZED to Leave. I am not sure though.
Can you verify if something like this is causing my problem?
Does reprogramming the device change it’s EUI? Typically that won’t change but if it was for some reason I could see it confusing the hub into thinking there is a node ID conflict (two devices with different EUI’s and the same node ID) which could trigger the leave request.
What do you mean by EUI?
Extended (64 bit) Unique Identifier
Reprogramming the device won’t change its EUI.