Hue Lights discussion

Thanks for looking into this.

I'm running Indigo 5.1.7 and the plugin is 0.9.5.

Here's the event log with debugging turned on:

ion:
delayAmount : 900
description : set hue bulb rgb levels to 255, 255, 255 with ramp rate 5.0
deviceId : 109472960
pluginId : com.nathansheldon.indigoplugin.HueLights
pluginTypeId : setRGB
props : com.nathansheldon.indigoplugin.HueLights : (dict)
blue : 255 (string)
brightness : 100 (string)
description : set hue bulb RGB levels to 255, 255, 255 with ramp rate 5.0 (string)
details0 : (string)
green : 255 (string)
hue : 230 (string)
intro1 : (string)
labelBlue : (string)
labelBrightness : (string)
labelGreen : (string)
labelHue : (string)
labelRate : (string)
labelRed : (string)
labelSaturation : (string)
rate : 5 (string)
red : 255 (string)
saturation : 100 (string)
replaceExisting : True
textToSpeak :
Hue Lights Debug Data: {"transitiontime": 50, "on": true, "xy": [0.447560546861, 0.407434672886], "bri": 255}, URL: http://192.168.1.37/api/dc182befd5bca02 ... ts/2/state
Hue Lights Debug Got response - [{"success":{"/lights/2/state/transitiontime":50}},{"success":{"/lights/2/state/on":true}},{"success":{"/lights/2/state/xy":[0.4476,0.4074]}},{"success":{"/lights/2/state/bri":255}}]
Hue Lights "End Table S" on to 100 with RGB values 255, 255 and 255 at ramp rate 5.0 sec.
Hue Lights Debug updateDeviceState: Updating device End Table S state: brightnessLevel = 100
Hue Lights Debug updateDeviceState: Updating device End Table S state: colorX = 0.4476
Hue Lights Debug updateDeviceState: Updating device End Table S state: colorY = 0.4074

Hue Lights Debug Data from Hue hub:
{u'name': u'End Table S', u'swversion': u'65003148', u'pointsymbol': {u'1': u'none', u'3': u'none', u'2': u'none', u'5': u'none', u'4': u'none', u'7': u'none', u'6': u'none', u'8': u'none'}, u'state': {u'on': True, u'hue': 15261, u'colormode': u'xy', u'effect': u'none', u'alert': u'none', u'xy': [0.44729999999999998, 0.4073], u'reachable': True, u'bri': 211, u'sat': 125, u'ct': 349}, u'type': u'Extended color light', u'modelid': u'LCT001'}
Hue Lights "End Table S" updated to on at 83
Hue Lights Debug updateDeviceState: Updating device End Table S state: brightnessLevel = 83
Hue Lights Debug updateDeviceState: Updating device End Table S state: colorX = 0.4473
Hue Lights Debug updateDeviceState: Updating device End Table S state: colorY = 0.4073
Hue Lights Debug updateDeviceState: Updating device End Table S state: colorRed = 194
Hue Lights Debug updateDeviceState: Updating device End Table S state: colorGreen = 194
Hue Lights Debug updateDeviceState: Updating device End Table S state: colorBlue = 194
Hue Lights Debug updateDeviceProps: Updating device End Table S properties.
Hue Lights Debug didDeviceCommPropertyChange

Thanks,

Carl

Cool. Thanks for the debug information. First, update the Hue Lights plugin to the latest version (0.9.8 ) from the main announcement thread. I don't know if that will resolve the issue but it's a good place to start until I can do more testing this evening. Let me know if it does end up fixing it.

Thanks but it still has same issue using 0.9.8.

Carl

Okay. Good to know. I'll do some testing tonight.

Okay. I tested out the color anomaly and was able to reproduce it. So, there are three things here. 1) It's not a bug. Despite the orange hue shown in the Hue app, the color of the bulb itself is roughly the same as a standard 60 Watt incandescent light bulb. That was how I'd set it up originally. 2) I've modified the color conversion algorithm in version 0.9.9 (now available from the original announcement thread) to assume a bluer white when converting RGB to the Hue's native (and non-standard) xyY-like color scheme. 3) I'd suggest using the Color Temperature method for whites and the HSB method for colors rather than the RGB method. The RGB method is provided for convenience, but it has to convert RGB values into a bastardized xyY color coordinate (bastardized because the "Y" of the "xyY" component is ignored, and the resulting color of the bulb doesn't seem to match what one might expect, at least based on my limited research of color schemes). By contrast, the Hue hub understands both Color Temperature and HSB values directly. The HSB method in Hue Lights sends the hue degree value and saturation value you enter directly to the Hue hub. No color conversion takes place because the Hue hub understands hue/saturation/brightness values. And the Color Temperature method performs a simple division of the Kelvin value for compatibility with the Hue's color temperature method.

So, let me know what you think about the new, bluer white obtained when sending RGB values of 255, 255, 255 to the bulb. Give the Color Temperature and HSB methods a try too and see what you think.

Wow, terrific, thanks for including that option. I rather prefer the warmer white
but it is nice to have the brighter cooler option as well.

Many thanks!

Carl

One for the suggestion box...might it be possible to have a default rgb/hsb on level? I see when the device is turned on it reverts to it's last on settings.

Thanks,

Carl

Hi Carl. It would be possible to have a default ON level for each bulb, though not for RGB because the combination of red, green and blue values defines the overall brightness. I'll see about adding a default ON level in the devise configuration dialog for the next update to Hue Lights. Thanks for the suggestion.

Yea, for whatever reason the wife just tends to go right to the device list to control
things...so much for all my work on control pages.

Thanks,

Carl

Question for plugin users

I got the plugin setup. I modified the Swithlinc that was controlling the old light to just wire the load ON all the time that way I can always talk to the bulb. I setup two trigger that turn on and off the bulb when Indigo sees Insteon On and Off commands from the old switch. That works but I notice a number of non-ideal behaviors that I am wondering if you guys have workarounds for:
1) If I hold down the button the switch to set a certain brightness level that doesn't trigger the script because the command is "start brighten".
2) I have many existing Insteon scenes that used these light locations (when they were just incandesces controller by the Switchlinc. None of these scenes work anymore because I can't add these bulbs into the Insteon scene.

I realize that I could create a whole bunch of triggers for switch on, switch off, start brighten, stop brighten, scene 1 on, scene 1 off, etc but that would be a lot of triggers and I would have to multiply that for each bulb. It doesn't seem to scale.

I wish I could just link the state of the bulb to the state of the switchlinc that was/is controlling these ceiling lights.

Any ideas for me?

Question for plugin users
1) If I hold down the button the switch to set a certain brightness level that doesn't trigger the script because the command is "start brighten".

Yes. I encountered this limitation as well. My solution was to create triggers (using events defined in my Dimmer Extender plugin) for start and stop brightening and dimming, which amounted to 4 triggers per light. I only have 3 Hue lights, so that wasn't a huge deal for me, especially using Indigo's "Duplicate" button to duplicate the triggers, but if you have many more, it could become very cumbersome. If you don't need real-time dimming and you just want the Hue lights to go to the approximate brightness level represented by the LEDs on the SwitchLinc Dimmer face, you could create 1 trigger per SwitchLinc Dimmer that triggers off brightness change and sets the brightness of the corresponding Hue light to the same brightness as the SwitchLinc Dimmer.

