Capability embeddedAlert?
This isnāt actually a device capability, right? Itās an extension telling ST itself to do something different, whether itās a traffic priority class, a popup in the UI, a an extra notification option, or whatever. (How configurable that is by the end user is not yet clear.)
but the physical device itself does what it was manufactured to do, per its certification by an outside group (not ST). It doesnāt know itās doing whatever it is weāre calling this.
Itās ST which is making a decision to handle this notification differently. Not the device manufacturer, not the device.
So I would consider something along the lines of capability.STsystemAlert
At least that way coders coming in from other zwave or zigbee systems wonāt waste a lot of time trying to figure out what protocol capability this maps to.
Itās an ST-specific capability to activate ST-specific features.
Just a thoughtā¦
No.
This is a catchall for any Device that has extra self-diagnostic alerts (similar to Deviced Tamper Alert, or Low Battery Alert, but not covered by those ā if any), that are also not covered in the basic Capability Attributes of the device (on/off/unlocked, etc).
This has nothing to do with any special handling by SmartThings.
SmartThings decided to add some slightly special handling (a prominent Location level Dashboard SmartApp) for low Battery conditions; they could choose to do this for Tamper Alerts and this catchall as well; but it is not fundamental to itās definition.
How are you using ābasicā? (Zwave terminology or something else?)
Because every certified zwave device that provides these type of notifications already does so in a predefined way using predefined codes OR under manufacturer proprietary. But thereās not just a random group of OMG What is This? codes floating around the network.
āSecurityā devices are devices that use different Communication profiles. They affect message transfer itself. No matter which hub youāre using.
Also, I wasnāt under the impression that these were all āselfdiagnostic.ā But maybe I missed it.
Anyway, if the definition already exists in the zwave protocol, why obscure it with a new name and less informative values than the ones the manufacturer already supplies?
SmartThings is protocol agnostic (devices can be ZigBee, Z-Wave, Bluetooth, IP, or telepathic, in theory).
So all my discussions regarding Capability definitions are equally agnostic.
Certainly Z-Wave and ZigBeeās clusters, profiles, notification codes or whatever they call Attributes and Commands are worth referencing casually in the process of defining the agnostic SmartThings Capability. Imho. Agnostic is valuable.
If it helpsā¦ I think ācatchallā Capabilities should be avoided if a reasonably small number of more accurate Caps cover the expected requirements (tamper, battery, too many combination lock input retries, etc.).
@garyd9 can perhaps list some example messages that donāt fit certain specific Capability definitions?l
Catchall categories never work the way you think they will. As Iāve mentioned before, I prefer a multiprotocol platform to offer a superset of all the available options from the individual protocols, and gray out the ones not available for any given device.
But if you want to have ST itself do something different, then that would be something you might want to add to the list.
At this point Iām going to leave this discussion. If thereās something missing that would make you happy and ST is willing to give it to you, as long as it doesnāt take away from the standard behavior expected of a certified device, or slow down the network, Iām fine with it. 
I donāt understand whatās confusing about āurgentAlert.ā Iām not stuck on it, and I couldnāt care less what itās called - I just think the CAPABILITY needs to exist (by any name.)
capability.ReallyNeedToInformAHumanAlert
capability.IBrokeSmartThingsTShirt (sorry, @April, I couldnāt resist.)
capability.CriticalNotifications
capability.ImportantMessages
capability.WAFFailureWarning
ā¦whateverā¦ A rose by any other name is still a rose.
I will ask, Terry, that you let me edit my own thread title, however, if/when we decide on something.
1 Like
Not me. I have no such desire.
This Capability is requested by @garyd9.
Why???
I am lost as to why @JDroberts and you are in completely opposite worlds with respect to critical messages.
I canāt believe weāve stalemated.
opposition? My point is that the label on it is less important than the functionality. The ability for a device type to communicate a critical message is important. Iāve given several examples in the early posts of this thread.
What the capability is called is, as far as Iām concerned, a marketing thing. Is a switch really a switch? Or should it be called a toggle? Perhaps a binarylever? A relay? They are all the same thing and the label doesnāt matter. Hereās a name that conveys the intent:
capability.DeviceCanGenerateImportantMessagesThatShouldBeSentToTheUser
Personally, I donāt want to type all that. However, if it makes someone at ST happy so that the functionality is implemented, I wouldnāt object too much.
But that / this is exactly what @JDRoberts says is a bad thingā¦ And I think I agree with his statements:
OK, but the whole reason zwave changed their terminology from āalarmā to ānotificationā is because after several years of actual field deployment they found that one personās āurgentā is another personās ālog and review later.ā
You seem to be trying to predefine how certain physical device features should be prioritised by everyone. But to a landlord monitoring an empty vacation rental 250 miles away, a siren may be a much lower priority than a text message.
I donāt care what itās called, either. Just noting that if you use the same terminology as a widely accepted protocol to which ST has been certified, but use it in a different way, many new users may be unnecessarily confused.
My main objection just to be clear, is to theshould above.
āMy use case is not your use case.ā You have no idea when I want a human notified. Or how. (Strobe lights and sirens can set off seizures. Not everyone finds them valuable.)
The device capabilities indicate what features a device has. And perhaps how ST will handle certain priorities.
But āshouldā belongs to the smartapp coder or the end user. Not the platform. (Unless there is a legal or third party certification requirement, of course.)
But thatās just me, based on experience with big brand companies developing mass market products. And my personal design philosophy.
We can just agree to disagree on this one. Like I said, if ST gives you what you want and it doesnāt slow down the network, Iām fine.
edited to add if the notification capability is missing from ST, that should definitely be added. But from @pstuart 's comments, it seemed like you were asking for something different than that.
I strongly agree with this (ie, the Capability or Device Type should not mandate that a user be notified under any circumstances).
That doesnāt mean, however, that there are not some type of messages or attributes from devices to the platform that require an unusual special Capability definition. I donāt believe this should force any specific types of end-user notification, but a Capability makes it possible for a SmartApp to process and notify as desired.
But maybe I / we need to see more specific examples in order to confirm if this is a single catchall Capability, or if the examples are actually typical Z-Wave or ZigBee messages that suggest specific Capability properties.
1 Like
@JDRoberts, the idea here isnāt for the device type to force a message down a userās throat. Itās for a device type to have a mechanism to communicate urgent messages. For a moment, put aside āz-waveā and āzigbee.ā Iām trying to think outside of the protocolsā¦
(unrealistic) Example: A garage door detects that itās crushing a human skull while in the process of closing. The garage door informs the device type of this information. It getās a āDoesntExistā protocol message with a code for āskull crushing.ā How can the device type get this information to the user?
The normal answer is: With a smartapp! Hereās the thing. I agree. My point is: how should it communicate with the smartApp? Should it toss out an event with no named attribute and a descriptionText and force smartapp to parse the text of every single event to see if itās important? Thatās not very practical.
So, Iām suggesting that device types that might have some really important information should declare that they have the capability to announce urgent messages. (Again, donāt think about zigbee or z-wave hereā¦) That capability gives them an attribute to use for creating events that contain those important messages. Perhaps also a mechanism for assigning an urgency.
At this point, itās up to a smart app (though Iād prefer some kind of global smartapp similar to the one that alerts for low battery) to relay that information to the user.
Right now, today, thereās NO ESTABLISHED WAY to do this without using specific ācustomā attributes and such. Should each device type force the user to also install a custom smart app JUST for that device type to relay messages? Thatād be clumsy, donāt you think?
In some cases, when the deviceās primary purpose is to detect āurgentā situations (smoke detector comes to mind as an example), this capability would be redundant. However, thatās not what this is for. This is for the door lock that detects someone bashing the door with an axe. This is for the garage door opener that detects a small childās head is being crushed. This is for the completely unforeseen things (of which I gave some wild examples of above) that device types might know about and need a way to convey to the application layer.
1 Like
I like separating this from the specific protocols, as I said earlier. Thanks.
But at the same time, the reference protocols may suggest a solution. Is there a common ZigBee and/or Z-Wave cluster, code, attributes, message, whatever, for āblocked door closing alertā?
If so, then this is a specific Capability or possibly even just an Attribute for Capability Door.
Otherwise, we STILL ask, should we make it a discrete Capability or must we let it fall to this Topicās ācatchallā.
And catchalls are worth avoiding (unless we really want super / sub Capability types, which are not a feature of ST).
You know whatā¦ screw it. Iām tired of saying the same things over and over and over. Iām trying to make the platform BETTER. Iāve argued this over and over in 4 or 5 different threads. Once people actually read the posts, they tend to agree. @JDRoberts, if you havenāt done so, please read the first 25 or so posts in this thread - its almost exactly what Iāve regurgitated several times over in the later posts.
There are other threads as wellā¦ at least one or two where I gave a whole list of things where a device might need to convey a message that isnāt defined by existing capabilities.
One suggestion was to make a new capability for each possible scenario. Iām fine with that, but the fact is that getting new capabilities added isnāt easy. tamperAlert for tamper type message, skullcrushAlert for skull crushing, etc. Whatever.
THINK about the situations Iām talking aboutā¦ NOT in the context of zigbee or z-wave, but in the context of ST. If you think thereās a better way, PLEASE SHARE. However, donāt discount this idea without suggesting how it could be done better.
Give examples of how you think these should be handled when a DEVICE TYPE detects these (nevermind that some of these donāt exist todayā¦ weāre developing for tomorrow):
door lock detects someone kicking in the door.
door lock detects someone is disassembling the door
garage door opener detects a child being crushed
light switch detects an electrical short that can cause a fire
food blender detects infant fingers at the cutting blade
ā¦and so onā¦
I still think this feature already exists in any device smart enough to send the message in the first place. They donāt send a random text message. They send a particular value in a particular way. Then, yes, there has to be code to process that value and decide what to do about it.
So far, at least, SmartThings is an open platform but limited to specific third party protocols. I think thereās a reason for this limitation, one being that the whole network comes crashing to a halt if you arenāt using terse protocols.
US Garage doors do send some kind of āobstruction encounteredā code. The door sensor doesnāt know if itās a trash can or a person. It just stops, reverses, and sends a standard code.
And door locks donāt detect āan axe.ā They donāt know the difference between Freddy Kruger and Sears delivering a refrigerator. They just report a code indicating a forceful bump was detected.
If youāre writing a device handler, you need to know the values the device can receive and the strings it can send.
If youāre writing a smartapp, you then to decide what you want to do with those values. if you donāt know what those values mean in terms if device features, thereās a problem.
1 Like
Not that Iām aware of. The zwave ābarrier operatorā command class is lacking in accessible docs. Even if it wasnāt, however, do you really want to create a new capability for every single possible scenario of āSomething Bad Happenedā?
Lookā¦ right now (today) ST sucks at doing some really obvious things. I have a $200 door lock that detects when someone is kicking in the door, but it doesnāt matter because ST device types have no mechanism to communicate that information. John Doe user doesnāt want to have to install a custom device type and a custom smartapp just to get what should be common sense functionality.
So you completely skipped showing how the device type should handle the messages, whatever they might be. You are right, of course - they donāt send strings. They send codes. The device types exist to decode the codes. What then? Right now, my door lock detects a ākick alarm.ā It comes in as a burglar notification.
It also doesnāt matter, because we donāt have a common mechanism to pass that info from the device type to the user level code.
[quote=āJDRoberts, post:85, topic:11041ā]
If youāre writing a smartapp, you then to decide what you want to do with those values. if you donāt know what those values mean in terms if device features, thereās a problem.
[/quote]You knowā¦ this is why this thread has me so frustrated. People come in and say you should do this and do thatā¦ but they speak (type) in generic terms. HOW IS THE DEVICE TYPE SUPPOSED TO GET THE INFORMATION TO THE APP LAYER???
Once you answer that, do you REALLY expect that every single device type should have a custom smart app?
- Tamper alert
- Tamper alert
- Door closure safety alert (probably exists, due to typical installed safety beam and obstruction detection hardware)
- Electrical hazard alert.
- Ummmā¦ Blade soft tissue detection
In other wordsā¦ I obviously have a strong preference for specificity, rather than using a generic catchall.
But, realistically, 100% agree Capability āUnspecified Critical Device Alertā sure would be handy for when a specific doesnāt exist and which doesnāt justify pushing through an new specific Capability with limited uses.
1 Like