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

Hardware Home Automation
1

I’m having an issue adding 2/3 of my Kwikset 914 locks. One has loaded fine, and might have been loaded on 2.4, while 2.5 fails to properly include the door locks.

I have about 60 z-wave devices on my network, including 4 door locks. 3 Kwikset 914’s (914TRLv3) and an August Pro. The August Pro was added with 2.5 and the 2.5.0 z-wave bindings, and works fine.

Platform: openhabian 2.5 on Raspberry Pi 4 w/ 4gb ram, 32gb sd

Here’s the info in thing in paperUI about the device

dbReference 1062
defaultAssociations 1
manufacturerId 0090
manufacturerRef 0003:0440
modelId 914TRLv3
vendor Black & Decker
zwave_beaming true
zwave_class_basic BASIC_TYPE_ROUTING_SLAVE
zwave_class_generic GENERIC_TYPE_ENTRY_CONTROL
zwave_class_specific SPECIFIC_TYPE_SECURE_KEYPAD_DOOR_LOCK
zwave_deviceid 1088
zwave_devicetype 3
zwave_frequent true
zwave_listening false
zwave_manufacturer 144
zwave_neighbours
zwave_nodeid 67
zwave_plus_devicetype NODE_TYPE_ZWAVEPLUS_NODE
zwave_plus_roletype ROLE_TYPE_SLAVE_SLEEPING_LISTENING
zwave_routing true
zwave_secure true
zwave_version 4.10

I can see that it is adding securely, but the thing never gets a COMMAND_CLASS_DOOR_LOCK so any attempts to control the thing with a configured item gives an error and does nothing. As mentioned above, the other locks are working without issue.

The other thing to note is that I’m was getting a TODO in the logs about zwave, until I factory reset one of the locks, excluded it, and re-added it.

2020-01-08 13:46:35.906 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Last transaction: null
2020-01-08 13:46:35.908 [DEBUG] [ve.internal.protocol.ZWaveController] - Incoming Message: Message: class=ApplicationUpdate[73], type=Request[0], dest=67, callback=64, payload=40 43 06 04 40 03 5E 72 98 
2020-01-08 13:46:35.909 [WARN ] [essage.ApplicationUpdateMessageClass] - TODO: Implement Application Update Request Handling of New ID Assigned (64).

I’ll include the logs that show the inclusion process. The lock is added most recently as Node 67.

2

Stephen,
What Z-wave usb device are you using?

3

I’m using the Linear HUSBZ-1

4

Ok, sorry I have no experience with that.

Sometimes you need to be very close to the device to include it with all of the security features.

5

I had the pi on a battery pack about 3ft from the device. It shows that security is enable and oddly enough on openHAB 2.4 one of the other identical locks from the same lock worked fine.

6

Good luck and don’t give up!

7

Thanks! I won’t!

8

Try factory resetting the lock. I believe there was mention that on some locks you need to factory reset before trying to include again. I know factory reset helps on other Z-Wave devices.

9

Thanks, Bruce. I did try a factory reset before this last attempt and inclusion remained the same.

Is there a good overview somewhere in the code or perhaps another log where I can see an example of a secure keypad doorlock properly get included?

10

Sorry I do not use them. I think @sihui may have some Z-Wave locks.

11

No really - it’s unfortunately quite complex, and difficult to debug due to lots of security constraints including very short times for things to happen. You can read through the ZWave docs, or the source code.

From a quick look at the log above though, the secure inclusion was working fine. It looks like the device did not respond to the VERSION command class requests and it gets stuck at that point.

1 Like
12

Thanks Chris! I’ve been looking through the z-wave docs and that gives me something to poke around at.

As an aside, I’m super impressed with what has been done with z-wave in openHAB. Even with a hiccup here or there, it’s already been way better to work with than some commercial solutions that have been around for a while.

2 Likes
13

Nope, too expensive :grinning:

1 Like
15

Is this a new lock or had it previously worked? The quality control on the Kwiksets is very poor. I had 2 bad locks before I got a third to work just fine. I also had one of the locks work for a few days before it became totally unusable and would only work after a factory reset.

1 Like
16

2 of the locks were installed and functional with a Vivint system for about a year before migrating to openHAB

17

Oddly enough my Kwiksets (888) that both failed to properly join were branded Vivint on the inside and my third was not branded Vivint on the inside. Don’t know if that has anything to do with it or not.

18

Vivint doesn’t sell the 914s, so I bought them off of amazon.

19

Then we may need a new database entry for this rebranded version, please post your xml file for that device from your userdata zwave folder.

1 Like
20

Is it possible that the default 5000ms timeout isn’t long enough for the VERSION_COMMAND_CLASS_GET for BASIC and that the binding isn’t giving the lock enough time to reply?

I’m going to work on getting a dev environment setup to be able to mess around with the binding to play around with timeouts, however, I figure I’d just do a sanity check due to my unfamiliarity with z-wave behavior.

Edit: I suspect the lock is trying to process something because the next ACK takes over a second to process when previous ACKs happen in 30ms.

21

I checked with a friend who’s written the z-wave stacks for some commercial devices and they confirmed they typically use 10s timeouts for GETs like this. The only other thing that would influence the lock not responding would be that the GET isn’t sent with security encapsulation/encryption.