Capability urgentAlert

Devices & Integrations Capability Type Suggestions
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