Capability urgentAlert

So this isn’t really about a device Capability of an Alert (which you want a device to send)
but more about a global alert system. Different from the messaging system?

I am confused as why the send sms, send notification, send email (not implemented yet) aren’t good enough notifications of alerts?

So in other words, the app should do something else then show a notification that a message?

It seems to me, this functionality can easily be written into any SmartApp or DeviceType by using the built in sendXXX functions.

However, I can see a use case, where in the UI of the apps, there is a separate priority alerts section, where you can clear alarms, etc. Instead of the “Hello, Home” section.

This alerts area, thus allows history, tracking and most importantly visual notification of an alert and ability to silence, accept or act on an alert.

Then, devices can also use the alerts area to trigger events, subscribe, etc.

Does this make sense?

1 Like

device types are unable to use the sendXXXX functions.

The purpose of the capability would be to give device types a common capability that would alert some global smartapp (similar to the one that checks for battery events) that there’s an urgent message from a device type.

But smartapps can spawn devicetypes, so the child device can trigger an alert within the parent smartapp.

So, you want a device, like a door lock, that only some have an alert command. Automatically added via the pairing process, send an alert to some sort of behind the scenes global smartApp for alerts?

Why not just do this in a published smartApps called Smart Alerts and let the end use configure up the alert actions and which devices they want and the actions?

A door lock tamper is just a contact sensor, open or close, on or off.

I just don’t get the need to have some behind the scenes automatic alert app that I can’t control.

An Alerts section, separate from Hello Home, would allow security system like functionality and priority over all other notifications (outside OS limitations).

Patrick, I think you might be confused as to what we’re asking for.

Consider this:

John Doe see’s that the Schlage “Touchscreen” deadbolt is a ST support device. They install and pair it. It uses whatever device type ST detects for the device.

3 days later, a burglar breaks into their home. The deadbolt actually detected the break-in attempt. It sent a z-wave message to the ST device type. However, the device type has no way to get the information to the user. The BEST that a device type can do is cause something to show up in the activity stream (which I don’t think any non-geeks look at.)

What we’re asking for is a new capability that, when added to a device type, says that the device is capable of generating urgent messages. It provides an common event (attribute) for those messages.

Then ST also has a built-in smartApp (similar to the one that reacts to low battery events which are part of the “battery” capability) that reacts to the events from this new capability. It would, based on user configuration, alert the user via an SMS or push notification (or some other mechanism - or the user might decide to filter based on alert level, or just turn them off completely.)

This isn’t a child device type… it’s a normally installed one.

BTW, even if done with an “alerts” section, it STILL would require a common capability. In order to choose which devices can cause push notifications, you need a capability. In order for the smartapp to trigger on the event, you need an attribute.

Finally, I’m not suggesting how the “alerts” section (or battery alerts, or hub not connected alerts) should be presented to the user. The purpose of this capability is to allow device types to declare that they can and might generate the alerts. However, they won’t (and shouldn’t) be responsible for actually presenting them to the user. That should be the job of a smartApp (though I think the smartApp should be a global built-in one similar to the battery alerts.)

I’m only suggesting the capability and how its handled at the device type level. Anything in my messages beyond that is only speculation on how the information provided via the capability might be used.

1 Like

But if the device properly implements a deadbolt with a forced entry detection or motion or whatever, the zigbee or zwave device is just going to be a contact sensor, etc.

Why have a separate alarm or alert event at the device level? Should my motion sensor automatically alert me of motion?

I understand the need to be simple and alert a user, but the use case you described in just a case of the end user not setting up their system?

How is this any different then say the cold weather smartApp? Just cause I installed a temp sensor, the system shouldn’t AUTOMATICALLY alert me the temp is too hot or cold.

The end user should subscribe to the event, open/close, hot/cold threshold, etc. and then set up the notifications they want to use.

Just my two cents. I’m struggling with why a tamper sensor is anything but an open/close capability?

1 Like

Because the preferences input capability filter is “broken”… It is insufficient. It cannot filter on boolean expressions or even just AND.

Contact sensors and Tamper sensors may both be binary state sensors with no Commands, but from a UI perspective, they don’t usually belong in the same selection list.

So you are quite correct, Patrick… Capabilities are convoluted due to a major architecture flaw.

Ref:

It’s for dealing with exceptions, not for common cases. It’s also for more than just binary cases. There are 4-5 different “alarms” from a schlage door lock device type. (From tamper alarms to lock jams.) In some cases, perhaps an existing capability COULD be used. However, the use of a capability should also match the intent. Otherwise, things start showing up in strange places. (For example, my garage door shows up as a light I can turn on/off because it has capability.switch.)

