Continuing the discussion from How to add a new device “capability”?:
Hi guys… Great topic!
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
event types. (NB: For interfaces, I believe that only
getters/setters) are a part of the definition, so Capabilities have some extras, in my definition.
Every Device Type that implements a
capabilityMUST support all those
event typesand exactly ZERO more. (In my definition, I’m only wavering on
event types, BTW). That means we must not be able to add arbitrary
methods) to an existing
capability. This is like adding a “middle mouse button” to a “mouse”. It may be convenient, but now SmartApps start to be deployed which rely on this new functionality and regular old two-button mice are no longer guaranteed to be compatible. In a world where we have a legacy
capability.mouseand that was defined with various attributes such as
clickLeft; we cannot extend that capability, but must rather add a new capability …
capability.middleMouseButton. A bit messy, but this way we can clearly distinguish SmartApps that use and/or require the new functionality.
Regardless of #2, we should hesitate to create new Capabilities for at a few reasons:
- (a) It adds complexity to the overall ecosystem. Browsing the capability list shouldn’t take too long.
- (b) By trying to map to an existing capability, we maximize compatibility with existing SmartApps (and other external interfaces that properly assign Devices by capability).
- © Once you officially add a
capability, it is very difficult to ever get rid of it. Every single SmartApp that relies on that new
capabilitymust be refactored.
So – New capabilities are good, and new capabilities are bad.
NB: I would like to see better ways to handle 3(b) with some sort of polymorphism approach, such that capabilities can be dynamically assigned to Devices. For example, a Device that supports
open/close can be morphed or mutated into a Device that reports these as
on/off. The best existing example of this is the “
Virtual Open\Close” that uses the tilt angle (accelerometer) of a SmartSense Multi to report
open/close instead of the magnetic reed switch. Right now it is necessary to awkwardly override the Device Type using the IDE environment.
More details on THAT idea here:
…CP / Terry.