C7 - authentication issue with z-wave S0 security on locks

I should have kept my mouth shut. :frowning: I just noticed something I've never seen on my z-wave locks. I have 3 Kwikset locks: One 98880-004 and two 99140-101's. All z-wave plus. Both C7 & C5 are on the latest code releases.

They've all been excluded, reset and re-joined to my C7 since the migration and I've had no issues with any of them until the last week or two. All three locks still work correctly but now there's nothing in the Details: section except for one line: zwNodeInfo.

Previously they all looked (at the least) like this:

deviceType: 3
zwaveSecurePairingComplete: true
deviceId: 1094
inClusters: 0x5E,0x72,0x5A,0x98,0x73,0x7A
manufacturer: 144

So, I unpaired one, reset, excluded and re-joined at the door. No S0 security. Repeated this half a dozen times. Same every time. No errors, no issues in the logs, no problem in any of the processes, nothing.

Took the lock to my C7, repeated the process, placing the lock right next to the hub (less than 2") as was the process years ago per Kwikset. A process I might add never failed previously to work. Same results. Repeated the process half a dozen times. No errors, no messages, no problems, nothing. The lock comes up in the hub perfectly - but without S0 security.

@bcopeland : you should know that these Kwikset locks are joining on the C7 with a Schlage z-wave lock driver instead of 'Generic Z-Wave Lock' which is the way the C5 used to (and still does) come up. Last month I did test the Schlage driver in case I had missed something, but it doesn't work correctly (the generic z-wave lock driver does) with the Kwikset so expect this is a signature bug? (Edit: Schlage FE599/BE369 Lock driver)

So, running out of time to screw with this, I took it to my C5, repeated the exact process and everything came up fine. Used mesh to send it back to the C7 so at least its working for now. I would appreciate any help. I need to get this fixed. I have NO intention of ending up with multiple hubs to run what used to work fine on one.

I have two locks still working on the C7 and I've left them untouched so I have one to test with on the C7 and one for a 'control group'. :slight_smile:

I have NO idea what's going on here and I've never had this happen before so I don't even know where to start figuring this out.

Working C5 (looked the same on the C7 last month):

C7:

Edward

Can you post a screenshot of your z-wave details page on the C7..

1 Like

Here you go.

Edward

Looks like your locks and keypads are paired securely.

And the information of the device page is incorrect. This is possibly suggestive of database corruption. If @bcopeland concurs, I would recommend a Soft Reset followed by a database restore.

https://docs.hubitat.com/index.php?title=Soft_Reset

3 Likes

I have the same issue, Yale locks with S0 no longer communicate. Only report battery at 100% which is not right. R2.3.2.141 Seemed to work last on R2.3.2.128.

Have you done a full hub power down, pull power, and restart? That is the only way to reboot the zwave radio itself.

1 Like

Appoligize for the delay. Had to go out of town.

@aaiyar : Thanks. I'll do this first.

@coreyclerico : No, you do not have the same issue. See OP.

@jtp10181 : I have no idea how this is relevant to the issues in my OP, but as I was about to do this anyway....

@bcopeland : I posted the screen shots as you requested. Anything?

@aaiyar : Waiting on Bryan. Yes, the weirdness on the device page(s) does make me think that too now that you've brought it up.

Edward

Edward

Following @jtp10181 , I power cycled (unplugged and let sit for 10 minutes) and then tried to pair to my C7. Failed. Again. So, I put it back on my C5 (until the next test of the C7). Anyway, this is what always comes up with the C5.

Edward

Failed pairing on C7. This time I got logs. Z-wave Kwikset 99140-101.

Edward

The error message just posted is a strong clue...

Part of the requirement SiLabs has via their 700 series certification has an impact on S0 security devices. They insist that S0 devices be "bootstrapped" to S2... the idea is, I guess, that S2 is a better security than S0.

I have two Yale locks that joined my newest C-7 (2 years ago) that are also S0 only.

The thing I see is that the Dataline for S2: shows 128, which is the code for 'not S2' -- S2 joined devices have larger numbers such as 131 and 132 as shown in this:

Screen Shot 2022-07-25 at 4.48.57 PM

Perhaps this can clarify a bit more:

1 Like

I had a rare occurrence very similar to this with one of my Yale YRD-256 Z-Wave S0 locks, but I just ran a repair and everything was fine afterwards.

Sometimes the current radio can be corrupted. Shutting down from the settings menu, unplugging power (at the wall not the hub) for 5 mins and powering backup clears the radio.

@aaiyar : No luck.

@rlithgow1 : Got it.

Edward

@csteele : So, let me see if I understand this ... My locks will no longer pair correctly because they're S0? And the failure is because the z-wave code on the C7 is broken?

If I follow the logic here ... then NONE of my S0 stuff will pair - again - with my C7 if I have to remove it and re-join?

Edward

S0 Only devices that can join with no security can join just fine, but only as none. (S-none) S0. You can't join S0 Only devices as S0. S-None

Devices that are S0 Only AND are barrier devices, which means they MUST join securely, are impossible easy to join, period. If they join as S-none then their barrier code prevents them from working.

No.. Hubitat can safely be left out of this. :slight_smile: It's pure SiLabs insistence that to remain certified, that S0 devices must 'bootstrap' to S2. The code that's out on the Zwave radio chip is a SiLabs image.

EDIT to correct per @jtp10181 and @bertabcd1234

1 Like

I might be misunderstanding; S0-only devices should be able to join as S0 if they either have a specific secure inclusion process or if that's the only method they support (cough, cough, many Monoprice sensors, the 500-series Zooz 4-in-1, original-firmware Inovelli bulbs, and other devices people love to hate...and, of course, older locks). The issue I'm aware of is that the hub can't not ask them to use security in this case, even if the device works with non-secure inclusion (and S0 carries a lot of overhead compared to either other option, which can contribute to problematic network chattiness).

1 Like

I only HAVE barrier devices. So, "... NONE of my S0 stuff will pair ..." is accurate. Wonderful.

I would like to know what changed in the last month that all my S0 stuff worked the first of June, but not now. SOMETHING was broken between my re-adding the devices after the "migration" and a week or so ago. Either SI, Hubitat or both.

Edward

1 Like

I'm trying to rewind through experiences of a year ago in memory... Am I misremembering?

My understanding is that S0 devices will pair as s0 regardless unless you use a secondary controller to pair with no security. Am I wrong somehow in that?

1 Like