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

Setup, Configuration and Use Beginners
10

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

11

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.

12

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

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

13

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.

14

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.

15

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.

16

Which UID are you referring to?

17

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.

18

The think type UID

20

IMHO the Thing Type UID

grafik
grafik707×27 846 Bytes

shouldn’t change when the manufacturer name gets updated:

grafik
grafik722×133 3.03 KB

21

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 -:

image

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.

22

With respect to the hard reset, I have tried two ways. One I exclude the device from the network through the Z-wave controller options and pressing the inclusion button on the lock, I then delete the z-wave thing and try the inclusion again.
The other method is excluding the lock and then doing a factory reset where the lock loses all the information including which way the strike extends, basically starting from scratch.
I never restart OpenHab.

I’ll check after work about the secure exclusion and post all the product properties.

23

Agreed, I hadn’t thought of the file name that contains the manufacturer name.

24

Either of these should be fine - just to reiterate that it must be done each time, which you’re probably doing, but since you didn’t explicitly state, and it’s super important, then I thought I’d mention it again :slight_smile: .

This is just one thing that can make the network busy and hence delay / fail the key exchange. I think it would be worth you grabbing the debug logs to make sure there’s not something else causing things to be busy and causing the same issue


25

Could you please post the data for your device?

26

And again, just to be clear, what’s needed is the properties as specified above, but also including the device id (I think it’s zwave_deviceid).

27

This is the thing label

label: Z-Wave Node 045 (0090:0811:13A8:7.13)

and the thing properties

zwave_class_basic                             BASIC_TYPE_ROUTING_SLAVE
zwave_class_generic                         GENERIC_TYPE_ENTRY_CONTROL
zwave_frequent                                   true
zwave_neighbours
zwave_listening                                  false
zwave_version                                   7.13
zwave_plus_devicetype                    NODE_TYPE_ZWAVEPLUS_NODE
zwave_deviceid                                 5032
zwave_nodeid
45
zwave_routing                                   true
zwave_plus_roletype                        ROLE_TYPE_SLAVE_SLEEPING_LISTENING
zwave_beaming                                true
zwave_secure                                  true
zwave_class_specific                      SPECIFIC_TYPE_DOOR_LOCK
zwave_devicetype                            2065
zwave_manufacturer                       144

I’ll look for the DEBUG log and post it
Thanks

28

As suspected, your device has to be added to the Z-Wave database:

grafik

Next steps:

  1. Check that the database entries for OpenSmartHouse Z-Wave Device Database match your device.
  2. If there are no differences, add 0811:13A8 to ‘References’ and request a review, otherwise a new entry for a new device must be created in the Z-Wave database. Please read Blog Posts for information on how to get access to the Z-Wave database.
  3. Wait for review and for new Z-Wave Binding snapshot.
  4. Install new Z-Wave Binding snapshot.
1 Like
29

I’ve made the update and am doing a database export shortly.

1 Like
30

Thanks to everyone