No, but your motion sensor might want a separate alert for tampering. You used a contact sensor above… some contact sensors ALSO have tamper notifications.

Keep in mind that capabilities in ST seem to have multiple purposes. They have attributes (events) and commands - but they ALSO are used to describe the device.

We have “battery” and “energy.” Both seem similar. However, the device with a “battery” capability is saying that it has a limited life battery that powers the device. A device with “energy” is (I’m guessing) something that measures an external energy.

We have “contactSensor”. Using your arguments, door/windows sensors should just use “switch”, as they can convey their information with on/off states. However, while both capabilities are binary, they represent different things.

The idea of “capability.urgentAlert” provides:

  1. Allows a device to claim the ability to generate important messages.
  2. Provides the capability that can be used by smartApps to list only devices that might generate important messages.
  3. Provides an attribute (event) that device types can use to broadcast important textual information.
  4. Provides an attribute (event) that smartApps (built in or otherwise) can react to in order to “handle” an important message. The handler might be to filter it out, or push a notification, or something else. (The handling isn’t defined here.)

In this case, I disagree that the reason is due to a broken capability filter. I’ve started to believe that while capabilities should be as simple as required to advertise a SINGLE capability, a capability should also be descriptive in what it is. All of the following capabilities (that exist in ST) are all numeric values (I think), but are NOT the same and shouldn’t share a generic “numericValue” capability:

capability.illuminanceMeasurement
capability.battery
capability.energyMeter
capability.powerMeter
capability.temperatureMeasurement

Why should they be different? Because they each mean something different. They are used by smartApps in unique ways. Capabilities are MORE than just basic types. They are saying “this is something that the device is capable of”

You’re right.

The “broken capability filter” is a different issue that would allow some implied inheritance of capabilities, but it isn’t the be-all and end-all of why capabilities should be descriptive and should not share the same Attributes with generic meaning.

It is polymorphic; but ST isn’t giving the ability to create Classes, so we have to compromise with redundancy (i.e., 5 or more “Measurement” Capabilities, that, if inheritance and polymorphism was available, could have a common ancestor, which has various OO benefits). Without the “common ancestor”, the Platform isn’t as easy to manage, but it will do for now.

First of all, back to my point of UI, where in the UI is any message more important than another? How would just a capability solve this issue? There is no UI/UX for important messages / alerts. This is the issue.

Again, no functionality for important messages vs another message.

Again a UI issue. No method to broadcast important info vs regular info.

Again, this is the crux of the issue. You can add this capability, redundant or not, but the real issue is the UI/UX has no method to distinguish an important message from a normal message.

Adding this capability doesn’t solve the issue of alerting the end user. If we had a surface to notify the user of an alert or important message vs a regular message, then this capability (or lack thereof) could be worked around or implemented.

Without the UI, it will not result in anything different then what is working today.

If It works like the battery alerts work, it won’t be very useful. I have never even seen a battery alert.

Ummm… With the Capability added, a SINGLE and rather trivial event subscription SmartApp can be installed by the user to select the Devices that have this Capability and set the desired method(s) to receive the notification (push, SMS, siren, light flash, Sonus, or, eventually, perhaps, a special notification panel in the mobile App similar to push() …).

That’s the UI.

Again… I’m not trying to “solve the issue of alerting the end user.”

I’m trying to solve the issue of device code having no mechanism to create an important message that other code can then react to in order to alert the end user. I recognize and mentioned that there would have to be something else (a smartapp - preferably a global built-in one) that would handle the events and deal with them.

Part of the discussion of this thread was to work out how the urgency of a message could be relayed to the application/UI layer. We were discussing that. Obviously, no matter what mechanism we provide for that, it can be abused by device types (just as a smart app could abuse the sendXXXX functions.)

This is a suggestion for a capability type in a “new capability types” section of the forum. Once we get the type, we can pursue how the information is relayed to the user, filtered, etc.

1 Like

So how is this then any different then the existing capability.alarm? or capability.indicator?

How would capability.alert be any different?

capabiltiy.alarm is limited to values of only “strobe”, “siren”, “off”, “both” – and is used to advertise the ability of sounding and/or showing an audio and/or visible alarm. capability.alarm is the capability of flashing lights and making noise. A device with “capability.alarm” is a device used to get someone’s attention. Typically, it does nothing on it’s own and is triggered by commands.

capability.indicator is limited to values of “when on”, “never”, “when off” – and is used for a physical indicator. (It’s used for the little indicator LED’s on switches and dimmers.)

