Capabilities: Existing and Process to Add New. Note: Capabilities ~= Interfaces?: Capabilities MUST be very strictly defined and enforced (attributes / commands / events)?

Devices & Integrations
6

One currently “live” and confusing / inconsistent example in the Capabilities Taxonomy is “capability.lock” vs. “capability.lockCodes”.

I can’t quite understand why the latter needs to include the commands of the former: "lock()/unlock()"…

790×182 7.65 KB

Does this imply that Lock Codes should inherit Lock? At least in this case and in the SmartThings environment, that is unnecessary because a single Device Type can serve multiple capabilities (i.e., both Lock and Lock Codes.

  • Or is this an “error” in the the Lock Codes capability (or my understanding of it…): Specifically, is it possible and/or even common and likely to have SmartApps which use all the characteristics of Lock Codes except attribute: “lock” and methods commands: “lock()/unlock()”? Or is this NOT possible?

The answer to that bullet really determines if there is redundancy in this example, or not.

And this illustrates how important it is for Capabilities to be: