[SOLVED] Kwikset Z-Wave 914 failing to create COMMAND_CLASS_DOOR_LOCK

I think it’s extremely unlikely - the device ACKs the command quite quickly, and then does not respond with the requested data.

ACKS will normally take this amount of time on a FLIRS device as the device does not listen all the time. If the device is awake, it will process quickly, if not, it will process when it next wakes dependant on it’s FLIRS cycle.

Maybe they do, but it is not necessary. For what it’s worth (nothing really) I also do this commercially.

I apologize if I came across pompous. The previous controller I used to control these locks had a stack written by this engineer, which is why I considered it relevant. I’ll have to see if inclusion still works for this lock on my other controller.

Inclusion works fine here - that’s not the issue. The device is included ok - the secure inclusion (key exchange) also worked fine. It just doesn’t respond to the VERSION commands which are normally used by most controllers as we need to know what version of the CCs are supported by a device.

I’ve just noticed that the binding is not requesting these VERSION commands with security - this might be the problem. Most devices don’t require security on this class, but it seems this one might.

Can you provide me the XML generated for your device please.

Oops, I was using inclusion to describe the entire learning process. Here’s the xml

network_c415b3b5__node_84.xml (4.3 KB)

According to my friend, this device won’t respond to VERSION commands w/o security.

1 Like

Yes, that’s what I said :wink:

1 Like

You know what, it might be that antitheft is enabled. Could that explain the behavior?

Edit: I’m going to try to load the locks that aren’t working back onto the vivint panel and see if they have antitheft enabled.

Probably not. The VERSION CC is clearly defined in the NIF as requiring security but the log shows that it “is not required”. I need to look at why this is - the binding has the information, but still thinks it doesn’t need to secure that class.

I’m happy to try anything else or provide any other information you might need.

I’ve found the problem.

The device is reporting that it supports the security command class V0 - this means that it does not support this command class, so the binding removes the command class. This means that it no longer sends the subsequent VERSION commands secured as security is removed.

The device should not report that it is V0. I will need to think about how to resolve this :frowning:

1 Like

Interesting. Checking my purchase history shows that the 2 that aren’t working were purchased Nov '18 and the one that is working was May '19. I wonder if they fixed it in a later firmware.

I think I have a way to fix this through the database. I will check it out over the next day or so and if it is available will update the database this weekend.

2 Likes

I saw you pushed some changes to the db for the 914. I’m happy to try to build and test out your changes or try a CI build once it makes it there.

The binding was updated a few days ago already…

Oh. I’ll go ahead and update!

I was able to add both previously nonfunctional locks to my system with 2.5.1-2. One of them looked like it was repeating its previous behavior, but finally worked after a factory reset. Thanks for your help with this!

The issues I am having are almost identical to the OP, so it doesn’t feel like I should start a new topic.

I also have a Kwikset 914TRL, and am getting COMMAND_CLASS_DOOR_LOCK errors whenever I try to control the device. I made sure to wait a few minutes while pairing, just to make sure it was able to get through a full handshake. I tried it last night, and again just now. The lock was working fine when I was on 2.4.0 of the zwave addon, but I have since upgraded the addon to zwave-2.5.4-20200323.171527-3, to get a different lock in the house (different manufacturer) to work.

Excerpts from my openhab.log:

2020-03-30 18:40:13.299 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'zwave:device:e96ab58b:node23' to inbox.
2020-03-30 18:40:49.814 [INFO ] [alization.ZWaveNodeInitStageAdvancer] - NODE 23: SECURITY_INC State=FAILED, Reason=GET_SCHEME
2020-03-30 18:40:59.861 [ERROR] [ore.internal.discovery.InboxResource] - Thing zwave:device:e96ab58b:node23 unable to be approved: No Thing with UID zwave:device:e96ab58b:node23 in inbox
2020-03-30 18:44:00.382 [WARN ] [nal.converter.ZWaveDoorLockConverter] - NODE 23: Command class COMMAND_CLASS_DOOR_LOCK not found
2020-03-30 18:44:12.420 [WARN ] [nal.converter.ZWaveDoorLockConverter] - NODE 23: Command class COMMAND_CLASS_DOOR_LOCK not found
2020-03-30 18:44:47.293 [WARN ] [nal.converter.ZWaveDoorLockConverter] - NODE 23: Command class COMMAND_CLASS_DOOR_LOCK not found
2020-03-30 18:45:20.357 [WARN ] [nal.converter.ZWaveDoorLockConverter] - NODE 23: Command class COMMAND_CLASS_DOOR_LOCK not found
2020-03-30 18:45:46.922 [WARN ] [nal.converter.ZWaveDoorLockConverter] - NODE 23: Command class COMMAND_CLASS_DOOR_LOCK not found

Excerpts from events.log:

