Probably not. If there isn’t an event being send I don’t see how I can trigger it.
I’ll see if I can come up with something for jams tomorrow.
1 Like
I’m recovering from a wisdom teeth removal. I’ll start on this sometime this week. Sorry guys.
1 Like
no issues, take care, so just to understand this you’ll be making a separate app that can be used to send notifications / SMS in case of a door jam (not a new device type right?)
You got it
I also have this lock. Didn’t realize it had an alarm built in to it, but of course that makes sense. Interested in any discoveries made here. My ideal future state for this lock is that codes are turned on/off (programmed/removed, i guess) based on day of week and time of day. That way I can limit usage of codes provided to the maid, etc.
1 Like
This sounds awesome… I look forward to this (worth way more than just a “Like”!)
Just now starting to work on this. Not sure how to handle the jam value. Gonna try though
I wasn’t checking in the right place. When I look at the debug logs the Z-Wave lock device logs the following when the alarm goes off:
@tslagle13 BINGO!
3a44cf03-6583-4531-9066-7344fcf14223 12:44:54 AM: debug "zw device: 04, command: 9881, payload: 00 71 05 00 00 00 FF 07 02 00 " parsed to [‘displayed’:false, ‘descriptionText’:Front Door: alarm event 0 level 0, ‘isStateChange’:false, ‘linkText’:‘Front Door’]
Can you use this to capture the alarm and then use to push a notification/SMS as well as set off the main alarm (optional)?
That was for when the door has been tampered with (Tamper Alarm).
This one below is for when the wrong code is entered too many times and the alarm goes off:
3a44cf03-6583-4531-9066-7344fcf14223 12:51:22 AM: debug "zw device: 04, command: 9881, payload: 00 71 05 A1 01 00 FF 06 10 00 " parsed to [‘descriptionText’:Front Door: alarm event 16, ‘display’:false, ‘isStateChange’:false, ‘displayed’:false, ‘linkText’:‘Front Door’]
Good find!!!
This will need to be added to the device type itself.
I’m not great at device types but I will see what I can do:):). The quest continues 
1 Like
@tslagle13 so the device type code it capturing this alarm event that’ why it’s showing up in the log. What would you need the device code to do for the app to use it?
Did we get anywhere on this? I have the lock and might give it a stab, but dont want to start from zero if work has been done!
It’s a small fix to the device code. I’ve made some changes but haven’t had to extensively test them. Also the door device type would have to be modified to a sensor to send the alarm (motion sensor) event.
What would really be nice is if ST would add a capability type for sending “alert” type messages. This door lock in particular can send several alarm/alert type messages. There are burglar type alerts, tamper alerts, invalid code, jammed device, etc. However, without a capability and associated attribute to attach those events to, there doesn’t seem to be any way for a smartApp to subscribe to them and react!
Having these alerts piggy back on other attributes is very hack’ish. (In theory, I guess, they could all piggy back on the “door” attribute, the same way that the “lock jammed” message does…)
BTW, earlier in the thread there’s reference to an alarmevent 0, alarmtype 0. That is the result of the tamper alarm (set alarm type to ‘tamper’ and then bang on the door.) The lock device type is missing out because it’s not catching the proper zwaveEvent. (It only catches 6 (ZWAVE_ALARM_TYPE_ACCESS_CONTROL) and ignores 5 (ZWAVE_ALARM_TYPE_BURGLAR.)
I have a device type I’m playing with that catches those (and many more) but it’s not ready for public consumption yet. I’m still working on getting it to properly set several different configuration parameters, but there’s no elegant way to do it when you can’t send more than one message every 4 or 5 seconds!
Imagine this:
set alarm type to tamper. delay 5 sec. get alarm type (to verify it set). wait 5 sec. get alarm sensitivity (There’s a different sensitivity for each alarm type). wait 5 sec.
(I don’t think this is a ST issue - I think it’s the lock and possibly a side effect of how z-wave beaming works.)
Anyway, once I have it done I’ll make it available (freely, of course.)
(In theory, I guess, they could all piggy back on the “door” attribute, the same way that the “lock jammed” message does…)
Where does the lock jammed piggyback on door? It just updates the tile as an unknown status message from what I see.
oops. not “door”, but the “lock” attribute (from the “Lock” capability.) Here’s a snippet:
map = [ name: "lock", value: "unknown", descriptionText: "$device.displayName is jammed"So, a smartapp could subscribe to this device’s “lock” attribute in order to get a message about the lock being jammed. (This is how the shared smartapp called “Lock Jam Notifier” works.)
So, if that were used as a template for things, “is jammed” in the above snippet could be replaced with “is being tampered with” or “has had too many invalid code attempts.”
The point is that if you want to get the notifications for various alarms out of the device type code, I can’t think of any way other than using an existing capability’s attribute with a custom value and/or descriptionText.
So, for the tamper alarm mentioned earlier, perhaps create a map with name:“lock”, value:“unknown”, descriptionText:“$device.displayName has detected an attempt to tamper” or something similar. I haven’t tried it, but I have to wonder what would happen if the event was created with a different value. Perhaps value: “tamper”? (I wonder what would happen to the state tile in that case… or if the event would just be rejected completely.)
Is is possible to define a new attribute in a device type? If so, can those attributes be subscribed to from a smartapp? That might be a possible “solution”, but I haven’t gone that far. Right now, my device type just ensures the info shows in the activity log and that’s it. (create an event with only a descriptionText, displayed=true, isStateChange=true)
Gary
Actually, I just found that I can subscribe to a custom attribute. That’s really interesting (and can be useful.) Of course, a smartapp would have to verify that a device supports that custom attribute (and I don’t even want to think of the mess that would occur if two different types happened to use the same attribute name for very different purposes.)
Okay I’ve posted the completed device type up in my first post:
It supports enabling/configure the local alarm mode with relevant icons, configuring the alarm level sensitivity for the alarm modes, ability to capture the alarms through motion sensor events (that way the device can be used with standard apps and phrases). In future we will provide apps to natively interface with the device but this is more flexible. Also provides custom attributes to capture invalid user code attempts.
It’s hosted on the RBoy server so yes you’ll need to get access to it (gives access to this and all other apps) through our facebook page by making a one time contribution. This helps us to continue hosting, creating and maintaining/customizing these apps. Enjoy!
Well, at least it’s not a $15 “required” donation anymore and now just a $10 “required” donation. (and does it now require that you sign up for facebook? Some of us avoid that like the plague.)
Sorry, @RBoy, while I respect your work, I disagree with your methods. You are taking ST code which was shared openly and freely with you, enhancing it, and charging for the enhancements. Even those enhancements are (at least in part) made with knowledge freely shared with you. I know the amount of work that goes into the enhancements for the alarm types, alarm sensitivity values, and so on. I’ve been working on it (in extremely rare spare time) myself. It’s not much at all. Most of my time has been wasted trying to figure out the oddities of groovy and ST’s platform.
If people want to wait a few days, I’ll give them a device type doing the same things - but won’t charge (or “require a donation”) for it. I’m not doing it to “compete” with you. As I mentioned in another topic (or was it this topic?), I’ve already planned on sharing it freely (and will likely never charge for any ST type code.)
I honestly believe that “community development” will collapse if everyone starts trying to profit from it.
13 Likes
Absolute garyd9, we too contribute back and share a lot of apps freely on the community, however this is our full time job - creating apps for users. If you have requests please feel free to let us know and we’ll be happy to create new apps, fix bugs in existing ones or add new features. And as you pointed out it’s isn’t easy building apps for the ST platform, it takes a ton of time trying to figure this out. So yes we do depend on donations to keep us going.
And no you don’t need to sign up for facebook, just use the links there to make the contributions and get access to our servers and support.