(There’s actually a proposed solution in the latter half of this post - the first half is just describing a problem, and then trying to emphasize how serious it is.)
If it’s not obvious from my recent postings, I’m playing around with device type code. One issue I see over and over is that a device might experience a serious problem that a human being REALLY needs to be informed about, but there doesn’t seem to be any way for a device type to send a notification or alarm.
For example, let’s say you get this new wiz-bang auto-magic does everything ESP enabled door lock. This thing can detect if a burglar is even THINKING about breaking into your house!
So, you add it as a new z-wave device, see that ST can lock/unlock it, and you go off to work. Then, while you’re at work, a burglar just happens to come by and breaks into your house. ST doesn’t notify you. You come home to find that you’ve been robbed blind (but at least the burglar left behind the ST hub that didn’t tell you about the event.)
Here’s the sad thing: The door lock detects that the door was forced, and the device type code for the lock actually does get an alarm event. However, the device code has no way to cause a notification of any type to be sent to the user. The absolute best you can hope is that the device type code causes something to show up in the activity stream (but you can’t even assume that!)
So much for a “smart thing” in a “smart home.”
BTW, as an irony, if the battery in the door lock gets low, you’ll probably get a notification for that (assuming the default for the low battery option isn’t changed.)
The reason for all this is that device types have no way to push to anything except for the activity log or to smart apps. The devices do this by calling createEvent (or sendEvent) to send information out to “whoever is listening.” However, there doesn’t seem to be anything “listening” on a global scale for any kind of alarms!
THIS IS A MAJOR FLAW IN ANY SYSTEM THAT CLAIMS TO BE USABLE IN A SECURITY SYSTEM.
The same flaw exists for a door lock, a water sensor, etc.
A user could install a smartapp to listen for certain events and send notifications. However, in the case of the door lock being forced, there’s nothing specific to subscribe to. Here’s the event used when if the door lock is disassembled:
map = [ descriptionText: “$device.displayName front escutcheon removed”, isStateChange: true ]
No name or value. Just a description. With no attribute (name), how can this be subscribed to? Is the subscriber supposed to parse the description text for everything? Really?
Is the lock’s bolt jammed? That would be pretty important… here’s the event:
map = [ name: “lock”, value: “unknown”, descriptionText: “$device.displayName bolt is jammed” ]
At least there’s an attribute (lock), but the value is quite a bit less significant than the description!
The z-wave garage door code is just as bad… jammed, stuck, car drove though it, nuclear explosions… all send events that are generally ignored.
Okay, enough ranting about what’s broken. Now a proposed fix. @Ben , I’ve referenced you so that (hopefully) you can call this to the proper person’s attention. This isn’t a “we need another device” proposal. This is a MAJOR shortcoming of the ST product that should be addressed quickly (and should be fairly simple to address.)
The simple way would be to add a way for device types to send notifications to users. I somehow doubt that would be added. It just doesn’t “fit” with the existing system. Then again, it might be the easiest and quickest “solution.” Considering that everyone is probably working on v2, this might be the best we can hope for.
A more elegant solution would be to have the ST recognize a boolean attribute in the ‘Event’ class called “urgent”. If true, the event is of an urgent nature and should generate a notification REGARDLESS of any smartapps that may or may not be running. This would act in the same way as an event with a name of “battery” and a value of “1” (but with no time restrictions.) If this is used, then the above sample (with actually exists in the z-wave door lock code) would be changed to:
map = [ urgent: true, descriptionText: “$device.displayName front escutcheon removed”, isStateChange: true ]
When that event was sent, it would immediately generate a pushed notification to all ST mobile apps (for that account) with the text of “Front door front escutcheon removed!”
If either of these ideas (or any other) is implemented, the device code for z-wave garage doors and z-wave door locks should REALLY be updated to make use of the solution.