Indigo Domotics

I'm experimenting with the standard indigo.dimmer.setColorLevels python methods on some Hue Bulbs and Hue Groups. I am pretty new to the Hue Plugin and behavior so wanted to take some inputs.

Set RGB values using the code below:

Code: Select all

  indigo.dimmer.setColorLevels(indigo.devices["Hue Bulb Group"], newRed, newGreen, newBlue)

Set Color Temp using the code below:

Code: Select all

  indigo.dimmer.setColorLevels(indigo.devices["Hue Bulb Group"], 100, 100, 100, 100, 0, newTemp)

In both of the methods above, the brightness for a bulb is always set to 100%. Is this expected? Is a different indigo method preferred in order to pass in the brightness at the same time and avoid it setting to 100%?

In general, the RGB colors seem a bit off based on the eyeball test but I understand it isn't exact. However, I do notice the Indigo settings for 'W' and 'Temp' are automatically updated via the plugin after updating RGB. Is there an optimal way to use the python methods to get the colors more exact? For example should I set the W/Temp values to something before setting RGB?

The native Indigo "setColorLevels" method is designed to accommodate a wide variety of RGB, RGB+W and color temperature devices, but not necessarily to work with all features of all color capable devices. So with the Hue devices, only RGB and color temperature are supported.

For RGB, brightness is implied by the highest red, green or blue value. If you specify RGB values of 90, 0 and 10, the implied brightness is 90 because that's the brightest channel.

For color temperature, because the "setColorLevels" method doesn't include a brightness parameter, the Hue Lights plugin ignores any RGB values passed and uses the existing brightness level of the device. If you want to change the brightness using standard Indigo commands, you'll either need to set the brightness before or after the "setColorLevel".

If you want to set both color temperature and brightness in one command, use the plugin methods illustrated in the Hue Lights announcement thread instead of the native Indigo methods.

Thanks for the explanation Nathan - I am not necessarily looking to have an all-in-one-method as much as understanding the current functionality.. Truth be told I wrote a plugin that allows dynamic light scenes to be created. It is written generically based on the Indigo DimmerType, and as such uses these methods only rather than anything native to a plugin.

In regards to the the existing behavior that you described for the RGB method, I am not sure it makes sense to imply the brightness from the highest RGB channel. The RGB setting should only impact the bulb color - for example you could have Red at 100%, but the bulb brightness of the bulb set to a very dim 20% right?

Congrats on the plugin! Have you shared it or is it mostly just for private use for now?

As for RGB and brightness, RGB color almost always means that each red, green and blue level is expressed in absolute terms, not relative terms. For instance, if I have text on a web page that I want to appear as a bright magenta, the CSS color would be rgb(255, 0, 255). If I then wanted to darken that, the CSS color would be represented by simply decreasing the red and blue values. such as rgb(128, 0, 128). There's no separate brightness component because the red, green and blue values have a fixed range of 0 to 255. Decrease the brightness by proportionally decreasing all of the red, green and blue components. (I use this wiki article on RGB notation as a reference).

As for the accuracy of the Hue bulb's representation of RGB, depending on which Hue light you have, it's not going to be very accurate, especially for cyans, greens and yellows. None of the earlier models of Color and Ambiance bulbs were capable of displaying deep greens or yellows at all, much less the full sRGB color gamut. The lights that are able to get closest are the second generation LightStrips and some of the newer Color and Ambiance bulbs. But even so, don't expect color accurate RGB representations. The Hue system doesn't even natively support RGB references. RGB has to be converted to CIE XY chromaticity values. The math for that is more complicated than I want to figure out, so I rely on 3rd party open source Python color math libraries in the plugin to do all that conversion. So those conversions may not be the most accurate as well.

Hope that helps.

I haven't published it yet - I thought I'd prime the pump in a couple of Topics to see if anyone is interested before I polish it up. The last post on that 'Scenes' Topic was super old so not sure if anyone is watching it

Thanks for the details on the RGB handling.. This still seems a bit odd to me - I haven't yet dug into the wikipedia page as I am not sure how much of a color expert I wanna become. I do think the Sylvania bulbs manage the RGB more natively - as you get a color pretty much spot on for the eyeball test when playing with one of those Color Pickers ( https://www.rapidtables.com/web/color/RGB_Color.html ) . Also the Brightness seems to be managed independently and doesn't change around the RGB values.

For the generation of the Hue bulbs - I just purchased them in the last couple of weeks at Costco, so hopefully they are the latest gen. The Zigbee connectivity seems way better than the Sylvania A19 bulbs - even when paired with the Sylvania Lightify Hub. So far none of the Hue A19s have had any type of connectivity issues

The Z-Wave RGB devices I've encountered have brightness independent of the RGB values. From a usability standpoint this is nice because one can set a specific color and then change brightness without impacting the current "color" used by the device. For example, one can dim the device down to 0% (or near 0%) then back up to 100% and it will still be the same original color.

@matt - yeah I totally agree from a usability perspective in terms of separation of config for Brightness vs. RGB.

From the eyeball test though, I am not entirely convinced that Brightness and RGB are connected for the Hue Bulbs. For example, my favorite color for Movie Watching is a cyan/aquamarine color - #1FFFFA, RGB = 31, 255, 250 (as RGB percentage - 12, 100, 98) .. Changing the brightness from 100% to 50%, the Hue Bulbs adapt the RGB percentage to 6, 50, 49 .. However, the color (to the eye) still looks the same just not as bright. Definitely not anywhere near to the color shown on the Indigo color picker chart for RGB Hex of 16, 128, 125 - which is more of a teal than aquamarine

rbdubz3 wrote:

Definitely not anywhere near to the color shown on the Indigo color picker chart for RGB Hex of 16, 128, 125 - which is more of a teal than aquamarine

Indeed. It’s a physical limitation of the Hue bulbs. Their LEDs aren’t capable of producing a true cyan color. This article explains it pretty well.

Sorry Nathan I was unclear - trying to convey that the when switching the brightness on the Hue color bulbs, the 'adjusted' RGB values shown are way off from the color to the eye on the bulb.. It isn't just the physical limitation you've mentioned - in strict RGB terms the colors are different :
- RGB percentage - 12, 100, 98 (set Hue brightness=100%) - this is my movie 'Aquamarine' .. And yeah I did notice the Hue Limitations and that this color is a bit off from the color picker tables
- RGB percentage 6, 50, 49 (set Hue brightness = 50%) - The color to the eye on the hue bulbs still looks the same as the 'Aquamarine', just not as bright.. However, the color picker for Indigo (and other charts such as https://www.rapidtables.com/web/color/RGB_Color.html ) show a color that is supposed to be more of a Teal - Hex RGB 16, 128, 125

If you do the same for a non-Cyan color - for example straight up Red - 255, 0, 0 .. Then switch the brightness to 50%, the RGB color picker shows a color that should look much more Maroon.

I think I'm still just adapting to a non-RGB viewpoint on Color. Wrapping my head around the Color XY stuff for Hue, and the Hue twitter support team forwarded me some info on their developer site such as this one - https://developers.meethue.com/develop/ ... -and-back/

I recently updated to the latest version of the Hue Plugin.. Since the upgrade, I've noticed handling of some of the indigo commands seems to have changed a bit.. My plugin issues the following command for changing the colorTemp:

Code: Select all

indigo.dimmer.setColorLevels(workItem.theDevice.id, 100, 100, 100, 100, 0, workItem.colorTemp)

Since the Hue plugin upgrade, this command also sets the brightness to be 100% in addition to the desired ColorTemp.. Can you advise the proper setColorLevels command to ONLY change the color temp for the Hue bulbs?

thanks in advance!

Hi there.

I had to rewrite the code that handles the generic Indigo setColorLevels method because the plugin wasn't handling different RGB and color temperature values consistently.

As of version 1.7.34, the only way the plugin knows to use the color temperature value is if the brightness value is a number greater than zero and a color temperature value is specified. If the brightness is anything other than a value between 1 and 100, the plugin defaults to using the red, green and blue values sent in the setColorLevels command, regardless of if a color temperature was specified. One possible way to accomplish what you're looking for might be to specify the current brightness level of the target device within the setColorLevels command...

Code: Select all

indigo.dimmer.setColorLevels(workItem.theDevice.id, 100, 100, 100, indigo.devices[workItem.theDevice.id].states['brightnessLevel'], 0, workItem.colorTemp)

Hope that helps.

Thanks Nathan - that worked for me!

Excellent! Glad that wired.