Is there a way for my SmartApp to determine if a bulb, I’m using Hue bulbs, is currently displaying white, set via colorTemperature, or a color, set via hue and saturation?
most probably you will need to check the DTH. In there you should be able to find the capability that will store the mode (white or RGB), then you can query the state of such device capability in the smartapp.
Beware, that RGBW bulbs (hue, osram, aeon, fibaro, etc…) usually dont have the same capabilities name.
1 Like
Thanks Rodrigo. I had a look at the DTH but unfortunately it doesn’t expose colormode. color (hue and saturation) and colorTemperature are both valid to set and get but colormode, although mentioned in the DTH parent is not a capability of the DTH.
I might just have to query recent event history looking to see if color or colorTemperature was used last. That would work, most of the time, otherwise default to either color or colorTemperature. Not ideal, but…
Thanks for the heads up on non-standard capability names. Crazy! How did SmartThings ever let this happen??? It just seems to be one thing after another. lol
The Capability paradigm of SmartThings (as a way to abstract Device Types to the SmartApps that use Device Instances… thus allowing one manufacturer/model of a Capability of Thing to be swapped with any other without breaking the SmartApp…) is brilliant.
Fact is, though, it is not particularly innovative. Abstractions (or the object oriented design concept of “interfaces”) is a well understood paradigm. For example, think about how easy it is to plug and play any model of mouse, keyboard, monitor, and even camera on a PC these days!
The problem is that SmartThings decided to allow Capabilities to be sloppy, and to put next week zero effort into expanding the list with a Community Developer review process. A major major pet peeve of mine. Heck, I created a whole Category on this Forum to draw attention to it, and… Failed.
https://community.smartthings.com/c/developers/new-capability-types
Capability “Color Control” is one of the worst.
If SmartThings doesn’t revamp Capabilities and put some strict rules in place for their use, the model will fail. It already is very inconsistent except for the most basic Capabilities.
I’ve just taken a look at a dozen or so bulb DTH on SmartThings GitHub and they all seem to consistently use capabilities Switch, Switch Level, Color Control and Color Temperature with commands on(), off(), setLevel(), setHue(), setSaturation() and setColorTemperature(). These are the ones that I am interested it so all looks good to me. Maybe things are not as bad as they once were???
1 Like
That’s pretty good, then.
The Capability spec for Color Control, though, also has the mysterious Command “setColor(color map)” and similar Attribute.
I think those are… Rendundant? Or critical?
I’m worried that redundant items may not be implemented in all DTHs, thus confusing SmartApps.
We’ve recently coded Color Control support into ActionTiles, and we have no idea what bulbs it will fail to work with.
Tagging @Sticks18
Yeah that’s not so good for you. I’ve keep away from setColor.
I do have a problem in that the bulb does not tell you what mode it is in, i.e. color or white (colorTemperature) so when you switch on a bulb you have no idea what it’s displaying. I have to look at currentState for the most recent use of color or colorTemperature to determine. I also found today a ‘bug’ when switching between color modes in that it does not raise an event when switching back to the previous color from white. i.e. select Purple, switch to warm white then switch back to Purple again. No hue or saturation events. Same happens in reverse too (white - color - back to same white (kelvin). This makes it difficult to sync lights because you have no idea the user has just switch back to the previous color from white (or previous white from color). We really need a colorMode event or the missing hue, saturation and colorTemperature events. Anyway, I degress.
Is there not some sort of certification process implemented by SmartThings and if not could they not implement one now so that future development meets a minimum standard?
1 Like
They’re still not good. The problem isn’t necessarily in the actual code because you’re correct that the consistency has gotten better (mostly because new DTH use an old one as a template); but there’s still issues with syncing colors across devices because of the conversion to device specific colors. The best form would probably be an x/y color space selection vs the hue/sat paradigm; but hue/sat is pretty common among the devices and easier to use in a 0-100 slider UI world.
That command and its corresponding color attribute (which is only a string, not a map AFAIK) do 2 things: 1) They allow for setting both hue and sat from one command. 2) They enable and control the ST UI for color picking. Unfortunately there really isn’t documentation on what parts of the map are required or optional. It’s pretty much up to the DTH to make it work for the individual device. I do know that when you select a color in the color picker UI in the app, it creates a map with color in the RGB hex format, which is used for the location of the dot in the picker as well as hue, sat and level values where level is always 100. You could simply have a setColor command that extracts the Hue and Sat values from the map and sends them to the corresponding hue() and sat() commands.
2 Likes
Yes, we do. That’s why I implemented colorMode in all of the ZigBee RGBW DTH that I’ve written. colorMode is an attribute in the ZigBee spec for exactly the reason you describe. I even suggested it be added to the RGBW ZigBee handlers, but was told that it didn’t fit the capability schema and/or UI. Partially due to backwards compatibility issues if they added it as a requirement now.
3 Likes
There definitely is a “certification process” (though it only applies to officially approved and published Devices Types; then they can be declared “Works With SmartThings™”. @Tyler can elaborate.
The problem?: If the specification (i.e., the Capability definition) is ambiguous, weak, or “flexible”, then certification is equally ambiguous, weak, and … worthless.
This is the impression I keep getting from SmartThings. They always seem to say “No”, but they do it with a nice big kind smile, and if they do say “Yes” well it won’t be available until tomorrow (which never comes). Maybe I’m being unfair?? SmartThings today does appear to be in much better shape than before. Cough!
And saying “it doesn’t fit the capability schema” assumes the schema is correct. Right?
I don’t think that’s very different from many online forums for services like ST, Hue, Harmony, etc… The people who show up here are overwhelmingly the tinkerers and advanced users, so our requests don’t always mesh with their product goals or may require complexity they aren’t ready to push onto the general user. That’s the big issue with supporting group and scene commands natively in either ZigBee or zwave, but I understand it. It does get frustrating over time though, especially when it’s harder to understand the reasons they give.
It does, and I haven’t seen them make any retro changes to capabilities, probably due to the backwards compatibility issue. 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.
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 ifx>=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.
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: