Problem with manual operation updates in Kwikset 914TRLv3

I have installed a Kwikset 914TRLv3 Touchpad Electronic Deadbolt and the secure inclusion seemed to go through painlessly. I can open and close the lock via openhab and the Door Lock channel updates as expected. I do NOT see any indication of any of the various Alarm channels updating though.

Also, if I manually lock or unlock the lock from the keypad or by turning the knob there are no entries at all in the DEBUG logs. I am assuming that I’ll need the Alarm channels working for openhab to be able to update on manual changes.

Here is some info:


Here is a log that is generated when I use openhab to lock the door. In it you can see that an ALARM_REPORT is generated but I never see any of the channels updated, maybe because they are setup as type Switch. I did notice the alarm channels on the 914TRL were setup as Number or String.

zwave.log (90.2 KB)

Also, here is a copy of my XML file, if needed.

network_c36bbef5__node_28.xml (21.4 KB)

I’m hoping @chris or one of the other Zwave gurus here can make sense of this as it is beyond me. I have read various other threads here about other locks that have had similar problems but I think Chris usually ended up fixing db entries.


I’ve added a new channel “Entry Notification” that should fix this. I’ll try to do a database update tonight so it will be available tomorrow - you’ll need to delete the thing and add it back so that it picks up the new definition.

Thanks Chris! It’s greatly appreciated.

Well, it’s still a no go for manual operation. I updated and removed/re-added the thing and now have the Entry Notification channel. I can see the channel update when I control via openhab but nothing on manual changes.

I’ve attached a log with the lock being node 28. At 9:50 you’ll see me unlock the lock via openhab. Between then and 10:00 I lock/unlock the deadbold 4 times manually (keypad/knob) then at 10:00 I lock the deadbolt via openhab.

Any ideas?

zwave.log (309.3 KB)

It looks like it’s working to me? At 10:00 I see the state update -:

This isn’t a request from OH - it’s a status update from the lock. I don’t see this happening 4 times as you say - there’s just a single notification to say the door is locked.

Correct, but I guess I didn’t word it properly. I do see the State Updates, but only after an openhab initiated transaction.

Unlock via openhab
09:50:15.181 28 COMMAND RECEIVED zwave:device:fc25cf47:node28:lock_door OFF [OnOffType]
09:50:20.445 28 STATE UPDATE zwave:device:fc25cf47:node28:lock_door OFF [OnOffType]

Manual operations take place here. I would expect some STATE UPDATES in this 5 minute period but I guess I just don’t understand how things work. Maybe the lock doesn’t send updates on manual operations?

Lock via openhab
10:00:32.464 28 COMMAND RECEIVED zwave:device:fc25cf47:node28:lock_door ON [OnOffType]
10:00:51.096 28 STATE UPDATE zwave:device:fc25cf47:node28:alarm_entry ON [OnOffType]

I think the lock is sending reports - these NOTIFICATIONS cannot be requested from the binding - they are only notifications from the device.

There are some strange things happening though and there are some delays in receiving data - I suspect that these delays might fool you into thinking that the device isn’t sending reports?

If we look at a longer log -:

Here we see that the binding did not request this alarm - the device sent it. But you can also see some other “bad stuff” - the data abort and the CAN message which are caused by a timeout from an earlier message to the lock at 10:00:34 (the first line in the log image above). There’s also a 10 second delay here from the device sending the NONCE request and the binding responding - that will be caused by the earlier data abort. This 10 second delay in responding to the nonce is causing a 10 (or probably slightly more) second delay in updating the channel information.

I would try again a few times to see what happens. If you’re seeing data aborts regularly, then maybe the lock is on the edge of the mesh and the mesh needs improving. Of course I’m just guessing from looking at the logs, and if you tell me it’s sitting next to the controller then we’ll have to think of another reason :wink: However, that’s what the logs tell me so far :slight_smile:

The lock is on the edge of the mesh about 40 feet from the controller. It has a mains powered device about 5 feet from it and another one about 5 feet from that, both with a clear line of sight. I will move the closest mains device to the other side of the lock so that the lock isn’t at the meshes farthest point.

I’ll give it a couple of days and see if that makes any difference.

Thanks again for your help.

1 Like

Well, I gave it a few days and still no manual updates. I’ll attach a log for about the last 24 hours and I think you’ll see very limited communication from the lock (Node 28). I purposely avoided triggering the lock using openhab to avoid any confusion. I only used the knob or keypad to open/close the lock.

I’m still seeing some data aborts but they seem to be for Node 18 which is about 10 feet from the controller.

Sorry if the log is excessive but I was hoping it would give you a better picture regarding the communication, or lack thereof, with the lock.


@chris have you had a chance to take another look at this?


Sorry - I missed this. As you said, there’s not a lot of communications so there’s not really a lot that I can comment on. In the previous logs there were reports being sent, so I’m not sure why it would stop now.

That’s the point I was trying to make in our original conversation. The reports seem to only be sent after an openhab initiated transaction. I can’t recall one ever being sent in response to a manual operation. That’s why I made sure not to use openhab during the time period of the last log.

I also reached out to Kwikset regarding the problem and they stated:

The lock is not set up to send the controller notifications as to when the door is locked or unlocked manually, you may want to work with your control provider to see what other features can be used with this lock through their system.

Does that make sense to you? Especially when the earlier versions on the lock seemed to do so via the alarm_raw channel.

The alarm report that I see in the earlier log is not requested by the binding.

However, if there are no reports being sent, then you will need to configure the device. Normally if this is a ZWave+ device, the controller will configure the lifeline. If it’s not a ZWave + device, it will configure any association group set with the “report to controller” setting in the database (see the binding docs for your device as it’s also specificed there). Otherwise you need to set the association manually.

I am so sorry for my lack of communication skills. I agree with you 100%. I was trying to make a point that is now moot.

This is a Zwave+ device and if by “configure the lifeline” you mean to set the Lifeline association group to Controller, I had to do that manually when I first included the lock. I just double checked it now and it is set for Controller but I still don’t get an update on manual operations.

Am I understanding you correctly?

That’s pretty strange - I suspect it was set but possibly not showing properly in the UI. Unless there was an error during initialisation, the binding will detect the lifeline automatically, and set this association automatically. I just checked and the database also has this configured automatically.

If that is set, then the device should send updates.

Ok, I guess I’ll just have to write this one off as a no go.

Hopefully, someone with this lock will see this thread someday and let me know if they ever get manual updates.

Thanks for all of your help Chris!!