Here’s an interesting thing I discovered this morning.
Yesterday I was adding an ikea 5-button remote to my Dirigera hub.
It was added to my Dirigera hub, but it also ended up being partly added to my SmartThings hub.
It’s not active since the button presses don’t register, and the firmware shown on the information page in the app shows the firmware version when it was added, not it’s current firmware.
That’s Very Not Good. 
That particular device can’t belong to both hubs’ zigbee networks at once.
And the ST hub should have ignored it, no different than if it was your next door neighbor’s Dirigera.
You’re losing network integrity, apparently, which is a fundamental characteristic needed for networks to coexist independently when in range of each other.
Let’s hope it’s just a leftover IDE artifact.
Did you try checking by CLI or @TAustin ’s viewer utility to see if there’s actually a device entry on the hub?
It’s showing up in the app and IDE.
I’ll check the CLI when I’m back at my computer.
This particular device may have been connected to ST in the past, but it was removed.
I move test devices around between my various platforms, and I’ve never had one automagically rejoin before.
Both of those could be platform artifacts, nothing to do with what the Zigbee coordinator inside the hub is tracking.
I’m concerned if your hub accepted information from what should just be random noise in the neighborhood.
There are three possibilities as you describe the situation:
A) the hub heard the Zigbee join message, correctly went “Oops, not for me”, but incorrectly failed to tell the cloud to ignore it. That would be bad but fixable.
B) because this is a device that once was joined to that same ST hub and perhaps had never been deleted, and because zigbee devices have unique ids, the hub may have interpreted it as a rejoin request and then the new architecture logic kicked in trying to match it to an edge driver. That would actually be human error for not having deleted it from the old hub before trying to add it to a new hub with overlapping range. That’s an “Oh, yeah, we’ve all done that” situation—you just delete it from the old hub and start over. Or it could be a platform error, where a requested delete failed to complete, that can happen too. But the point is that if that device ID still had an entry in the Zigbee table, weird things could happen.
Also note that since devices that are in the Zigbee table can initiate a rejoin from their side without you having to put the hub into pairing mode, it would fit what you saw with the added twist of the new platform logic to match it to an edge driver.
C) it had been successfully deleted before and the ST hub actually tried to add a device based on a random join request to another hub in an overlapping range. That would be (from a network maintenance perspective) horrific, so let’s hope it’s not that.
——
So I’m hoping for B.
See if it still has an entry in the hub’s device table (not the cloud, IDE, or app, the actual zigbee data). If so, delete it.
Then if you want, try adding to the Dirigera again and see what happens this time.
I would guess B as well. My guess is that even if the device was removed from the IDE in the past, perhaps it didn’t actually get removed from the radio. 
Good point, a failed delete could have the same effect. I have expanded my point B above to cover that possibility
But the main thing is that if it was perceived as an attempted re-join by the smartthings hub, then that can be initiated from the end device, you don’t have to put the hub into pairing mode for it.
Using the CLI, the device did show up in the middle of the list of devices (Device 30), so it was installed at some point in the past.
30 IKEA Remote Control five-buttons-battery ZIGBEE ed414555-b995-407d-9e3d-abcd123
31 IKEA Remote Control NF five-buttons-battery ZIGBEE 3669bee0-ea15-47a8-ab57-abcd123
I have to assume I had deleted it from my SmartThings hub because I took it out of it’s box and had to put a battery in it before attempting to pair it to my Dirigera hub. I don’t leave inactive devices paired to my hubs.
Zigbee secure mode is enabled on the hub.
I used the Smarthings app to remove the device.
According to the CLI, what was Device 31 is now Device 30.
I also deleted the affected device from the Dirigera hub and paired it with the Dirigera hub.
This time it did not rejoin the SmartThings hub.
I noticed in the activity log, that there as a button press event at the same time as it was “added” to SmartThings yesterday, I wonder if ST saw that as a rejoin request.
That device would have been removed from SmartThings around the time when they updated the Zigbee firmware and a lot of Ikea devices were having issues.
It’s possible it was a failed delete and then when I fat fingered the button while pairing it with the Dirigera hub, ST saw it as a rejoin request.
A failed delete would make sense.
