Is bulb in 'color' or 'white', i.e. colorTemperature, mode?

[tgauchat (ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)]

@IvanR

And saying “it doesn’t fit the capability schema” assumes the schema is correct. Right?

The concept of Capabilities ain’t bad (actually, it’s great; but, as I mentioned, it’s not revolutionary).

The flaws?:

• The design isn’t comprehensive. It doesn’t have a good, standard, consistent way of handling “optional” Attributes and/or Commands, for example. (Ad hoc Attributes & Commands are not the same thing, and, in fact, have the same issue). Should a SmartApp safely with 100% confidence expect that a DTH claiming a certain Capability fully supports it; or should the platform provide a “failsafe” way for some or all Commands/Attributes to be optional and SmartApps easily handle these exceptions? For a simple but silly example, if a DTH claims “switchLevel”, then a “failsafe” DTH the claims this Capability even for non-dimmable bulbs, need simply ensure that if a SmartApp calls “setLevel(x)”, the bulb would do something predictable and deterministic (e.g., be off if x<50, on if x>=50). And/or, if the platform handled it, then the SmartApp would be returned a code saying “device doesn’t quite have this capability, so you may want to do something special, but don’t worry… I won’t crash you.”.

• The design doesn’t have well-defined data element definitions.
  Being loose on datatypes is par for the course of using Groovy; but what about units? Look at `Capability “Temperature Measurement”`` for example:

… WTF? "A number that usually represents the current temperature. Usually!!?!?!?!
… What about the units? Fahrenheit? Celsius? Kelvin?

• The Developer Documentation is the only available “specifications” for each Capability, and, well, to be honest, the documentation isn’t any help fixing the above two issues.

The above quote from the docs means that every DTH and SA developer has to risk using the Capability “wrong” and therefore their DTH and SA’s are subject to risk of failure at any time.

---

@Sticks18

The trouble with colorMode is that it really requires both color and colorTemperature capabilities to be useful, so which one should it belong to and how? I’m sure there’s a reasonable answer like add it to both, but it’d be wasted code for an RGB light or a Tunable White light.

You’ve expose the 4th trouble with Capabilities: No standard for granularity.
In the current implementation, the only correct answer to “colorMode” is to add it as an entirely new and distinct Capability. That way “good” DTHs can add it (and SA’s can query the DTH to see if it claims this Capability, and if so, should (try) to make use of it).

This Topic is over 611 days old… and I doubt anyone wants to tackle it:

@tgauchat

Scope (Granularity)

– ed: which term is best … or both?
Each Capability should contain an “appropriate” set of Attributes and/or Commands.

At this time, it is difficult to know the optimal number of these characteristics; so let’s just consider the factors involved in making the decision, and looking at examples with pros and cons.