I have been having some issues with my Zigbee devices not connecting correctly to my V3 Hub and Samsung Support has just commented (not really recommended) about some Hub settings I may want to take a little at. Secure Mode - do most people have this enabled or turned off? My understanding is that when enabled my Zigbee devices that disconnect will not try to auto-connect back to the hub. Although this is supposed to be a security advantage , I don’t really know why. Seems to me with Security mode turned off I would want my Zigbee devices to try and reconnect on their own, wouldn’t I? Also, I noticed that my Firmware Updates is turned to Don’t Allow. Again why would I not want devices to perform firmware updates? What do most of you have this set at?
I have secure mode set to off and firmware updates set to allow.
As for your devices that are not connecting, can you provide more details… types of devices, brands/models,stock or custom code?
Zigbee devices disconnect and reconnect to the network all the time on their own. It’s a mesh thing.(for example when you change the batteries in a sensor, you don’t have to re-add it to the network.) The problem is that when you allow insecure rejoin, you open a pretty significant security vulnerabilities allowing for foreign devices to be added to your network. That’s not really a big deal for most residential home automation, but it’s a huge deal for security systems. So a couple of years back pretty much every home automation system took the step to require security join after there was a lot of publicity about the zigbee Security vulnerability. You can find some old threads from 2015 in the forum discussing it. Or the following which covers pretty much everything for the current environment. (The topic title is a clickable link)
But there are still some devices which don’t handle secure rejoin well ( Sengled is one) so you need to be able to disable secure re-join or those devices will keep “falling off the network.“ (They aren’t actually falling off the network, they’re doing the normal fade and re-join, but they’re unable to rejoin.)
Thanks. That sounds reasonable to me. The issue Samsung Support is trying to figure out is why I cannot connect properly with a new Kwikset 914 lock with the new Zigbee 3.0 protocol. I spent several hours on the phone with KS and Samsung. I have other KS 914 locks with older versions of Zigbee and they work fine. However for some reason, the newer version 3.0 will connect but only shows as a THING in ST and no ability to control the status of the lock. It is not a distance issue as I moved the device within 8 ft. of the hub. KS keeps sending me new locks with new Zigbee 3.0 but the same issue which makes me think this is a ST issue. It is not the lock as I swapped out to a Z-wave chipset I had and everything shows and functions correctly in ST.
Among other things, Samsung Support they indicated the following regarding Zigbee 3.0, “Zigbee 3.0 is a new update of the Zigbee protocol that is more secure than its predecessors. When the device is connecting to SmartThings, a secure key is passed between the device and the Hub by scanning a QR code on the device through the SmartThings mobile app”. However there is no stated process to do this when connecting the lock to ST. There is a QR code on the interior assembly of the lock and the chipset (if you remove it) but neither are supported QR codes for connecting to ST (I have tried). So at this time everyone is a little more than stumped. 
I agree that a new zigbee 3.0 lock should have a QR code either on the lock itself or sometimes as a sticker on the user manual. You need that to get it to join at the highest trust level, which is what the lock will be expecting.
It gets complicated when you have a lock like yours which can take different modules, because then it’s not likely that the code will be on the physical lock. It’s more likely to be on a piece of paper that came with the lock, like I said, most typically the user manual. sometimes they give you a sticker which you can then stick on the lock.
But because you need to be able to read the QR code while the device is powered, they can’t put it on the interchangeable module itself. ( if they do, you usually have to photograph it and then scan the photograph.)
@rboy or @johnconstantelo might know more.
There is no QR code in the instruction directions or on the box. However as I indicated there are QR codes on both the interior assembly (logical place) and on the chip set itself (not logical to have pull out the chipset from the assembly to get to it). I did try both on separate attempts by attempting to connect the lock by selecting Scan QR Code when adding a new advice but it comes back with a message that this is an Unsupported QR code and isn’t valid for adding to ST. I think this isn’t really the scanning of the QR code that Samsung Support is referencing but there is not any other place in the connection process that requires scanning a QR Code. I spoke to KS Support yesterday and they did not indicate any process to scan a QR code, only the process indicated in the installation directions which is the same for all of their locks for the exception of how many times you press the button for Zigbee or Z-wave. I will be responding back to Samsung Support on where they think this scan process takes place.
The lock has to be on power when you scan the QR code, so you can’t pull the chipset out and scan that. But you can take a picture of it and then scan the picture after the lock is back on power. If that’s the right code
@rboy is an expert on locks and may know more.
Thanks for tagging me @JDRoberts
I’m betting that the “fingerprint” has changed, which is why the device joins as a Thing. This is easy to resolve, which I’m surprised ST support could not figure out, but then again, ST support isn’t what it used to be. It’s terrible actually…
Do this:
- Refer to one of your existing locks and note the device handler it is using via the IDE (it’s the Type field). It’s likely using “Zigbee Lock”.
- Add your lock back to ST using the zigbee module and wait for it to join as a Thing. Remove and factory reset your lock before rejoining it, just in case.
- After it joins, go to the IDE and edit the device to change the Type field to the same one your other KS 914’s are using.
The mobile app will eventually catch up with the change, so be patient, or you can force close the ST app, clear the app’s cache, and then restart the ST app.
This is actually a common issue I’m seeing with ST in that their built in device handlers are not being updated fast enough to keep up with new devices or changes with existing devices. It’s hard for ST to try and keep up with changes, so you can’t put all of this on their shoulders. The same thing happened with the new GE Zigbee 3.0 devices that came out a while ago. It took ST a long time to update their end so that these would join properly.
Voila 
John, your process worked! I followed your every step and had no problem changing the DH Type to my other functioning zigbee lock. Natively the lock connected as a device type “Samsung 2015 TV”. Where it got the device type is beyond me. 
It is also a disappointment that Samsung Support does not know this especially when they were remotely looking into my hub settings and didn’t see this. I will be letting them know of the issue of the wrong type DH loading with the zigbee 3.0 lock. Maybe this will spur a correction for all zigbee 3.0 devices. 
Again thanks for this great solution as I am not familiar enough with the IDE settings to have resolved this. All you experts in this Community are super and extremely knowledgeable.
Cool, glad that worked out!
I think I also have issues with the zigbee setting for secure mode and some devices with SmartThings hubs.
For months, my Smart Thermostat (Zen) has been hit and miss when SmartThings sets the thermostat controls via Automations/Scenes. And when I open the thermostat’s device page to manual tap the settings to make changes, it sometimes takes two to three tries before the change is made.
Last week, I disabled the SmartThings Hub feature for zigbee secure rejoin. And over the the last week the Automation/Scenes controlling the Smart Thermostat have been solid.
I’m wandering if there’s some devices that just don’t work reliably when using zigbee secure mode on SmartThings hubs. Because every few months or so I also have some Cree smartbulbs that loose their way too even though the other manufacturers smartbulbs I have work fine.
I’ve always had problems with enabling secure rejoin, so it’s disabled for me. I’ve never had a problem since.
As for Cree smartbulbs, I got rid of all those as well. They act as routers in your zigbee mess and are super flaky and cause problems. I replaced them with Sengled smartbulbs, and I’ve never had a problem since. My recommendation would be to replace yours as well.