Getting Philips Hue Values

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!

I believe u can send a hex color and level instead of hue and saturation.
setcolor([hex: #00FF00, level: 50])

Is this supported by all Capability Color Device Types or only Hue… Or is Hue the only such Device?

Documentation update needed?

ie… All Command method “signatures” should be listed in the Capability Taxonomy…, @Jim

I don’t have any hues. He can test to see if it works.

As for the signatures, I suggest that we add the items below. What do you think Pup?

Hex,
HSL,
HST,
ColorName,
RGB,
RGBW,
Temperature,

My guess CT is color and temp?

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)…

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.

And code examples, of course.

I think what we currently have is… lacking.

3 Likes

@Kristopher,

Did you try Hex and Level?

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

Thanks for exploring that idea, @Jim!

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…

@Kristopher,

I have some conversions in an RGBW light strip device type. Don;t mind the mess it’s in as it is pre-release. Maybe something in there you can use.

2 Likes

Thanks Twack

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.


http://colorizer.org/

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

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??

def nextLevel() {
	def level = device.latestValue("level") as Integer ?: 0
	if (level < 100) {
		level = Math.min(25 * (Math.round(level / 25) + 1), 100) as Integer
	}
	else {
		level = 25
	}
	setLevel(level)
}

def setLevel(percent) {
	log.debug "Executing 'setLevel'"
	parent.setLevel(this, percent)
	sendEvent(name: "level", value: percent)
}

def setSaturation(percent) {
	log.debug "Executing 'setSaturation'"
	parent.setSaturation(this, percent)
	sendEvent(name: "saturation", value: percent)
}

def setHue(percent) {
	log.debug "Executing 'setHue'"
	parent.setHue(this, percent)
	sendEvent(name: "hue", value: percent)
}

def setColor(value) {
	log.debug "setColor: ${value}"
	parent.setColor(this, value)

	// TODO: convert hue and saturation to hex and just send a color event
	if (value.hue) {
		sendEvent(name: "hue", value: value.hue)
	}
	if (value.saturation) {
		sendEvent(name: "saturation", value: value.saturation)
	}
	if (value.hex) {
		sendEvent(name: "color", value: value.hex)
	}

	if (value.level) {
		sendEvent(name: "level", value: value.level)
	}
	if (value.switch) {
		sendEvent(name: "switch", value: value.switch)
	}
}

def setAdjustedColor(value) {
	log.debug "setAdjustedColor: ${value}"
	def adjusted = value + [:]
	adjusted.hue = adjustOutgoingHue(value.hue)
	adjusted.level = null // needed because color picker always sends 100
	setColor(adjusted)
}

def adjustOutgoingHue(percent) {
	def adjusted = percent
	if (percent > 31) {
		if (percent < 63.0) {
			adjusted = percent + (7 * (percent -30 ) / 32)
		}
		else if (percent < 73.0) {
			adjusted = 69 + (5 * (percent - 62) / 10)
		}
		else {
			adjusted = percent + (2 * (100 - percent) / 28)
		}
	}
	log.info "percent: $percent, adjusted: $adjusted"
	adjusted
}

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.

3 Likes

Yeah a couple things…

  1. 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.

  2. It looks like setColor might support a Hex value. I didn’t know this but its good that it does.

  3. 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.

  4. 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:

    def hex = colorUtil.hslToHex(23, 56)
    sendEvent(d.deviceNetworkId, [name: “color”, value: hex])

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.

setColor(hue: 100, saturation: 100, level: 100, switch: “on”, color: “#ffffff”)

level: dimming percentage.

saturation and hue: considering that this was originally coming from a slider the values are 0…99. The final value is the result of this formula:

def hue = Math.min(Math.round(color.hue * 65535 / 100), 65535)
def sat = Math.min(Math.round(color.saturation * 255 / 100), 255)

switch: “on” or “off”.

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.

3 Likes

Hey Juan,

I noticed the changes on the device type, including the adjustedcolor fixes. Thank you very much :slight_smile:

I’ll let you know how my testing goes

2 Likes

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!