Capability urgentAlert

Devices & Integrations Capability Type Suggestions
89

No…

A single SmartApp is quite, and immediately, capable of subscribing to multiple Devices of multiple Capabilities if there is any desire to logically group these various different alerts in one place.

(Ideally, SmartThings will eventually offer some sort of inheritance or grouping of Capability Types or Attributes so that we get the best of both worlds… Granular specific alerts, and rolled up alert types. But this is irrelevant and unnecessary for the successful definition and implementation of this Topic.)

90

Terry, being that the argument this time is that we can do what we want with existing capabilities, and there currently isn’t any such smart app, nor are there any type of “alert” capabilities, it’s a moot point. At the rate that this thread is going, there never will be either.

Oh God, and here comes the inheritance thing again…

good night.

91

I read every post. And thought about them. From both an engineering and a coding standpoint.

Don’t overcomplicate it. Device records a measurable physical event that matches specific parameters and sends a simple code describing the physical event detected. Obstruction, temperature exceeded, movement detected, CO2 detected, etc.

If something special is needed it can be developed, like a glass break detector, but it’s usually the physics of the event that require a new device, and therefore a new device type. Not the context or intent or importance.

Devices don’t “know” a human has to be notified. Neither does the device type.

The device has to be able to detect a condition and send a standard code and value. That’s all built in by the manufacturer.

It’s the app that subscribes to those values that makes those decisions.

1 Like
92

I’m optimistic because of Capability Tamper Alert.

It seems to be a good specific case that is immediately usable. Even my cheap garage door tilt sensor sends this when the battery cover is removed.

I think Tamper Alert also covers your immediate needs related to the Lock Devices your are working on… Right???

93

Agreed :+1: … Very well said.

I think we are really close on this. I’m just sweating terminology, but it has the helpful side effect of stimulating discussions that clarify what we’re talking about.

94

@JDRoberts, there are no such alerts in ST. Bump detected doesn’t exist. Obstruction detected doesn’t exist. …and so on.

Oh, and just because certain things can’t be detected today, it doesn’t mean that it won’t be possible tomorrow.

Again I ask: how is the device type supposed to inform the app layer of these things? There is currently no common and feasible way.

BTW, I’d argue that the device type should interpret the codes to something meaningful, but the app layer should make the presentation decisions. (The same as battery notifications are handled today.)

(I think my phone’s auto correct creates more errors than it fixes )

95

Wrote a long complicated architectural answer, but since we all want to end up in the same place, with a stable multiple protocol platform that gives us access to all the networkable features of popular HA devices, I decided to stay brief.

I absolutely feel your pain about the missing functionality as it exists today. I think some of us are just hoping that the zwave and zigbee support will be expanded to give us full support for many more protocol features, which would solve a lot of the open issues from garage door openers to keypad locks to secondary controllers. I’m hoping that’s what “investment in certification” will mean, but who knows?

The ST staff are doing a great job tackling one device at a time, but I’m really hoping to see things addressed at the device class level and getting ahead of the curve.

Either way, though, I think we agree that the potential is there, it just needs to be actualized.

1 Like
96

My $0.02

Yes, we need a hook for subscribing to the various error/fault/warning/whatever states that devices can report, but which have little or nothing to do with their normal capabilities.

To borrow a word I’ve seen on an indicator light on an alarm system control panel:

capability.fault

attribute "fault", "string", // map of fault
attribute "level", "enum", ["info", "warning", "error", "critical" ]  // level of most critical fault

command "getSupportedFaultTypes"
command "clearFault", [ "string" ]    // set the fault in the State with this id to cleared = true
command "clearAllFaults"

with a faults returned as:

    [ type : "string", // what kind of fault (see getSupportedFaultTypes)
      level : "info|warning|error|critical",
      cleared : Boolean
      descriptionText : "words",
      timestamp : Date ]

Tamper, short circuit, jammed mechanism, etc. All the stuff that can go wrong, but isn’t part of the device’s intended use.

In addition to alarms and sensors (moisture, etc.) specifically intended to raise flags, have a notification smartapp subscribe to any/all of these capabilities, and then allow the user to configure what to do with different types and levels of faults on different devices.

If official capabilities are slow to arrive, we can always work with a draft specification (hey, how long was 802.11n just a draft?).

initialize() {
    devices.findAll({ it.supportedAttributes.contains { i -> i.name == "fault" } })
           .each(subscribe(it, "fault", faultHandler))
}

I mean, how hard could it be to get everyone to agree on a standard?

3 Likes
97

Laugh. Out. Loud! :smile:

1 Like
98

To answer your question, just read this thread. The biggest problem, as I see it right now, is that ST isn’t helping or guiding in any way. As far as I can tell, we’re just amusing ourselves debating about all of this.

It’s shame, really, because I can’t seriously recommend ST to anyone because of the large shortcomings right now and what appears to be complete apathy on the part of ST to fix them. :frowning:

I mean - really - this isn’t a trivial thing here. If a person buys a $200 door lock that alerts when someone is breaking in, they EXPECT the controller to pass that alert along to them. This is a door lock that ST claims as certified and even sells on their own website!

99

Is there a way to subscribe to all of a devices events, not just ones tied to an attribute? I can subscribe to a device without providing an attribute or callback function, but I get no indication as to what this does for me.

ST is far from ready for market. Until the device types are mature (so normal users never have to install device types) and it’s dead simple to install SmartApps (again, no IDE), it’s strictly a geek toy. If some initial time investment were made in some design and documentation of interfaces, they could be leveraging all the work people like us are putting into it. As it stands, it’s working a bit in the other direction for me. I find myself frustrated with the limited developer toolset and documentation, and how it results in a lot of wasted time. It’s like I’m being punished for my efforts. (OK, that’s hyperbole, but you get my meaning.)

To be fair, the initial standard for declaring something to be working is that the core device functionality is exposed, as described by the generic types it supports, which the lock type does support. The thing that I’d point out before fault-reporting events is the lack of a generic code-management app in the OOB experience. Sure, I’m having fun rolling my own, but I’m not representative of 99% of the market. This, of course, feeds back into leveraging the enthusiasts efforts by providing good tools and docs. Or not, as the case may be.

They’re understaffed and trying to staff up, at least recently, so it’ll probably be a little while until the train gets up to speed.

1 Like
100

I tried sending an event with a name that didn’t correspond to an attribute, but it did not show up in the list of States returned when querying the SmartDevice. I sent the same event, but with an eventType of “ALERT”, and the event did show up in the list of States. However, in neither case did it trigger a call to a handler subscribed to the non-attribute named in the event.

Which led me back to this.

Capability fault is too complex.

How about:

capability.alert

attribute alert, "string" // really an enum that varies per device

command "getSupportedAlerts"  // alert string for this device

That’s it. Simple string value and a command to give SmartApps the list of values that are usable when subscribing to a specific attribute value. No level, active/cleared, or any of that stuff. Just simple flags that are left for subscribers to prioritize.

Faults might still be worth looking at, but this one is stripped down enough that there’s a prayer they might slide it in.

1 Like
101

Or just notification, since that’s already in zwave.

102

The only problem I have with that is that I think the Notification command class in z-wave and the Alarms Cluster in zigbee should have their own (combined) capability that is focused on raising alarm conditions. Of course, that probably fits what the OP was going for better than the completely generic, maybe urgent, maybe not “alert” I posted above.

Perhaps the “alert” name better fits the Notification/Alarms role, and “notify”/“notification” the role of an urgency-not-implied capability that any device can claim.

I’m just throwing stuff out there, no pride invested. The only thing about which you’ll get violent disagreement from me is the subject of the need for capability.pants.

1 Like
103

I arrived at this thread because I’m updating a number of my device handlers (dimmers and relay devices) and I was hoping that by now there’d be a capability to represent the ability of a device to raise alerts/system-faults/notifications such as “Power surge”, “Load failure” etc.

In my eyes, these are one-off events that need to be reported to the user, have a level/severity, and perhaps also a “urgency” (being distinct from severity), and which would be acknowledged/cleared by the user. A “tamper” event might be another example, there’s plenty more examples in the Z-wave Notification Command Class definition.

After wading through this thread I was pleased to see some sensible solutions towards the end. I think @llamas proposal for capability.fault is 90% there, but could well be made more generic (i.e. capability.deviceAlert or capability.systemAlert perhps).

Obviously, capability.tamperAlert exists but is too specific, and doesn’t meet all requirements. capability.alarm and capability.notification are obviously not relevant, despite their overlapping semantics.

It’s two years on and we still don’t have an adequate solution for this scenario. @duncan, I know you are keen to avoid a generic alert capability, but I think it’s sorely needed. If we really can’t have it, can we at least have some more-specific capabilities like capability.electricalFault, capability.systemFault, or something?

More generally, as a community developer who’s spent considerable time developing a number of device handlers and SmartApps it really is massively frustrating how blasé SmartThings appear to be about Capabilities. Community developers are wasting huge amounts of time all re-inventing their own wheels to fill the gaps where SmartThings device capabilities haven’t kept up with the range of physical devices and properties that are now available.

2 Likes
104

Thanks for chiming in as we approach the 1 year anniversary of the last time this Topic was updated.

Actually… It’s pretty much exactly the 2 year anniversary of the start of the Topic. :cry: