SmartThings Community

About the Capability Types Suggestions category

(Ben Edwards) #1

Please create a new topic for EACH new capability that is being requested so that we can have conversations for each. Conversation in this specific thread should only be a meta discussion.

With threads in other categories, people can go way off-topic and it’s no big deal. But for this category, let’s try staying on topic to get the most out of it. (eg. having feel free to flag more off-topic posts and have moderators delete or move them?)

1 Like

Capability videoStreaming
( co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #2

Can this include discussion about attributes and/or commands that could be added to existing Capabilities?

Though: That could be a can of worms, if Capabillites must be “strictly” implemented by Device Types (see:


I suppose in the meantime, it would be nice for the “observers” to consider if any of the suggested “New Capabilities” could or should be rolled-into existing Capabilities, and discuss the implications.

Random example of “add” suggestion: capability.switch … add command: toggle() (no parameters).


( co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #3

Existing Capabilities Reference:

(Unfortunately, I cannot paste a Table here, but this is a dynamic list anyway…).


(Jason Mok) #4

I missed out on the party just now. First of all, thanks for listening to the community.

Second, do we have a firm description of what capabilities in general is all about so developers understand what to request for.

Third, do we have any extra guidelines for naming conventions (just to satisfy my OCD) :wink:

1 Like

( co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #5

No… But I’m willing to suggest a definition and guidelines and let SmartThings adjust me…

I’d recommend my post below as background on why there is no simple answer.


DRAFT: Guidelines for Capabilities (under construction...)
(Aaron) #6

. . . second the motion. Yes, potentially a can of worms but maybe better than alternative ways of dealing with a particular need. If not here can/should we open a similar space for discussion of amendments to attributes/commands of a current capabilities?

1 Like

( co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #7

Any ideas on how to move a Topic from the “early” discussion phase into the “final design” phase?

My suggestion:

  1. If a Topic is stale (no new contributions, not counting off-Topic or obvious re-hashing) for x days, lock it and start a new Topic with a similar title, prefixed "FINAL REVIEW: <Capability Name>" that summarizes the specification based on some sort of fuzzy-consensus. The Topic “Capability Urgent Alert”, for example, has been stale, at this moment, for at least 3 days. I suppose 7 days is reasonable?

    Of course, if the Discussion consensus appears to conclude that the originally Proposed Capability is no longer valid (e.g., it has spun off into one or more other Capability Topics; or agreed that it is not required due to redundancy, or should be deferred until more example real-world devices exist…). then the “final review” can be an accelerated process to just confirm that situation.

  2. The fuzzy-consensus should be determined by some “Qualified Person”, and they would consult with: (a) the original poster, (b) the posters with the most likes and/or obvious significant contributions to the Topic, and © select available ST engineers or architects with a likely stake in the decision.

  3. The new Topic would be held open for a minimum of 7 days and a maximum of 30 days based on the activity and consensus level of relevant discussion. Discussion should be moderated to reduce off-Topic posts (spin-off new Capability Topics, please), and detect rehashing. Moderation should be conducted by the “Qualified Person” determined in #2.

  4. The “Qualified Person” (or delegate as necessary) writes the final specifications and documentation notes for the new Capability, and inserts it into the fastest possible release cycle.



Next Developer Call will be on 02/25/15
New Capabilities Docs
Capability Color Control "color" Attribute & Command ambiguous, incorrectly documented, and/or improperly used in DTHs
( co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #8

This Capabilities Types Suggestions category has gone very, very, stale…

@Ben very responsively created the “New Capability Types” Category on the Forum (now called “Capability Types Suggestions” in February 2015, but there has been less than a trivial amount of participation from SmartThings engineers. There are hundreds of user Views reported of the posts in this Category.

Meanwhile the official Capability Taxonomy has grown by only 2 or 3 items in the last year (well… somebody check more closely and let me know).

So … I can only conclude that:
(a) SmartThings believes that the Capability Taxonomy was created with all the items we will ever need, and considers the new “Suggestions” to be superfluous.

or (b) SmartThings has abandoned the maintenance of this quite clever, and even, brilliant portion of their fundamental architecture, in favor of the ease of use of ad hoc Attributes and Commands, even though the latter results in a hopelessly fractured device type library, filled with redundancies and inconsistencies. When appropriate new Capabilities are eventually introduced (if ever), dozens of Devices Types which used ad hoc Attributes will have to be manually updated to comply with each new definition; and also dozens of SmartApps which could have input() filters based on these new Capabilities.

and/or © SmartThings new architects have not been motivated to learn the full depth and power of the Capability Paradigm, and/or does not want to deal with the creative range of suggestions made in the Category (some of which are, IMHO, extremely relevant, and some have been submitted with good intentions but fall outside the design purpose of the paradigm).

Optimistically (or cynically?), I think SmartThings may be working on a major overhaul of the Capability Paradigm. This would not be atypical of SmartThings – i.e., instead of an incremental in-place fix (i.e., add a few new Capabilities even if they are not “perfect”), they are coming up with an entirely new model which introduces significantly more development effort and platform risk, not to mention the tremendous effort needed to rework existing Device Handler and SmartApp code.


Calling All Developers - An open proposal for cross application triggering
SmartTiles Dashboard 5.4.2 - July 13 (