2) I have many existing Insteon scenes that used these light locations (when they were just incandesces controller by the Switchlinc. None of these scenes work anymore because I can't add these bulbs into the Insteon scene.

Yep. That's certainly a limitation of mixing fundamentally different automation technologies. The only thing I can think of to work around this would be to convert your scenes to Action Groups. If your scenes had varying brightness levels based on some other condition (bright for day, dim for night, for example), you could use the "Set Brightness with Ramp Rate" Hue Lights plugin action and specify an Indigo variable as the brightness source. This way, your action group could first set the Indigo variable to the brightness percent you want the lights to go to, then the other Set Brightness with Ramp Rate actions in the Action Group would set all the Hue lights to the brightness value in that variable. This conversion from INSTEON scenes to Action Groups would take some time, but once done, the functionality should be very similar with about the same number of triggers.

Am I right in believing that the plugin doesn't like LivingWhites products?
When I first ad a device that is of the LivingWhites kind it works fine, but when I restart Indigo or the plugin I get the following:

Enabling plugin "Hue Lights 0.9.9"
Starting plugin "Hue Lights 0.9.9" (pid 455)
Plugin "Hue Lights" connected
Plugin "Hue Lights 0.9.9" started
Hue Lights Loaded 10 bulb(s)
Hue Lights Error exception in deviceStartComm(Living Reading light): 'hue'
Hue Lights Error exception in deviceStartComm(Living Side light): 'hue'
Hue Lights Error exception in deviceStartComm(Living TV light): 'hue'
Hue Lights Error exception in deviceStartComm(LivingWhite 1): 'hue'
Hue Lights Error exception in deviceStartComm(LivingWhite 2): 'hue'
Hue Lights Error exception in deviceStartComm(LivingWhite 3): 'hue'
Hue Lights Error exception in deviceStartComm(LivingWhite 4): 'hue'
Hue Lights Error Error in plugin execution runConcurrentThread:

Traceback (most recent call last):
File "plugin.py", line 255, in runConcurrentThread
File "plugin.py", line 773, in getBulbStatus
<type 'exceptions.KeyError'>: 'hue'

Hue Lights Error plugin runConcurrentThread function returned or failed (will attempt again in 10 seconds)

I see a lot of 'hue' comments in the error which is logical because the LivingWhites, as the name suggests, can't do color.
Is there a chance that, besides the lonely "Hue Bulb" model, the "LivingWhites Bulb" and the "LivingWhites Wallplug" could be added to the model choice?

Thnx,

Bert

Hi Bert.

Until your post I'd never heard of "LivingWhites" product. The reason for the "hue" in all the errors is probably because the plugin is attempting to get the current color (hue) setting from each bulb. If the LivingWhites don't report a "hue" value to the Hue hub, that's why the error is being reported.

Unfortunately, it doesn't look like Philips mentions anything about the LivingWhites in the Hue documentation (or the API), and since I live in North America (where the plugs and power system are incompatible with the LivingWhites), I can't test them myself. If you have some links to API docs, I might be able to do something, but no promises.

Regards,
Nathan

Nathan,

Didn't know these lights were unavailable in North America. I don't think there's an official API. Philips doesn't even mention hue and LivingWhites being compatible. I used LampStealer to connect them and they just work. And apart of the annoying error they do work in Indigo, I just mustn't restart the plugin/Indigo.
Maybe someone at http://www.everyhue.com knows something about an unofficial API. I searched there but until now I haven't found anything useful yet.
Is there a way I can query my bulbs for supported properties?

Update:
I did a simple applescript query on a wall plug, and the folowing was returned:

{
"state": {
"on": false,
"bri": 240,
"alert": "none",
"effect": "none",
"reachable": true
},
"type": "Dimmable plug-in unit",
"name": "Wallplug 1",
"modelid": "LWL001",
"swversion": "0",
"pointsymbol": { }
}
}

And a Bulb returns the following:

{
"state": {
"on": false,
"bri": 128,
"alert": "none",
"effect": "none",
"reachable": true
},
"type": "Dimmable light",
"name": "LivingWhite 20W 1",
"modelid": "LWB001",
"swversion": "0",
"pointsymbol": { }
}
}

Don't know if this helps, but it looks exactly the same as a hue bulb minus the color part.

Hi Bert.

Interesting. Yes. That info might indeed be helpful. As soon as i get a chance, I'll see what I can do with the plugin and post a test version of it for you to try. Thanks for sharing the info!

Nathan