Comparing capability.alarm or capability.indicator to what I’m suggesting is like comparing a person walking to a skyscraper. (I’d say apples and oranges, but those two are at least both fruit.)

1 Like

And maybe it can make coffee for the first responders while it’s at it. :wink: (engineer joke)

Seriously, though…

The capabilities of a device are what that physical device can do as delivered by the manufacturer. One fairly stupid device.

a communication standard like zigbee or zwave is what allows a pretty smart coordinator, like the ST hub, to tell a known pretty stupid device to use the built in capabilities it has, usually in messages of 2 bytes or less. Or to receive a report from the pretty stupid device about what it did.

Like @chuckles and @pstuart said above, the klaxon won’t necessarily have a report capability. That’s important to know.

PRINTER DRIVERS

Java runs on the ST hub or in the ST cloud. In any case, someplace pretty smart. Zigbee and zwave are what happen on the other side of a Java interface. Basically like a printer driver. The interface part of an OO model is more like the word processing program. Two different things, both necessary to actually get a page to print.

You can’t print in color on a black and white printer, no matter how much code you write.

SO WHICH DEVICES ARE ABOUT THE SAME PHYSICALLY?

The question is always which physical devices should use the same device type. Are a black and white printer and a color printer the same sort of physical thing, just with a some features icon or off? Possibly. Maybe even probably.

Are a klaxon siren with no reporting function and an SMS messaging system the same sort of physical thing? Not a chance. To a human, they serve some of the same purposes. But to a communications protocol, or a network engineer, they’re totally different.

Device type is about what the physical device can do when delivered by the manufacturer. Not about what purpose you intend it to serve.

PURPOSE IS FOR PEOPLE.

A printer driver can control a device used to print a sign that says: “WARNING:ELEVATOR OUT OF ORDER.” Does that mean a printer should be put into an Alert device type?

The english word “Alarm” might be a mode, available to other apps. It might be a scene, that causes many things to happen at about the same time. It might be a smartapp that changes mode and does a bunch of other things, including trigger a klaxon and send an SMS message. That’s terminology, and you can decide how rigorously you want to control the terminology used in the ST ecosystem.

But device type capabilities should model the manufacturer-delivered abilities of a set of pretty similar physical devices, because they represent the printer driver. They should have map well to existing communication network protocols. They should associate device models that have similar energy draw and routing table functionality.

THINGS THAT MATTER INSIDE THE BLACK BOX

There’s a very important reason why zwave separates static controllers and handhelds, and it’s all about the routing table. To a human, their purpose is the same. But to the communication network, the difference is really important. It’s similar to the reasons why a printer driver doesn’t include display screen options. Monitors are a separate device type because of differences in the physical devices, not their purpose.

The communication protocols allow for sending a code. And we want that code to be as tiny as possible (small packets sent over short distances to/from low power devices).

Look at the conformance statement for the Schlage lock:

It supports the battery reporting code. Since it’s also a lock, it supports the “anti theft” reporting code.

Now look at the Philip flood sensor. It supports the battery reporting code, but NOT anti theft.

Why not? Because unlike a software design philosophy, as engineers we want each device to support the FEWEST possible features to meet the use case. Lower the power draw, lower the memory requirements.

I guarantee you you will only find an anti theft code supported in a device that supports beaming. Because if the sensor is asleep for 10 minutes, there’s not much point in the anti theft alert. Plus the device itself doesn’t have the physical security features of a lock. But beaming adds expense from about 5 different angles.

WHAT YOU CAN SOLVE WITH SOFTWARE

So device types are printer drivers. (Technically, the UI to the printer driver.) And communication network protocols for home automation think 3 bytes is verbose. And we intentionally keep the end devices pretty stupid and limited in features to keep power draw and costs down.

Don’t overload a device type with features not frequently supported. A door lock is not an on off switch. It has a bunch of built in security features plus a requirement for instant on. (Hence beaming.) but if a switch is smart enough to know all the things it CAN’T Do, I’m paying for intelligence I don’t need.

And don’t send messages any longer than needed. Quite often a new device type is added just to drop a few bytes from the packets. ZLL distinguishes color scenes from no color scenes just so they don’t have to have white bulbs processing parameters that are meaningless to them.

Put the smarts into the code run by the smart machine. Not the driver for the not very smart device.v

1 Like

I hope adding more analogies doesn’t sidetrack the Topic, but this first major Capability addition seems to be stimulating conversation. I do cover some of this in my Guidelines Topic in this Category, and will be adding more.


