Capability urgentAlert

[tgauchat (ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)]

@pstuart

I’m struggling with why a tamper sensor is anything but an open/close capability?

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:

DRAFT: Guidelines for Capabilities (under construction...)

Continuing the discussion from About the New Capability Types category: Disclaimer: This should probably be written by an official SmartThings Architect (or authorized technical writer), but I’m outlining my understanding of what makes for “good” Capability Definitions. This is based on my analysis of the existing Capabilities Taxonomy, and the SmartApp Developer’s Guide (particularly the section on device selection via preferences { input() }, and, most importantly, the Anatomy of a Device Type (Device Type Developer’s Guide), partially extracted here: Capabilities are the interactions that a device allows. We have a reference document that lists all available capabilities. When you define a capability, you are stating that your device supports the given capability. Commands are …