Just tried on my Kwikset 916 lock and confirm after 3 attempts the touch screen is locked out, but I do not see same info logs as above. Just log entries for manual lock/unlock.
Make sure that you have debug logging enabled for the lock and look at live logging for the entire hub and you will see these events. You will not see them on the events page for the device.
Which means the driver is not creating an event for this. Back to what @mike.maxwell said, the lock drivers don't do this because of lack of uniformity in how the locks themselves handle it.
I now see in the log file:
dev:3222020-07-08 03:51:44.157 pm infoGarage Door Lock detected failed user code attempt[161]
dev:3222020-07-08 03:51:44.152 pm debugalarmv2.AlarmReport: AlarmReport(alarmLevel:1, alarmType:161, eventParameter:[], numberOfEventParameters:0, zensorNetSourceNodeId:0, zwaveAlarmEvent:0, zwaveAlarmStatus:0, zwaveAlarmType:0)
dev:3222020-07-08 03:51:44.146 pm debugparse: zw device: 09, command: 9881, payload: 00 71 05 A1 01 , isMulticast: false
Cool .. I have the 916 too .. would be nice if someone can whip up a way to send this to the HE notification to alert us when there been failed attempts .
1 Like
There's a couple ways I can think of:
I looked at the post and it for Schlage' lock?
The 916 is a Kwikset lock but again I am not a coder so I wouldn't know exactly how to make it work 
I'm not sure you can... I just tried this on one of my zigbee Kwikset 916 locks, and you get no event in Node-RED as the event type is "tamper" and there is no "tamper" attribute.
For some reason I don't think this event gets sent out by Maker API at all... Could be wrong though. 
With my Yale lock, I read the content of "msg.payload.descriptionText"
The kind of lock doesn't matter. You can edit it to work with any lock .....
That won't work w/my Kwikset Zigbee (no idea of the zwave is different). There is no event in node-red whatsoever when the invalid code tamper event happens.
Aha - it has been mentioned that some of the info messages are lock specific.
There is a tamper event in Hubitat logged, but nothing in node-red. So I'm not sure if Maker API isn't sending the event at all, or if the node-red nodes are trashing it (but I was coming off the "event" node, so I don't think so...).
That's weird. FWIW, I not using the event node. I'm using the lock device node with "All" attributes selected.
I turned on Maker API debugging - it is not in there, so I'm pretty sure Maker API isn't sending the event at all. 
@bravenel or @mike.maxwell - Any idea why when I input the wrong code enough to get a tamper event on the lock, and an event shows up in the device logs, that Maker API is not sending an event for this? I would think if the device is generating an event then Maker API should be sending it?
This is with the in-box Generic Zigbee Lock driver.
Note below - no Maker API debug log at all for the tamper event @ 8:07:38...
Device Log:
Maker API debug log:
-
You see the lock event in Maker API at 8:06:35 -
Tamper event @ 8:07:38 is missing altogether -
Next lock event in Maker API is the manual unlock at 8:07:42
1 Like
Huh - I just tried my sequence again, and it doesn't work. I'll be danged - I was sure "sure" it worked because I remember playing around to get the switch node right.
Maybe it works if you use websocket instead of webhook. 
I'm not willing to test that right now, though.
I just wanted it to work with the built in HE notification app .
Is this possible?
I entered wrong codes a couple of times in my 916 ZWave where it blinks red color when entered wrong
Nothing shows up in my event log
The attribute is not showing up as a supported attribute for the device. Maker API subscribes to all of the supported attributes of a device. And, "tamper" is not an attribute in the driver, although it is an event.
Unfortunately, "tamper" "detected" is used for several different conditions, not just the one you are interested in. Only the description text discriminates which of those it is, and Maker API (and other apps) don't look at description text. I suspect we'd have to do some schema work to surface this attribute and its possible conditions.
Z-Wave lock driver does not send an event for this. I'm not sure, but the lock may not be reporting it.
This is the reason nothing has been done with this; there is not consistency across the various locks.
