Capability urgentAlert

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

Patrick, I’m getting frustrated because you don’t seem to understand what I’m describing. This is made obvious when you compare what I’m describing to capability.alarm or capability.indicator. However, no matter how many times I’ve tried to guide you along with what I’m intending, you seem to pull back to something different.

You keep saying that what I want already exists, but you’ve yet to show me a functional way how the existing UI/framework can allow a DEVICE TYPE to alert to an urgent condition without the use of a companion smartApp specific to that device type.

The “eventType == ALERT” that @duncan mentions is something I’ve already tried and doesn’t function. Being it’s undocumented, it’s reasonable to assume that it’s not supposed to function in that way.

By this logic, every single device type would need a special custom smartApp for each special function of that type. I don’t think that’s the intention of the framework. (I might be wrong, but I doubt it.)

[quote=“pstuart, post:37, topic:11041”]
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.
[/quote]Huh? How can a device TYPE subscribe to a capability.alarm? It can’t. This isn’t making any sense in the context that I’m presenting - which is (again) why I’m getting frustrated with your replies.

Unless… are you suggesting that the doorlock should claim it has the “alarm” capability? If so, I very much disagree with that. The door lock can’t reasonably implement any of the commands required by capability.alarm, and the alarm capability is designed for devices that have flashing likes and sounds… not for devices that might want to give a message to the user. IF this is what you’re saying, then a door lock might just as well claim it has a thermostat capability… or perhaps a television capability. It just doesn’t make sense.

Gary

1 Like

You can’t just arbitrarily assign a Capability to a Device Type if the physical device doesn’t have the behavior of the contract specified by the Capability.

If it is a Virtual Device, well… You can make up any contract you want.

Am I misunderstanding the “details” of your recommendation?

BINGO!

Exactly my concern.

1 Like

capability.BINGO ?

Oh, wait… maybe not. It’s not 20 characters.

Edit: BTW, Patrick, please don’t misinterpret my frustration with anything personal. It’s not. I respect what you do. I just feel like we’re talking about different things. Or, at least, we’re coming at the same thing from such radically different angles that we’re not understanding each other.

1 Like

I believe @pstuart post says if the device type includes a capability.notification that can be subscribed TO. Which most zwave doorlocks do these days. This is exactly the reason Zwave changed the terminology from “alarm” to “notification” in version 3.

Check the zwave conformation statement for the Schlage lock. It has both the capability.notification and the capability.antitheft because it is of the standard device class GENERIC_TYPE_ENTRY_CONTROL / SPECIFIC_TYPE_SECURE_KEYPAD_DOOR_LOCK

yes, the door lock does have that z-wave command class. It uses zwave alarm types for ZWAVE_ALARM_TYPE_ACCESS_CONTROL and ZWAVE_ALARM_TYPE_BURGLAR (and perhaps others)

However, there’s no such thing as a ST “capability.notification”, so I don’t understand the relationship.

This should work, but doesn’t…

/**
 *  PS Smart Alarm
 *
 *  Copyright 2015 Patrick Stuart
 *
 *  Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except
 *  in compliance with the License. You may obtain a copy of the License at:
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 *  Unless required by applicable law or agreed to in writing, software distributed under the License is distributed
 *  on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License
 *  for the specific language governing permissions and limitations under the License.
 *
 */
definition(
    name: "PS Smart Alarm",
    namespace: "ps",
    author: "Patrick Stuart",
    description: "Simple alarm",
    category: "My Apps",
    iconUrl: "https://s3.amazonaws.com/smartapp-icons/Convenience/Cat-Convenience.png",
    iconX2Url: "https://s3.amazonaws.com/smartapp-icons/Convenience/Cat-Convenience@2x.png",
    iconX3Url: "https://s3.amazonaws.com/smartapp-icons/Convenience/Cat-Convenience@2x.png")


preferences {
    section {
        input "alarms", "capability.alarm", title: "Which Alarm(s)", multiple: true, required: false
        }
}

def installed() {
    log.debug "Installed with settings: ${settings}"

    initialize()
}

def updated() {
    log.debug "Updated with settings: ${settings}"

    unsubscribe()
    initialize()
}

def initialize() {
    // TODO: subscribe to attributes, devices, locations, etc.
    subscribe(alarms, "alarm", alarm)
}

def alarm(evt) {
    //TODO: Do something
    log.debug "$evt.name: $evt.value"
}

If the devicetype had a capability.alarm, you should be able to get the event “siren” in the subscribe.

This isn’t working. Yet the “Smart Security” Sample SmartApp uses this exact code…

Not sure if it is a limitation of the virtual devicetype or a breakdown in the capabilities.alarm functionality.

Or maybe the IDE is just broken right now?

I don’t understand… that looks like a smartApp… not a device type.

Are you saying to subscribe to command? And the device type calls it’s own command?

Gary,

A SmartApp will do the notification. A devicetype would just need to add the capability.alarm.

I’m using the above code to suggest that ANY SmartApp subscribing to the the capability.alarm of ANY devicetype that uses that capability can do anything. Like a notification.

But, that code doesn’t even work, and it should. Not exactly sure why, but even with swapping out alarm with switch, it still fails to work, so the IDE might be having issues tonight.

I think you are missing the fundamental point that if a lock devicetype were written to use the capability.alarm and a smartapp was written to then subscribe to this device alarm state, then a notification could be sent.

EDIT: It appears the IDE is in fact having issues:

                Investigating - An issue has been 

discovered where developers cannot simulate virtual devices in the IDE.
We have identified the issue and are working to resolve it.

                  Feb 12, 11:31 EST