Capability urgentAlert

For granularity perspective, a Device with Capability to transmit messages (alerts or otherwise) to external services, is not in the same set.

So command: alert( message ) is a different Capability, or even a global library method (like “push()”).

In other words; I think it already exists; but you can correct me or clarify your requirement:

Try reading it again. S-l-o-w-l-y.

OK… After reading slowly, I think you are creating a different Capability with at least one command (whereas the Capability of THIS Topic needs no commands).

Recommend spinoff to Capability.sendMessage or similar.

Your recommendation is duly noted, but it seems logical to me that capability.alert includes both the alert() command and the alert attribute. This is consistent with other action/state capabilities, since conceptually alerts can be both sent and received.

A Device of a particular Capability must implement all of its Attributes and Commands (Meta: yes, some way of defining optional attributes and commands would be nice, but off-Topic).

Sample device that can set the urgentAlert attribute is a lock which has tamper related alert.

That same Device Type is, more often than not, not a thing or service that has the ability to take a message from a SmartApp and transmit it directly to another person or phone, speaker, etc…

In other words, the Command sendMessage is not an integral part of THIS Capability and Topic, even if such messages may be alert-like in nature. A lock is not a pager or pushbullet service.

Please give an example of a specific existing Capability(s) that combine unrequired commands with required attributes. Those are improper.

Sorry I took so long to reply… @geko, please don’t take offense, but I disagree. The idea for this specific capability is

“This device has the capability to trigger urgent alerts.”

The capability would be added to devices that might generate “urgent” alarms/alerts that the user should be notified of (and which aren’t handled by some other mechanism already.) Some examples:

  • door lock detects a burglar.
  • window sensor detects tampering
  • garage door opener detects an infants skull being crushed by the door
  • smoke detector notices that your house is on fire and no one is home

While your idea is a good one, I think it would be a different capability.

(Please remember that I’m in the group of people that feels “capabilities should be as simple as possible - multiple capabilities should be combined for more functionality.”)

Take Care
Gary

1 Like

An alert is an event.

Raising an alert is a capability.

Reporting an alert is a capability.

Just because a device can raise an alert (e.g. a heat detector) doesn’t mean it can report an alert (e.g. a klaxon) and vice versa - hence two different capabilities, albeit dealing with the same underlying object.

To specify that the one capability incorporates both functions then renders us unable to determine whether a device can actually report an alert based upon its stated capabilities - it may only be able to raise an alert (and vice versa).

I would suggest renaming the capability to raiseAlert.

I support the capability incorporating multiple standardised alert levels (an attribute).

I support the capability incorporating an alert descriptor (string) attribute.

Whether a corresponding reportAlert capability is of value or not I’m still debating with myself. If it were to be defined it should probably accept as inputs all the standard output attributes of raiseAlert. Device implementations could ignore those which are irrelevant to it, e.g.

  • a klaxon ignores everything except level - safe turns off, higher
    levels cause increasingly raucous sounds;
  • a “traffic light” display sets lights according to alert level;
  • a PA system sounds an alert tone based on alert level then voice
    synthesis of the alert description and maybe repeats depending upon
    alert level, etc.).

The point of using the same attributes is to simplify how SmartApps route alerts from sources to sinks.

4 Likes

Terry, how would this be actually used in a device type? Assume I’m in the zwaveEvent() function, and realize that my smoke detector is sensing a massive fire. How can I create an event with multiple attributes?

[code]createEvent( name : alertMessage, value : “Ladybug, fly away, your house is on fire and your children are away.”, displayed : true )

// where to include the alert LEVEL?[/code]

Perhaps it’d be better to DROP the “alert” or “alertMessage” or “alertData” attribute, and instead ONLY have an “alertLevel” attribute. The event’s description text can be used for the actual alert message. Example:

createEvent (name : alertLevel, value : "critical", descriptionText : "Ladybug, fly away, your house is on fire and your children are away.", displayed : true )

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