Generic "capability.measurement"

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

@garyd9

One argument for having each one as it’s own is for multi-sensors. Currently, there’s no way for a given device to have multiple of the same capability. (can’t have two switches, two temp gauges, etc) So, if the measurement is made generic, then any device wouldn’t be able to measure more than one thing.

The second reason, and major ST limitation at this time, is the UI input filter can only be based on a single Capability (there is no “AND” operator). So if too granular used, you can no longer show the list of only Thermometers.

Ref my Guidelines topic and contributions there very welcome… (in fact, I need to add your first drawback that I quoted here!).

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 …