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

Devices & Integrations
61

That’s absolutely right. This is exactly how Zigbee HA defines thermostat:

Mandatory Clusters:
    Thermostat
    
Optional Clusters:
    Scenes
    Groups
    Thermostat User Interface
    Fan Control
    Temperature Measurement
    Occupancy Sensing
    Relative Humidity Measurement

Z-Wave uses the same approach, only instead of cluster calls it command classes.

Technically, a lock is just a switch. It is either locked or unlocked; on or off.

Another case in point. Z-Wave, for example, defines Basic Command Class that all devices must implement. The meaning of this class is device-specific, but it allows sending On and Off commands to virtually any device.

Bottom line, I don’t see any value in trying to define yet another home-brew, half-baked capability nomenclature when one (or even more) already exist. Should SmartThing adhere to any of the existing standards, we wouldn’t be in this mess in the first place.

I does not matter! Both are just abstractions of physical objects and offer pretty good and consistent abstraction model. A thermostat is a thermostat, whether it’s Z-Wave, Zigbee or WiFi. Zigbee spec does a pretty good job defining all common home automation devices in terms what capabilities and attributes they provide.

1 Like
62

I’m having an “agree to disagree” feeling at this particular point of the Topic.

I think ZigBee & Z-Wave clusters (or whatever nomenclature) are not a bad starting point for SmartThings, but I think they are weaker than SmartThings can and needs to be.

In order to be HA protocol agnostic, I personally feel there is value in using a different model (ie, the OO Interface concept), which can accommodate the best of multiple incompatible, but similar, solutions, and pave the way for independent extension. TL;DR; SmartThings is not ZigBee and ST should not confuse the Community by copying its standards in respect to this Topic.

1 Like
63

Sure, if you have unlimited time and resources, you go ahead and design something better than Zigbee HA Profile and make a name for yourself in the industry. But if you don’t, you just take what’s already there, time-tested and proven to work. Chances are, it will take care of 95% of your needs. Then you just extend it to cover remaining 5%.

My point is, SmartThings as a whole is a patchwork of haphazardly written code held together with duct tape (also known as “agile s/w development”) :smile:
Whichever area you look at, be it a UI, app management, IDE, event handling, scheduling, everything needs refactoring. Do you really think they have resources to rewrite (actually re-architect) entire device management layer, which includes capabilities?

64

Nope, they don’t have the resources, even with lots of resources, it is an issue of focus; I totally agree with you on this point: Certainly in the short-term SmartThings has much more pressing priorities than any major re-architecting, which is why it is understandable that they lean towards the “flexible” side of things, rather than making things more strict and rigorous.

But I assert my recommendations are incremental inconsequential to the existing platform architecture:

(And, though those of us in the discussion may use different terminology and emphasize some components more than others, we have a lot of consensus here, I think!)

I’ll call this a summary; sure, it is a bit of a rehash of what I wrote earlier, but I am also including super appreciated comments made by other posters, and hoping @matthewnohr and/or @thegibertchan can let me know if what I’m proposing is indeed → NOT A PLATFORM CHANGE! (i.e., no rearchitecting, no-rewriting, and minimal, if any, refactoring…).

  1. SmartThings’s concept of Capabilities is a good thing, and has worked pretty well for hundreds of Device Types, SmartApps and Services. The existing Capabilities Taxonomy, however, has some “bad examples”, but we may have to live with them to avoid refactoring. New Capabilities should not consider all of the current ones to be useful examples!!!

  2. Hopefully the current use of ad-hoc additional attributes, commands, and arbitrary events in Device Types is not widespread, since it breaks the intention of the Capabilities concept. Device Types that have ad-hoc added characteristics will have some SmartApps use these characteristics, and those SmartApps will not be compatible with similar, but different, Device Types that would/should/could otherwise have the same Capability list.

    But, these “optional added attributes and commands” won’t break conforming SmartApps (i.e., apps that utilize only the standard attributes and commands defined by the Capabilities), unlike the other way around (i.e., if a Device Type is missing an attribute and/or command for a Capability, then that breaks the contract with all SmartApps & Services selecting devices of the Capability).

    I’m still unsure, but it is worth considering that a Capability itself could have such “optional attributes and commands”, and this could be implemented purely “by definition”. (Refer to Aaron and NB: SmartApps need to have some way of checking if individual Device Instances have these optional characteristics, but only if they want to use these extras): [quote=“AaronZON, post:39, topic:9917”]
    Would we also consider the same or similar approach for new attributes of existing capabilities? As has been noted, changing current attributes would break things - a bad thing - but I would think that we should consider a process to add new attributes to existing capabilities in a thoughtful way. Existing SmartApps that utilize existing attributes would not be broken but new SmartApps that wanted to leverage some new functionality made possible by a new attribute could do so.
    [/quote]

  3. It is not too late to make it mandatory that all Attributes and Commands of a standard official Capability must be implemented by any SmartDevice Type that claim that Capability. If there are existing SmartDevice Types that violate this, that refactoring can be done over time, using default value Attributes and stub Commands if necessary for expediency. This “mandatory” requirement can be enforced by the SmartDevice Type submission - certification - publication process. The compiler does not need to be modified.

  4. Capabilities should be granular to maximize flexibility; redundant attributes and methods from one Capability should not be included in another Capability. This can be done immediately without rearchitecting to add support for “combo-capabilities”; since the SmartDevice Type already accepts a list of Capabilities in the current platform. (Unfortunately, Jody’s which for a “device class” cannot be properly accommodated without changes to the platform; though the concept can be implemented solely through documentation – i.e., we can document various categories like “refrigerator” and document the default or mandatory list of Capabilities that device types in that category should contain, with optional additional capabilities permitted). [quote=“jody.albritton, post:59, topic:9917”]
    We also need device classes.
    In my smart app I could say “requires a device class of refrigerator and a capability coolSetPoint”
    [/quote]

