New Capabilities Docs

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

@StrykerSKS

A window “shade” would not have blades. Those would be window “blinds”, so really you need two different capabilities as they are two different things.

Thanks for your comments, Sean…

Because it takes so long to get new Capabilities (and, apparently, even longer to get them right…), and for several other very good reasons, I think it is reasonable to “overload” a Capability with some broadness.

If you want to read (and, please, please contribute to) my academic discussion on what should the scope and granularity of a Capability be, please reference this link:

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 …

---

TL;DR; … Since there is no Capability “Window Blinds”, and we’re not likely to get new capabilities for a very long time, I think it is reasonable to figure out how to have Attributes in a Capability that may not apply to all Device Types implementing it. i.e., Windows Blinds are a special type of Window Shade.