Lock failed to complete the network security exchange

I’m trying to get my August Pro lock connected to Smartthings and am getting the following error when I try to pair: “The lock failed to complete the network security exchange…”

I’ve tried excluded, and re-pairing, moving the lock right beside the hub, resetting the lock, restarting the hub but end up with the same error every time.

Does anyone have any ideas? I’ve found some similar threads but haven’t been able to find a solution

Thanks

If you go into the IDE and click on the device, what do you see in the field marked Raw Description?

If the device included in secure mode it the string should start with “zw:Ls”.

It would be with excluding, do a Z-wave repair and then include again. This time with it sitting on top of the hub. Also, does the device have a different pairing sequence for secure and not? I know some devices need a different kind of button push to get them to include in secure mode.

Hi Simon, thanks for the help, here’s the raw description:

zw:L type:4003 cc:5E,55,98,9F

I’ve tried excluding, repairing and including even with it on top of the hub. The August Pro had paired successfully before, although over the last couple weeks it had gotten a little flaky so I had excluded it, factory reset it and included it again. I don’t believe there’s any tricks on the August Pro side for getting it to pair in secure mode, in fact when it pops up, it says Smartthings only supports S0 security, rather than S2 like the lock does.

No you can’t control nor can any DTH control the pairing process. That’s between the hub and the lock. It should automatically fall back to S0 if S2 fails and continue working. However if I remember the specs correctly it will not function if it fails to negotiate S0. If it doesn’t pair it means the exchange failed and you need to try again.
Often distance is a crucial factor, sometimes pairing within 3ft of the hub helps.

If this problem started recently it could be related to a hub firmware update (since pairing is exclusively controlled by the hub). You may want to report it to ST support and have him investigate the hub logs to see why it’s no longer pairing with S0

A S2/S0 warning is normal with the August Pro since SmartThings doesn’t support S2, but this error may be different. Could you control it from the SmartThings app at all?

Yeah, I’m guessing it’s hub firmware related as I was able to pair it previously. Where as now it won’t pair whether it’s 20ft away, on top of the hub or anywhere in between.

Jimmy, I’m not able to control it at all, it shows up and in the locked state, but it can’t be unlocked through z wave and when I manually unlock it, smartthings still shows it as locked.

Bummer. It could also be lock firmware related. I know mine has received a couple since i’ve had it. One of them killed z-wave communications, but a reset via the August app and a replace in SmartThings fixed that.

1 Like

So I tried picking up a new August Pro lock today just to test, and am running in to the exact same error, so assuming I can rule out the lock hardware it looks like it’s something that is Smartthings hub related.

If anyone else has any ideas, I’m all ears

Can you post a screen shot of the error?

Sure thing:

ohhh, its on the SmartThings side. Interesting. Don’t think i’ve ever seen that. Are you using any custom device handlers for locks?

Yeah currently I’m using the Rboy handler, I suppose I can try removing the device handler and trying again, but I was receiving the same error without it, and tried using it in an attempt to resolve the issue:

hmmm, removing any community handler was going to be my suggestion. And it sounds like you’ve tried pairing it within 3 ft or so of teh hub. Not really sure what to suggest other than exclude, try again and repeat until it works :confused:

Try this, power off the hub for about a minute and then power it back on. Exclude first and then try to pair within 3ft of the hub. This error is a basic z-wave pairing issue (even before the DTH comes into the picture, it isn’t able to negotiate on the communication protocol) and may be an issue with the hub firmware. We had seen this issue with another vendors product when working with some plugs, sometimes power cycling the hub gives it a fresh start.

If it still does not work, ping me and I can request the ST engineer who had worked with us back then to resolve the issue to try and take a look at what’s going on.

Thanks RBoy, I’ll give that a shot this evening and let you know how it goes.

Cheers!

1 Like

Alright so I moved into a new house, brand new Schlage lock. The same exact model that I had at my old house, it was working great there for years with @RBoy’s premium device handler. At my new house, I’m getting the dreaded “The lock failed to complete the network security key exchange. If you are unable to control it via SmartThings, you must remove it from your network and add it again”

I have read this entire thread. I have done exclusion and inclusion cycle over 5 times. The Schlage lock displays a red “X” on it after pairing attempts, and then I get the same exact screenshot that @SJN posted above.

I’ve updated to latest device handler and that didn’t make a difference. I have also moved my ST hub to literally right next to the lock, I had them touching during all of the exclusion and inclusion attempts. My hub firmware is at 000.024.00011. My hub hardware version is “hub v2, US customer Rev E”

Any ideas? Really want to get this workin! :slight_smile:

Try these steps:

  1. Reset your lock (refer to your Schlage manual) - imp step (Kwikset locks have an anti theft feature which requires explicit disabling but Schlage locks can be reset to disable it I believe)
  2. Reboot your reboot your hub
  3. Pair the lock (exclude if required before pairing)

I want to go on the record to say that @RBoy’s solution here worked for me.

I was having this same issue – ST errors about it not being able to complete the key exchange, despite the hub being within a foot of my Schlage lock.

I saw this issue with a v1 hub, upgraded to a v3 hub (for various reasons), and continued to see the issue there using the standard ST device handler…

Not knowing what else to try, I did a factory reset on my lock, and when that was done, it connected extremely quickly.

I then switched over to rboy’s handler and SmartApp, and it’s all working smoothly again!

Note that I believe this all started after replacing the batteries of the lock.
-Eric

1 Like

I just had the same issue happen with me on a new Schlage lock. In case anyone else has this issue, I had to delete the RBoy device handler from Smartthings, reset the lock, then add it. Once it was added, I could put the lock (along with my other two existing Schlage locks) back on RBoy’s device handler.

I’m not sure if there’s anything RBoy can do to avoid this, but it seems like Smartthings doesn’t like his device handler when pairing. Just resetting the lock but not deleting the custom device handler didn’t work.

It sounds like a platform/ hub latency issue, possibly the specific platform instance is running too slow causing a timeout. A DTH isn’t involved in the pairing process, that’s done directly between the hub and the device based on its advertised capabilities. However once the pairing is complete the last step is that the hub sends a request to the platform to find a compatible DTH’s based on the device description/identification and run its installed/configure routines. If the platform is running slow or the internet or hub latency is high it could timeout which probably explains why the hub throws an error (a hub firmware bug IMHO as it should have a fallback mechanism if the platform is running slow). One more reason why we’re asking ST move custom Z-Wave and ZigBee DTH’s to local processing. They already have the framework in place, just need to enable it.

If the platform server is running slow or the internet has high latency not much you can do about it but rebooting the hub and internet modem/router does help reduce some latency. If this problem started recently as pointed out by Eric then you can look back to see if any of the internet connectivity components or z-wave mesh devices have been added or changed which may be introducing the additional latency.

1 Like