tgauchat
February 18, 2016, 11:06pm
10
Yup… it’s a challenge.
I don’t have to point you to the volumes I’ve written on the subject – part of the problem are the limitations of the implementation of the Capability ("interface) paradigm in SmartThings, such as only being able to specify a single Capability as an input() filter (i.e., no boolean logic).
Random example reference … discuss as you wish, private or public … super appreciated!
Continuing the discussion from How to add a new device “capability”? :
Hi guys… Great topic!
This is something I’ve brought up in discussion with @Ben ages ago, and with @Jim very recently.
My discussions with SmartThings (at great length) are tied to the fact that Capabilities are quite similar to the concept of OO Interfaces (Java and other strict object-oriented environments). Interfaces are a very powerful way to manage polymorphism and extensibility of classes and functionality.
Ummm… somewhat briefly…(?)
Capabilities (including all existing ones) must be thoroughly documented, particularly all attributes, commands, and event types. (NB: For interfaces, I believe that only methods (i.e., commands and getters/setters) are a part of the definition, so Capabilities have some extras…
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 …