If you were trying to capture a group of various bulbs in different states that is probably not going to go well, most likely based on how Hue reports the state of the entire group, not individual bulbs. You will probably still not like the results, and want to just import the scenes, so that Hubitat can just tell Hue to activate whatever scene, instead of many individual bulbs.
In the group were 2 hue lamps and 4 A19 bulbs. All were set to the same color and brightness. ct value of 447 and bri value of 145 (Hue settings). But green on capture from HE? It's just odd.
They’re odd bulbs that work excellent on the Hue bridge and nowhere else. It’s funny that it’s captured as green. When I tried mine paired to HE, the always seemed to cycle past a green color when I turned them on. One of the reasons they quickly went back on the bridge.
You need CT or hue/saturation values (ideally in colorMode: ct or colorMode: hs) to work well with Hubitat. If the bulbs are in xy mode, I'm not sure which set of values Hubitat's stock integration will parse (I think CT?), but I do know it will not attempt xy-to-HS conversion (which is difficult to do accurately; I'm trying to figure something out myself now). That could be the problem. If you can find a matching hue/saturation color and set it from Hubitat, it should work better. Hue, unfortunately, seems insistent on using xy color if manipulated from the Hue app as of a few firmware updates ago, or possibly longer but I never noticed. CT from the Hue app seems fine until you save a scene, then that too gets set as xy.
1 Like
Thankfully I’m using your app to import scenes, not capture them in HE. It has been excellent btw.
1 Like
I've been testing it out more and I think I'm going to back to the Hue Hub. When I was using Vera Plus it didn't really have Hue integration (for my size of Hue use). I have two hubs and close to 80 lights/bulbs/indoor and outdoor light strips). I created a back end API to do everything you can imagine. HE has http capabilities and I have it set to call the API endpoints. Works great and no endless configuring drop down lists with green results. lol
1 Like
I think that’s the right call. The Hue bridge is the best thing made to control Hue bulbs. With @bertabcd1234 ‘s CoCoHue app, I have all Hue scenes activated from HE, and also zgm for Hue groups, which is nice for dimming, but maybe not necessary if you already have it set up the way you want it.
I had no luck with XY and HE understanding it. But, creating the Dashboards with the Groups and Scenes is less effort. Using RM to call my API makes me create a lot of virtual buttons to get the functions into the Dashboard.
I tried the CoCoHue App. I don't have scenes for each room/zone. I create (via code) LightScenes not GroupScenes. This allows me to have 6 scenes total on each hub and I can keep them in sync easily. I then apply the LightScene to a group and only bulbs in that group are changed. CoCoHue didn't handle LightScenes, it would trigger all bulbs on that hub to activate and I couldn't figure out how to apply the LightScene to a group in CoCoHue.
I’m afraid lightscenes are before my time (with Hue that is). Hue V2 did away with those I believe and went to group scenes. Maybe @bertabcd1234 will have something to add, because I’m not familiar.
LightScenes are alive and well. I'm using v2 too. They allow you to control LightStates without having to turn on the lights to create a scene and give you a "master plan" to apply to any group on a hub. Makes for a no hassle and predictable implementation. Also, they are not visible in the Hue app, so others can't screw them up. 
1 Like
I'm not sure what you mean with "activate." Do you mean all bulbs would turn on? If so, I'm not sure why; it just sends the scene ID to /groups/0/action (which it actually does for GroupScenes too to make it easy since it doesn't matter), which both shouldn't cause this problem and as far as I can tell from the docs is the only way to do this. That being said, I haven't tested this on v2 with the group <-> light state "sync" options, so it's possible something odd is going on there if you're using one or both of those...
I'm also not sure about "applying a LightScene to a group." Since LightScenes are not associated with groups, that does not make sense to me, but even the fact that GroupScenes are associated with groups is pretty well abstracted away to any CoCoHue user since it doesn't display (aside from data only used by CoCoHue) or require any knowledge of the associated group to the user.
1 Like
Yes. When I used a LightScene it would turn on all lights on the Hub. It did apply the scene to the built-in group 0 on the Hub.
I'll explain better how I use LightScenes. In the scene definition I define a state for every light on the hub per scene. So for example, for my office, for the "morning" scene, i set the lights to a bright color with brightness on full. But my outdoor lights are set to off (because it's daytime). So if I apply the LightScene to my Office (group 14) I get the nice bright light. If I apply the scene to Group 21 (outdoor lights) they go off if they were on.
This allows me to have 6 predictable settings for each time-slice in a 24 hour period. I have defined 6 slices that make up 24 hours; early_morning, morning, afternoon, evening, night, and late_night. Each slice has a LightScene Scene and controls on/off, light color and brightness of every bulb. It's predictable and consistent. Any changes I want to make are done using code, not the Hue App and I don't have to mess around configuring each room/zone individually.
To set any room or zone, i call my "on" API endpoint; the API gets the HE "mode" and turns on the appropriate LightScene scene. This allows me to have Wallmotes on the wall. I walk by press button 1 and the lights turn on to the default scene as defined by the HE mode setting. If I press button 1 again within 7 seconds, each press cycles through the 6 LightScenes allowing me to override the default for brighter or darker lighting.
Wallmotes in each room control only that room. Wallmotes in hallways control that zone. For me it's about simplicity. Dealing with 6 scenes on each hub is just easier. This also allows users to customize their areas with scenes created by the apps they prefer without messing up the systems defaults.
I'm struggling to understand this. Consider the following scenario....
I'm interesting in reproducing a custom RGB in my Hue bulbs connecting to HE courtesy of CoCoHue. Since I think I understand that HE is based on HSV, I pull up one of the many RGB-to-HSV convertors on the web, figure out the corresponding HSV value. I then go into the device details page of the CoCoHue device (later I'll convert this manual step to RM) only to find that:
- There is no command for "V". Only Hue and Saturation.
- Even if I set just the Hue and Saturation, I'm not getting a color that corresponds to the starting RGB value. I've enabled the Hue value in degrees (0- 360).
So, then I think, ok, I'll select a color approximating my starting RGB directly from the setcolor map. I picked a dark blue from the map, click Set Color, and, lo and behold, my Hue bulbs turn yellow. Then I select yellow from the color map, and the bulbs turn red.
I don't remember taking any illicit substances, I swear. Any idea what I'm doing wrong?
Hubitat's color model is HSV/HSB, not HSL, and the "V" or "B" component correspond to the level attribute (which in real-world terms is brightness/dim level). So, either individual "Set Hue," "Set Saturation," and "Set Level" commands to get the HSV values you want or a single "Set Color" command (which takes a map of hue, saturation, and level values, and is my preference since this is a single command and is likely to work better from a network and device perspective) should get you where you want to be as long as you have appropriate values calculated.
If you have 0-360 hue values turned on device preferences, then Hubitat's color sliders are not going to match what you really see for hue. Those are scaled 0-100 no matter what. I believe that would explain your blue vs. yellow issue.
As for the rest, I'm not sure what to say other than that maybe there is some issue with the RGB to HS conversion, perhaps owing to HSL instead of HSV/HSB (the latter of which I believe are equivalent, though I am by no means an expert on color models--I can only tell you what I've learned from lots of time playing with Philips Hue and reading about xy/hs conversion, which is more difficult than I anticipated ).
Ah, that is so helpful. I didn't realize that V/B = Level. I also didn't understand that the color map ignores the hue scale.
I'm going to put the Hue scale back on 0-100 and rerun the test. Thanks
For those that follow in my bulb-noob footsteps, @bertabcd1234's clarification above about the color map not tracking when Hue is set to degrees was the big discovery. Once I solved that, Hue bulbs ceased being color crazy (e.g., showing yellow when I selected blue, etc.)
However, there's still odd shading. Let's use my beloved Pittsburgh Steelers as an example. When you go to the official NFL color palette, you see that one of their secondary colors (after the great black and gold) is red. I went here to find that the red has an RGB value of 213, 10, 10. I then went here to convert that RGB value to an HSV of 0 degrees, 95%, 84%. I recall reading that a Hue of zero degrees is pure red so at this point I'm thinking it sounds correct. And I'm thinking when I plug those numbers into the device details page of my CoCoHue RGBW bulb, I should be close.
Except I'm not. Here's Pittsburgh red (please don't sue me, NFL): 
And below is a terrible picture of the bulb. Trust me when I tell you it's "trick or treat" orange. Look at the reflection of the metal trim in the upper right hand corner and you can get a pretty accurate rendering of the color). Any idea what I might be doing wrong?
Probably nothing. 
Tell two different brands of smart bulbs to set themselves to the same hue and you will probably get two different results. For Philips Hue in particular, while I love the bulbs, I've compared them at hue 0 to other smart bulbs at the same value (e.g., Inovelli/Ilumin) and find them to be a bit orange-y. I don't really notice it when it's just a Hue bulb, but the comparison makes it clearer.
A possible second issue is that bulbs tend to have a limited color gamut, possibly causing the first issue. This was most notable in generation 1 and 2 Hue bulbs, where greens were pretty washed out and blues more purple. The diagram here with "gamut C" that the gen 3 (and newer) bulbs supports illustrates this a bit: Completed Philips Hue product model list(US) - Home Automation Technology (I know they've had products in all three but think the previous bulbs were B, so the current ones are also probably a tad better at red, too).
Despite all of that, if you mess around with the hue and saturation values enough, I suspect you'll find something close enough. I personally rarely lower saturation much below 100%, otherwise the color starts to look too white/washed out (remember that by definition a saturation of 0% would be black, gray, or white, though with bulbs we'd really see only the latter). I'd suggest experimenting with nearby hue values to see what works, keeping in mind that you could go up to 100 (or 360 if using degrees), and it would be nearly the same as 0. As you go up from 0, it goes from red to orange; as you go down from 100 or 360, it goes from red to magenta. Something near one of those extremes with a higher saturation that the online conversion tool suggested would be my best guess. Level is more or less up to you, with an idea bulb being faithful to hue and saturation throughout the entirely of its brightness range (does not always happen in my testing with all bulbs, but I haven't noticed any Hue oddities here).
Hope this helps!
1 Like
Makes total sense. While disappointing, not entirely surprising. I feel marginally better that it wasn't me!
Hopefully this conversation helps other bulb-noobs that follow. Props to you.
What driver are you using to get those Preferences options?
