Z-wave binding Kwikset 620 lock shows Unknown thing with no channels

  • Platform information:
    • Hardware: CPUArchitecture/RAM/storage
    • OS: Windows 10
    • Java Runtime Environment: 11
    • openHAB version: 3.4.0 stable release

I am trying to add a kwikset 620 z-wave lock to my system.
I can add the lock to the network but all I get is an unknown thing with no channels

I looked at this thread

Which says to keep trying until it works but I tried 4 or 5 times with several factory resets and I always get the unknown thing without channels.

If I look at the OpenSmartHouse Z-wave database it shows the Kwikset 620 lock approved although I’m, not sure what the 1/7/23 date means

Unique Reference ks620
First Approval 2022-08-08 23:29:03 OH-SNAPSHOT
Last Approval 2023-01-07 18:54:13 OH-SNAPSHOT

But if I look at Github and look at the list of supported things full list of supported things.
The Black and Decker Kwikset 620 is not there.

So should this lock work with Openhab and the 3.4.0 Z-wave binding or do I need to wait until a new binding is released ?

Thank you

Keep waking it up, it is battery powered, it may take a lot of tries. If you are trying to include it using security, (which since it is a lock, I’m assuming you are) that takes even longer then a normal battery device. How close is it to the controller?

Also, how are you doing the inclusion? Secure inclusion must be started from openHAB, and not from pressing the button on some USB sticks.

Before you do it again, put the controller into exclusion mode to ensure that it removes the door lock from memory. Then try including it again.

It’s been a long time since I did a secure inclusion, but I had to bring my controller within a few feet of the lock.

I always do the inclusions the same way. I go to Things, click on the + sign, choose the Z-wave binding, click on SCAN and then press the button or the paddle or whatever the manufacturer says

I will try it again


The first few tries it was directly above it on the next floor, the last two tries it was about 3 feet away in the same room

ok, just keep waking the lock, don’t wait between tries
eventually it will get all data needed for inclusion

There is one other possibility. Does the UI page show 5 lines at the bottom
Five Lines of configured node

If yes, check the MFG & TYPE:ID pair with the Zwave DB for the device. It will be under the Thing properties tab. Yours could be different and need to be added. Some of the properties are in Hex and some in decimal, so make sure to watch that.

Yes the UI shows the 5 lines
The properties show

  • zwave_devicetype 2065
  • zwave_manufacturer 144

The database shows

Manufacturer [0090] Black & Decker
Type 0811:23A8

Should I enter 90 for the manufacturer and how do I transform 0811:23A8 into a number in digital format?

The thing properties are grayed out in the UI, I assume there is an XML file somewhere that can be modified, do you know where that is?, or is there another way to change the properties values?

Thank you

Hi I tried that, played with the lock, opening and closing it and adding lock codes for about 1 hr and then leaving it overnight and nothing
I think it is a database issue

This device has not been fully discovered by the binding. There are a few possible reasons for this -:

  • The device is not in the database. If the device attributes show that this device has a valid manufacturer ID, device ID and type, then this is likely the case (eg. you see a label like “Z-Wave node 1 (0082:6015:020D::2.0)”). Even if the device appears to be in the database, some manufacturers use multiple sets of references for different regions or versions, and your device references may not be in the database. In either case, the database must be updated and you should raise an issue to get this addressed.

My lock device shows in the same format as that shown in the explanation Z-Wave node xx (0082:6015:020D::2.0)

Thanks for your suggestion

For further analysis the zwave_deviceid from the Thing Properties is needed (or the values ‘(0082:6015:020D::2.0)’ for your specific device).

Since the device properties have been discovered, communications with the device looks fine and this device is in the database so there ought to be channels showing…

Continually “waking up” a lock won’t help since it is basically always awake. Locks are what’s called FLiRS devices - these wake up themselves periodically - it can be 1 or 10 times per second - to allow communications to occur without waking the device up.

This is fine, but do you perform a hard reset on the lock before doing this? Locks can only be included into the network if they are hard reset since the key exchange protocol can only take place within 15 seconds of them joining the network.

Also, when you join the device, don’t do it too soon after starting the system as the network may be busy and this can slow things down if it needs to talk to other devices, and it can push the key exchange out past the 15 seconds. Once this happens, you need to reset the device and start again.

Also in the properties, does it show that the device is securely included?

Properties can’t be changed - they are set by the binding.

No - you can’t change them. They are just properties that give the user information from the binding and changing them will do nothing.

Based on the above, and the fact that your device IDs seem to have been discovered and are consistent with the database, I don’t think so.

My guess is it’s related to the secure join and the restrictions on the timing I mention above. You can also get a debug log to see what’s happening - this should show if the key exchange works ok or not.

We cannot be sure that @clark’s device is a 0811:23A8. IMHO he just quotes the data in the Z-Wave database.

Manufacturer 0x0090 should be changed to ‘Spectrum Brands’ in the Z-Wave database.

Well, he said above that his properties were the same -:

These values come from reading the information from the device (and can’t easily be manipulated by the user), and are correct for this device. Admittedly this doesn’t include the device id which is the third component, but 2 out of 3 values are being correctly read from the device and are consistent with the values in the database.

Sorry - I missed this point. I prefer not to change things here as it potentially then changes everyone UID on their devices and will break peoples systems. We could just change the name that people see and leave the UID and Black and Decker, but that is then inconsistent and will likely cause further confusion. IMHO it’s best just left alone - at least it’s consistent in OH and doesn’t break peoples systems - even if it’s changed and now not consistent with the ZWave definition.

And that might be the problem here:
I cannot find any indication that a 0090:0811:23A8 even exists. :slight_smile: The Z-Wave Alliance tells us that there are 0090:0811:03A8 and 0090:0811:13A8, but I cannot find a 0090:0811:23A8 in their database.

Which UID are you referring to?

But that’s from the database so it almost certainly exists since someone created it with their XML (unless it got changed).

The ZWave Alliance system is very unreliable and incomplete - I wouldn’t rely on that at all.

We need to see the complete set of properties from @clark to know what the ID is.

The think type UID

IMHO the Thing Type UID

shouldn’t change when the manufacturer name gets updated:

Well, that’s the issue issn’t it…

We either have a thing type UID that doesn’t match the name, or a name that doesn’t match what the ZWave Alliance now calls the company. Ideally, the UID used for the company would be aligned with the name of the company - that’s not always the case, but something we try and do to avoid people getting confused.

Anyway, for now I don’t propose to change the UID or the name in the database.

I don’t really understand what you’re trying to show here though with this image? The thing type UID is made up of two parts - the part that is listed at the bottom of the device entry, and then another part that comes from the manufacturer entry in the database.

If we take your example of the NAS-PD07Z, then in that devices entry, we see -:


I agree - this doesn’t change.

However we also have another part that comes from the manufacturer, so the full thing type UID is shenzhen_naspd07z_00_000. This is made up of the manufacturer name, the device UID, and the version.