2020-03-30 18:40:13.299 [home.event.InboxAddedEvent] - Discovery Result with UID 'zwave:device:e96ab58b:node23' has been added.
2020-03-30 18:40:30.696 [me.event.InboxRemovedEvent] - Discovery Result with UID 'zwave:device:e96ab58b:node23' has been removed.
2020-03-30 18:40:30.728 [hingStatusInfoChangedEvent] - 'zwave:device:e96ab58b:node23' changed from UNINITIALIZED to INITIALIZING
2020-03-30 18:40:30.732 [hingStatusInfoChangedEvent] - 'zwave:device:e96ab58b:node23' changed from INITIALIZING to OFFLINE (BRIDGE_OFFLINE): Controller is offline
2020-03-30 18:40:30.732 [hingStatusInfoChangedEvent] - 'zwave:device:e96ab58b:node23' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE
2020-03-30 18:40:30.736 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:e96ab58b:node23' has been updated.
2020-03-30 18:40:30.756 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:e96ab58b:node23' has been updated.
2020-03-30 18:42:42.590 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:e96ab58b:node23' has been updated.
2020-03-30 18:42:42.621 [hingStatusInfoChangedEvent] - 'zwave:device:e96ab58b:node23' changed from ONLINE to UNINITIALIZED
2020-03-30 18:42:42.637 [hingStatusInfoChangedEvent] - 'zwave:device:e96ab58b:node23' changed from UNINITIALIZED to ONLINE
2020-03-30 18:42:42.668 [hingStatusInfoChangedEvent] - 'zwave:device:e96ab58b:node23' changed from ONLINE to UNINITIALIZED (HANDLER_MISSING_ERROR)
2020-03-30 18:42:42.700 [hingStatusInfoChangedEvent] - 'zwave:device:e96ab58b:node23' changed from UNINITIALIZED (HANDLER_MISSING_ERROR) to INITIALIZING
2020-03-30 18:42:42.700 [hingStatusInfoChangedEvent] - 'zwave:device:e96ab58b:node23' changed from INITIALIZING to OFFLINE (BRIDGE_OFFLINE): Controller is offline
2020-03-30 18:42:42.700 [hingStatusInfoChangedEvent] - 'zwave:device:e96ab58b:node23' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE
2020-03-30 18:42:42.700 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:e96ab58b:node23' has been updated.
2020-03-30 18:44:00.373 [ome.event.ItemCommandEvent] - Item 'Lock_UpperEntry' received command ON
2020-03-30 18:44:00.378 [nt.ItemStatePredictedEvent] - Lock_UpperEntry predicted to become ON
2020-03-30 18:44:00.389 [vent.ItemStateChangedEvent] - Lock_UpperEntry changed from NULL to ON
2020-03-30 18:44:12.420 [ome.event.ItemCommandEvent] - Item 'Lock_UpperEntry' received command OFF
2020-03-30 18:44:12.424 [nt.ItemStatePredictedEvent] - Lock_UpperEntry predicted to become OFF
2020-03-30 18:44:12.432 [vent.ItemStateChangedEvent] - Lock_UpperEntry changed from ON to OFF
2020-03-30 18:44:47.293 [ome.event.ItemCommandEvent] - Item 'Lock_UpperEntry' received command ON
2020-03-30 18:44:47.297 [nt.ItemStatePredictedEvent] - Lock_UpperEntry predicted to become ON
2020-03-30 18:44:47.297 [vent.ItemStateChangedEvent] - Lock_UpperEntry changed from OFF to ON
2020-03-30 18:45:20.357 [ome.event.ItemCommandEvent] - Item 'Lock_UpperEntry' received command OFF
2020-03-30 18:45:20.357 [nt.ItemStatePredictedEvent] - Lock_UpperEntry predicted to become OFF
2020-03-30 18:45:20.361 [vent.ItemStateChangedEvent] - Lock_UpperEntry changed from ON to OFF
2020-03-30 18:45:46.918 [ome.event.ItemCommandEvent] - Item 'Lock_UpperEntry' received command ON
2020-03-30 18:45:46.922 [nt.ItemStatePredictedEvent] - Lock_UpperEntry predicted to become ON
2020-03-30 18:45:46.926 [vent.ItemStateChangedEvent] - Lock_UpperEntry changed from OFF to ON

Does anyone have any ideas for how I might get this thing recognized?

Have you securely included the device into the network? If not, the lock command class will not be available and you should reset the device and perform the secure inclusion again.

1 Like

Well, the controller Secure Inclusion Mode is set to “Entry Control Devices”, as it always is, but the “Using Security” attribute on the lock has a red x instead of the green check. I assume that is the only control I have over whether or not a device is included securely? I’ll try the factory reset thing on the lock today.

It’s not just about how the device is set - it’s about “was it securely included”. If it’s not securely included, then it won’t work. Secure inclusion has VERY tight timing requirements - if it doesn’t work, then you MUST reset the device and start again. It will fail within 15 seconds if there are any problems.

So - the question is “is it securely included”? PaperUI will show this in the properties so you should check this.

1 Like