tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
10
CT?.. Color, Tint? Or am I guessing wrong?
This would just require an extension (i.e. A new Command signature) to Capability Color (which is technically a very tough thing to do because every Device Type that claims a Capability must implement all of its Attributes and Commands, so all existing Device Types would need to have conversion methods…).
The workable alternative is to add a new Capability with just this Command signature (and Attributes to read the current set values), and Device Types can decide whether or not to claim and implement it.
Please make the New Capability request in the Category on the Forum!
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
15
Good list, but I prefer colorTemperature to avoid ambiguous Attribute or parameter names even if they are in context.
But adding Attributes, Commands, or Command Signatures to an existing Capability is theoretically risky.
(and I discuss choice of Units for Color Temperature)…
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
16
I also consider Hex and RGB to be redundant, if they have the same resolution (0 to 255), since the units are equivalent, just a different number representation. #FFFFFFF = 255,255,255.
I am exploring the idea that each capability have its own dedicated documentation page/section, with all attributes and possible values, commands and their signatures.
Certified zigbee Light link device (ZLL). Standard clusters.
CT in lighting installations means “color temperature.” Cool white to warm white.
The hue API provides three options for setting color:
hue and saturation
xy in the CIE color space
ct the Mired Color temperature
If you would like to use RGB color in your app, you will need to translate to one of these color settings options. Our SDKs provide utility methods to do this or alternatively you can build your own. For more information on this refer to ‘Color gets more complicated’ in ‘Core Concepts’.
1 Like
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
20
Some Capabilities will have quite complex definitions, with lots of Attributes, etc.
I’d appreciate any feedback or personal discusson you have time for on my Draft Guidelines… I raise a few important questions there that suggest feature requests for the Platform, but without new features, we may need some redundant and overlapping Capabilities and this means extra documentation to explain why each overlap occurs, and the recommended Capability choices for example Device Types and their SmartApps.
I think only HSL is supported. Its strange, but CT to RGB is a decently hard problem (I could probably do it), but then you have to go RGB to HSL. I have not seen a CT to HSL implementation. Of course, the API can so CT directly which is what started the whole thing…
I’m not sure if you knew this – or maybe I’m wrong. But I think the Hue implementation on ST is incorrectly labeled HSL when its really HSB. I did not know there was a difference until I did a lot of research.
Do you know how to get a method implemented into the ST Hue class? I wrote the converter from CT to RGB to HSL. The ST class is either converting HSL then to HSB, or its converting it again to xy. I have to think its easier to just tweak the REST endpoints. Especially since color temperature is such an obvious use case…!
1 Like
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
24
I pulled the Device Type code from the IDE to paste here for reference… I’m trying to grasp the implications, since SmartThings doesn’t seem to be doing any significant conversion based on this code… right??
Biggest thing I see with the entire implementation is the following.
St is insisting the ST values are integers, and then they are thunked into the device as a 0 100% space for the controls.
And the color wheel isn’t capable of rendering the complete color set that the hues are.
Philips claims the REST call is done in HSB/HSV space – which is different than HSL. However, it seems that we’ve understand it to be HSL due to the way it was named in the tools.
It looks like setColor might support a Hex value. I didn’t know this but its good that it does.
The color adjustment might effectively be doing some conversion. I don’t know what that code is doing but I suspect the round trip would be way off.
I didn’t give much thought to editing the Hue (Connect) SmartApp before. I’ll probably have to do that and also fix the Bulb device. Here is the code inside the SmartApp if anyone is interested:
Hi all,
I have been working on Hue, mostly fixing discovery problems and other issues. I can bring some light to this thread. While not ideal this is how the integrations are working now.
color: hex value for the color. This value is being stored in an attribute but, right now, it doesn’t affect the setColor function.
Hope this helps!
Next week I push for standardization of how we control color bulbs and I definitely for a way of making this more intuitive both for users and developers.
I spent a bunch of time on this and iterated a few apps. I think it is pretty good. The colors seem pretty accurate on round trip but I did not test with a light meter – its a vast improvement from before. Thank you!