Existing Capabilities that are obvious combo’s (e.g., capability.thermostat) could be phased out, but refactoring of both Device Types and SmartApps is required. Not urgent. Just try to avoid creating more of them.

BTW: There are many reasons to avoid redundancy and to optimize granularity:

  • If a Device Type supports “locked/unlocked & lock()/unlock()” then using capability.lock ensures that the “meaning” of those Attributes and Commands is consistent in all such Device Types. Theoretically, the “locked/unlocked & lock()/unlock()” of capability.lockCodes could have a different “meaning”. Just basic redundancy risk – I come from an SQL background … normalization is a good thing.
  • Pulling out “locked/unlocked & lock()/unlock()” from capability.lockCodes makes the definition of that Capability smaller (more granular), and thus easier to maintain and implement Device Types which properly conform to it. (Reference Gary D: [quote=“garyd9, post:40, topic:9917”] … 1. It is completely realistic to have a device that supports locking codes, but doesn’t actually support a lock mechanism. Perhaps it requires a code to turn on a switch instead, or a code to turn on an alarm system, etc. … [/quote] )

5. In order to avoid the problem areas of #2, SmartThings must implement an expedient but rigorous process to add new standard global Capabilities. If a new Capability can be swiftly added to the platform, then the need for ad-hoc Attributes and/or Commands is minimized or eliminated.

6. To conform to #4, New Capability Requests should be well-vetted – i.e., well named, well defined Attributes and Methods, optimal granularity: low to zero redundancy, etc… Again – no architecture or code changes required, just a management process; hopefully with time for Community input, and also mapping against major standards (Z-Wave, ZigBee) where applicable.

I close again with a disclaimer: This is a Forum post, a summary, a discussion: Not a formal proposed specification. I think there is enough detail here for readers and contributors to get the gist; but before adoption, a formal spec with a review and confirmation period is needed in order to clear up ambiguity and irrelevant tangents.

Thanks,
…CP / Terry.

65

@tgauchat,
Well… I think you have enough material for a book. :smiley:

But seriously, like @matthewnohr mentioned, they how have 12,000 custom device types on their hands. So I sincerely hope all these mandatory restrictions you’re proposing will never happen. :smile:

66

I absolutely share that concern, Geko: In my first post to @matthewnohr; I asked, essentially, how the heck did 12,000 Custom Device Types get created with the rather limited existing Capabilities list. I definitely still have that question on my mind, and the answer may shake my resolve regarding “mandatory” standards. Yet I can’t see SmartThings acheiving their hardware abstraction visions if they’ve perverted the concept of Capabilities used Capabilities inconsistently.

Things that make me go, hmmm… :confused:.

And, well, there is a difference between fixing legacy stuff and trying to do a better job “from now on”. Gary D is pretty optimistic in writing:

…CP / Terry.

67

Sure I can see 12k device types from a query such as: “select count(distinct name)” vs “select count(distinct capabilities list)”, I would predict the latter to be much smaller.

2 Likes
68

Real world experience. My suggestion was the only way (short of breaking changes) I’ve seen to fix legacy stuff. (There are others, but I’ve personally never seen them work out.)

I have to question that. If someone posts a “ge link light” device type on the community forum, and 2,000 users copy the code into the IDE, is that being called 1 device type or 2,000? If the latter, then it changes the meaning “12,000” dramatically.

How many of those 12,000 device types are just identical copies of each other? How many are functional copies with cosmetic differences (such as a simple edit to make the icon changeable?)

Gary

1 Like
69

I have the same trouble understanding that 12,000 number. I wish there was a published list of all the SmartDevice Types (even without any proprietary source code). I don’t think there is an API query … you can only query for the Types associated with your account.

The “Works With SmartThings” page only lists 108 Device Types. That is short by 11,892. :confused:

@Mike_Maxwell … Queries against the SmartDevice Type database would be fascinating: How about a count and list of distinct Attributes and distinct Commands along with the number of Device Types that use each? This information would help us understand the potential impact of any recommendations to the Capabilities model.

70

Old thread, but I’m struggling with this now. Why do we need 200 device handlers for thermostats when we could have 1 that requires certain capabilities and has optional capabilities that are enabled per instance as they are supported by the given device.

This thermostat has batteries that report back status, this one doesn’t. This one does Humidity measurement, this one doesn’t. They don’t need separate device handlers since everything else is the same, but my understanding is they do or you have to deal with the capabilities being exposed but not actually existing.

71

It’s a great idea, and in Object Oriented terminology it’s called “inheritance”.

In other words, the architectural concept has existed for decades; but it wasn’t implemented into the SmartThings platform. :cry:

72

I’m familiar with the concept from my college java days. I’d be good with preference variables or constructor options to enable or disable capabilities

1 Like