Z Wave Lock with failed attempt alarm

Devices & Integrations
1

Another fairly trivial change to an existing device type: I have a Kwikset lock 912 and 910 - both report when an invalid code is entered. Sounds like an alarm condition to me :smile:

Start with the Z Wave Lock template (or the Z Wave Lock Reporting version - works with either…)

Add to metadata:

capability "Alarm"
command "reset" // reset tamper state

Add to tiles:

standardTile("tamper", "device.alarm") {
  state("secure", label:'secure',    icon:"st.locks.lock.locked",   backgroundColor:"#ffffff")
  state("failed", label:'tampered',  action:"reset", icon:"st.alarm.alarm.alarm", backgroundColor:"#53a7c0")
}

Add “tamper” to details…

In this function

def zwaveEvent(physicalgraph.zwave.commands.alarmv2.AlarmReport cmd) {

Look for case 161 - add this to the “else” portion

// trip alarm
sendEvent(displayed: true, name: "alarm", value: "failed", descriptionText: "$device.displayName has had a failed code entered")

End of file add:

// for failed code entry
def reset() {
  log.debug "reset alarm state"
 sendEvent(displayed: true,  isStateChange: true, name: "alarm", value: "secure", descriptionText: "$device.displayName reset to non-alarm")
}

This will trip the alarm state for the door lock if someone enters an invalid code. You could do whatever you want with that. The alarm state stays tripped until you reset it by tapping the tamper tile in the device or set the alarm state via an app.

EDIT: Somehow uppercase S slipped into sendEvent()!

Edit2: You need to enter a bad code 3 times - the lock flashes several times and makes a lot of beeping sounds - and fires the alarm event :slight_smile:

Edit3: Screenshots on the way

2 Likes
2

Normal mode:

After 3+ failed attempts at codes:

Your event log when someone’s been naughty, and then you tap the alarm tile to clear the alarm:

Screenshot_2015-05-08-16-50-01.png1440×2560 504 KB

3

Due to the lack of response from SmartThings with respect to new Capability requests, I understand why you chose “Alarm” to tag this Device, but in my opinion, it is not the right choice (there is a very long extensive discussion about this in the “New Capabilities” Category, BTW).

Capability Alarm is meant for Devices that sound alarms (i.e., either via a siren and/or strobe) – i.e., it is an activated device (an actuator).

The Attributes of Alarm do not make sense for Tamper messages:

878×99 2.95 KB

A device of Capability Alarm must be able to respond to the 4 Alarm commands (off(), strobe(), siren(), both()).

Detecting tampering is a passive device (a sensor), and only has one Command, as you noted, “reset()” (although reset probably should be done only physically at the device, because if it was tampered with, it needs to be physically inspected!!!).

My recommendation?
If you don’t just want to use generic Capability Sensor, then any binary sensor device is applicable, such as Capability Smoke Detector, Capability Contact Sensor, or Capability Motion Sensor. The latter is “self-resetting”, in theory, when “motion (tampering) stops”, the former is easily extended with your “reset()” command.

877×38 2.22 KB

I hope my explanation of why Alarm is a bad fit makes sense, but it’s just an opinion and open to discussion.

Even SmartThings engineer proposed the new Capability Tamper Alert too, sigh:

4

Tamper is the right thing (although I sure might want to SOUND an alarm if someone tries to unlock my doors by guessing - perhaps passive devices should have “raise()” and “reset()” alarm?)

For the door lock guess alert, I figure you want some event you could look for in an app, and some persistence of the tripped state. The tamper state could clear when the door is successfully locked, for example. This is just about the same as the tamper switch on those door sensors - they trip when they fall off or are removed - could clear when the sensor detects “close” again.

I could just make a custom tamper attribute I suppose. Anyway, the details of the thing are actually less important to me than to ST - they control the models. I just wanted a way to see the tampering in the system…

1 Like
5

Absolutely correct… This is a very useful and important feature to implement, regardless of what it is called. And by actually coding these examples, it puts more weight behind the need for an officially defined Capability when ST starts adding them.

In the meantime I lean towards adding custom / adhoc Attributes and Commands, rather than accidentally “redefining” one of the existing “well-defined” Capabilities.

6

Lemme clean this and the contact sensor up and post non-model-polluting versions :smile:

2 Likes
7

For what it is worth - I have a new Schlage Connect Touchscreen bolt. The current ZWave Lock device handler does everything I needed except for the failed attempts. I had to make a copy of the stock handler and add “isStateChange: true” to Line210 (case 0x10 under (cmd.zwaveAlarmType == 6).

Here is the debug for a failed attempt: Cmd: AlarmReport(alarmLevel: 1, alarmType: 161, eventParameter: [], numberOfEventParameters: 0, zensorNetSourceNodeId: 0, zwaveAlarmEvent: 16, zwaveAlarmStatus: 255, zwaveAlarmType: 6)

zwaveAlarmEvent: 16 is of course 0x10.
My app subscribes to “tamper”, so both the forced (kick) alarms as well as the failed attempts go to the same place where I can turn on my camera, lights etc.

1 Like
8

Sounds like an excellent candidate for a Pull Request against the SmartThings Public GitHub repo!
@Tyler?