And most of what I just wrote below was just better stated by JD as I was writing.
Ref:

So … I used “mouse” (mouse drivers that implement the interface/capability “mouse”) as my analogy, whereas JD used “printer drivers”. Same intention, same message.
Thanks, @JDRoberts!!!


  1. Capabilities should (really, must) be the only way a SmartApp (or external application) can access a physical device for input and/or output. The Device Type handler “implements” the interface to the Capabilities, but should not expose anything that is not defined in the Capability.

  2. The interface model is common to all HAL (hardware abstraction layer) architectures. On a PC, a “mouse” is an interface with certain capabilities. The applications which use a mouse don’t care what brand it is, or even if it is a trackball or some other weird implementation of mouse. The applications just know it has buttons and motion and perhaps a scroll-wheel.

  3. There is no direct relationship between a mouse and the application. The mouse and the Pointer (cursor) are not a part of the same interface: They are, in fact, two distinct interfaces. The pointer, however, is a very useful interface that responds to applications that use the mouse, though other non-mouse applications can access it’s interface and move it around, change its appearance, etc.

  4. Capability.alarm is like the pointer – it is a display (output) capability (as is capability.indicator).

  5. Capability.urgentAlert is like a mouse – it is an input capability (as is capability.contactSensor).

  6. Some Capabilities are input and output (Capability.switch is an “output” capability when you use Commands to turn the switch on/off; it is an “input” capability when it reports its current state (or state change) as on/off, and that state change could be initiated from a Command or from a physical action (pressing the button or wall switch or another remote).

There actually already is a poorly documented thing called an eventType which has an option ALERT. If you send an event with eventType:"ALERT" it should pop up an alert in the app. (I think the app has to be running, and I’m not sure how well this is working.) So maybe we could use that or something similar to mark an event as urgent.

Another thing to consider: the Battery notification system does spam protection, where it won’t give you every 5% battery alert that a device sends to prevent an avalanche of push notifications. An urgentAlert capability could have similar problems.

1 Like

I’ve seen this (used in security key exchange failures), and tried to take advantage of it. However, it doesn’t seem to do anything - app running or not. (see smartthings/Z-Wave Schlage Touchscreen Lock.groovy at master · garyd9/smartthings · GitHub)

[quote=“duncan, post:34, topic:11041”]
Another thing to consider: the Battery notification system does spam protection, where it won’t give you every 5% battery alert that a device sends to prevent an avalanche of push notifications. An urgentAlert capability could have similar problems.
[/quote]Agreed. We were discussing the idea of different levels of alerts. Of course, as with the battery messages, it’d be up to the smartApp to control what is and what isn’t relayed to the user. If there was a “critical” level, I’d hope that they’d be sent through. (So, a “critical” level alert might be treated like a “0” value battery.)

It’s something that a device type could abuse. Perhaps the smartApp would have a mechanism to only allow “critical” level urgent alerts if the device type was “certified” by ST? (Which, of course, would mean that some type of certification system was in place, and that device types meeting that certification were somehow known to smart apps, etc.)

1 Like

I hope you mean just automatically installing / attaching a SmartApp that can be easily disabled by the user.

As the user I should have full and higconthighly granular over any and all notifications.

1 Like

So if I can write a devicetype that has the capability of alarm (existing) for several alarm type conditions, ie, tamper, forced, etc. Wire up the zigbee or zwave command for alert to these alarm conditions.

Then write a smartapp to subscribe to said device alarm capabilities and then notify the user, how is this not exactly what you want accomplished?

All of this can be done in the existing UI and framework.

Can we try to keep this civil. I’m trying to point out that existing resources exist to accomplish this task. Besides, I have no idea what a person walking to a skyscraper compares to something else. I’m sure you meant person walking compared to a skyscraper…

The requirement goes beyond capabilities, and is more of a parsing of a higher level of alert then standard messaging.

This would be exactly that, and could be then used in a simple smartapp subscribing to any device with capability.alarm (or more than one alarm if the devicetype specs it out)

A better UI for alerts/alarms would be ideal. But I still go back to the original post.

This is already acomplished by a custom smartapp. At point is overriding a user desire similar to battery to allow a device to send an alert without user permission. This is dangerous and outside the common usage patterns for ST.

In fact, you specifically called for this here:

The devicetype does, if it has a capability.alarm to subscribe to and the end user installs the “SmartAlarm” smartapp to notify them or alert them.

In fact capability.alarm is far more robust then what you propose because it has multiple states that can be wired to do different things based on the devicetype coding.

1 Like