Oh, I thought you were asking about the behavior of CoCoHue's "transition time" and not asking a general question about the parameter with the same name in the Hue API, but I see now. I haven't tested that specifically but can when I'm near my Hue lights again. I don't see anything in the docs that calls this out specifically as not working, but there are other things that don't work with on: false either (but they're also called out as not working after this state is set), so who knows. It seems to me like it would be more consistent if it did...I'll let you know what I see!
Thanks! I can see the transition time getting into my bridge, so I think I added it correctly in the driver. But I can't tell if it's a DIYHue issue or if if it's a Hubitat issue or if it's just not supposed to work at all! There are just too many variables to figure it out without another point of reference.
Just tried this (genuine Hue Bridge with Hue bulbs), and, for example, {"on": true, "transitiontime": 90} has no different effect than {"on": true}. Mysteriously, {"on": false, "transitiontime": 90} has the expected effect (a 9-second fade to off). If anything, I would have expected this behavior to be backwards. However, even with a transitiontime specified for "on": false, some oddities remain: a subsequent "on": true restores the bulb to a very dim state (presumably bri: 1), not their previous bri level.
My plan, with these findings, is to continue avoiding specifying transitiontime in conjunction with on. I would have never thought it didn't work this way, however, so thanks for the prodding to look!
1 Like
Very interesting. I'm going to have to see what I can see with DIYHue and see if I am getting the same results. I'm really only concerned with Off anyway, since I almost always setLevel, which works perfectly with transition time, as far as I can tell.
I'm seeing something a little odd. With color prestaging turned on and color HS turned off, the group device keeps reverting back to the previous settings for color and colormode. Even If I change all the component lights separately, and have the options for updating immediately turned on, as soon as the bridge is re-polled, the group device lists the incorrect colormode and color. I can pull logs if you want but if you take a look at the group device you'll see it's not being set with the correct color & colormode.
I'll take a look! Before I do that, can you tell me what version you're on? (I made changes in one of the most recent versions, but even if you're not on it I'll see if I can fix it there...or see if my recent fix broke something along the way.) Also, by "color HS" off, do you mean it's in CT mode?
Most recent version.
I believe that means High Sensitive Color mode. But "not in hs mode" is what came out of the logs. I can see it in a debug message down in the createEventsFromMap method. I tried commenting that out and it still didn't work though. So, that's when I decided better to let you know than to monkey with it all day. 
Ah, so "hs" here refers to Hue's colormode attribute, which can be either hs (hue/saturation, the best mode for color with Hubitat or ST integration given that they use a similar model), ct (color temperature, also good for Hubitat or ST), or xy (which can represent either and which Hue has started using for a lot under the hood recently; unfortunately, Hubitat does not use xy color, and conversion to hs is difficult, and ct not much easier assuming you even know it's "supposed" to be CT). If you have debug logging turned on for the group, you'll see what data is coming from the Bridge. Here's what happened when I tried setting the CT about 2750 myself (so CT mode--just so I know where I start), the change to which is not logged below, then telling the Hue app to turn on the "Concentrate" scene (used to be CT mode at around 4350K, but recently Hue has been doing this in xy mode instead with the same visual result).
Immediately after activating "Concentrate" (when previously in CT mode at 2750 K):
2020-03-28 16:18:36.134 [debug] Preparing to create events from map from Bridge: [on:false, bri:254, hue:39415, sat:13, effect:none, xy:[0.3691, 0.3719], ct:364, alert:none, colormode:xy]
After waiting a couple minutes without changing anything, the Bridge reports:
2020-03-28 16:22:38.352 [debug] Preparing to create events from map from Bridge: [on:false, bri:254, hue:39415, sat:13, effect:none, xy:[0.3691, 0.3719], ct:230, alert:none, colormode:xy]
This are basically the same except that Hue has updated the ct value (the fist value of 264 is represents about 2700K; the latter of 230 is about 4750 K). This seems to be a calculation Hue doesn't do immediately but does behind the scenes (ha) but rather at some unpredictable, undocumented point afterwards.
So...why am I saying all of this? CoCoHue has a secret. I think Hubitat's stock integration does too. Since Hubitat doesn't deal with xy color and conversion is something I'm looking into but pretty much a failure with everything I've tried so far, CoCoHue deals with xy mode by just parsing the ct value (which eventually seems to be accurate if it does really represent a CT) from the Bridge, while trying to not change the color or colorMode attributes on Hubitat, per the debug log:
"Skipping colorMode and color name event creation because light not in hs mode"
This isn't ideal (I wish I could know whether, when in xy, the values represent color or CT and convert reliably), but it does seem to provide the best behavior most of the time. This is also why you see the logs note that it's not in hs mode. It would also be good if Hue didn't change what it reports afterwards when nothing actually changed, but that's another story.
So, that's one possibility, but it's not the only place I've seen Hue sneak weird things in behind the scenes. If you create a scene from the Hue app in CT mode and then save it, it seems to get saved as xy (so it's not just the built-in ones), despite the lights appearing in ct mode from the Bridge while editing (I've checked before and after). What value Hue calculates as the colormode, ct, and whatnot of a group device also seems to be somewhat unpredictable: CoCoHue assumes it's the value of the last light in that group that you changed, and in most cases this seems correct. However, sometimes I change a different light in that group later, and Hue doesn't update the values reported for the group to match. I have no idea what the pattern is here, and I don't think it's documented. If anyone knows, I'd love to find out.
For both of these issues, there are a couple of solutions I've internally debated:
- Provide a preference for how to handle xy mode in Hue: ignore (don't change color or CT on Hubitat), parse CT only (current behavior--I was in the process of making these options when I discovered this was good enough for me), or attempt some conversion (not currently possible but something I will try to figure out some day)
- Provide preferences on how to propagate bulb->group and group->bulb changes. Right now, both directions encompass just about all attributes, though as you've seen, color-related ones and level can be tricky. The on/off state is predictable (assuming you're OK with CoCoHue's behavior of matching the Hue app and assuming a group is on if any member bulbs are on), so any changes would likely provide an additional option to just do this instead of everything or nothing.
Sorry for the long post and knowledge dump of all the Bridge quirks I've figured out when writing this, but hopefully you can dig through and find something that is applicable to your situation. Let me know if any changes would be helpful! And if you don't have a Hue debugger handy (the web-based CLIP API or a REST app like Insomnia or Hue Debugger), debug logging for lights and groups in CoCoHue will show you the map of values it receives from the Bridge if that's of any help in figuring out a pattern.
Sorry, but I'm not following you. Maybe I wasn't clear in my explanation. If you make a change to the color of a group device, after a second or two the settings revert back to CT mode and the color name is the name corresponding to the CT value. It always reverts back to the last CT setting that the device was set to. The color mode of the group device is never correct in Hubitat. The individual lights are correct. But the group device is not. I have the setting set to update the group device and the setting to update the individual bulbs when the other chnages. Can I not have both enabled?
Also, changes to the lights color made in the Hue app while in RGB Mode are not reflected in Hubitat after the lights sync. Level changes, switch status, and CT values all sync correctly when changed in the Hue app. But color does not seem to sync for either individual lights or groups for changes outside of HE. Even if the light is in RGB mode in Hubitat and I use the Hue app just to change the color, in HE the colormode goes back to CT mode and the name changes to the last CT name that device was previously set to. The light is still in the correct color but HE shows it in CT mode.
Are you saying that both of these are "just the way it is"? I don't remember this happening in the native integration but I will install it again and check it out.
I'd be curious what the data map coming from the Bridge really is. My suspicion, at least for "RGB" problems, is that Hue is in xy mode, which would explain some oddities. The Hue app tends to use xy instead of hs when setting color. For color temperature, it seems to use CT until you save it as a scene, in which case it goes to xy for some reason. Either this behavior is new (last year or so?) or I've never noticed it, but either way, to summarize the above, there's no great way to deal with xy data from Hue, and comparing groups vs. bulbs can be difficult because I'm not sure exactly how it chooses to report group state based on bulbs ("most recent" is easy but does not seem to capture the full range of its behavior, which itself can change with the passing of time even if you don't change anything!). I also haven't played around with prestaging much so that might add an extra complication (furthering the delay in this discrepancy even more).
To answer the specific question, you should be able to have immediate group to bulb and bulb to group syncing turned on. Hue seems to report groups somewhat unpredictably compared to members, which may explain part of these odddities, but Hue sneaking into xy colormode behind the scenes probably has something to do with it too. If I can provide at least the "Map from Bridge" from the debug logs, that would help tell. (For extra fun, get them right after you change, then get them again a couple minutes later. They may be different, even if you didn't change anything. Refreshing the Bridge device will generate the "Map from Bridge" in the bulb or group debug logs.)
That's the part that I don't understand. The bulb isn't reporting back in XY mode. It's reporting back in HS mode.
I first turned the bulb to 3000K and then to Blue a few times in a row but each time the group reverted back to CT mode. Also, the individual bulbs did not change to Color Mode but stayed in CT mode.
Actually, it's reporting no color mode. Can I ask what bulb and Bridge you are using? You should see something like this, which is what I see with any Color or Extended Color-type bulb on a Hue v2 Bridge:
Preparing to create events from map from Bridge: [on:false, bri:254, hue:39415, sat:13, effect:none, xy:[0.3691, 0.3719], ct:230, alert:none, colormode:xy]
If not colormode:hs, CoCoHue will parse the color temperature (ct value) if present. I think that could explain what's going on here. If this is diyHue, it appears they're not reporting back colormode to specify which of the xy, hue/sat, or ct values are the correct (or at least best) ones to parse for the current light state.
Well, I am using DIYHue...so if that is not coming back from the bridge correctly, then I will report it to them. They've been really interested in the other things I've found where their response differs from genuine Hue so this is a distinct possibility.
So, in this case:
Why does Coco hue assume that XY mode is CT? Couldn't that also be RGB? That's the part that I'm not quite understanding. I set the light to an RGB color via hubitat and then made a change to the color in the Hue app and it changes from HS to XY mode but the lights is still in colormode RGBW. Are you not able to tell that from the XY value you get back from the bridge?
I think this is one of those times, so it might be good to report. It doesn't look like they're reporting a colormode value at all, which is definitely necessary for Color and Extended Color lights (since there are two or three colormodes possible for each, and the value of colormode tells you which of the xy, hue/sat, or ct values returned from the Bridge is guaranteed to represent its current color) but also something I've seen on Color Temperature lights too, at least Hue's own (less important here, but they could technically be in either xy or ct mode; Hue always appears to have the correct value for ct regardless).
colormode: xy could indeed represent either a color or a color temperature. There are several problems, however. Most notably, Hubitat (and ST) doesn't have any support for the xy color model; it uses only hue/saturation (or really HSL). When the Bridge is in colormode: hs, it's easy--just scale the hue and sat values from the Bridge down to what Hubitat uses. Similarly, when Hue is in colormode: ct, it's easy: convert the ct value from Hue (mireds) to Hubitat (Kelvin). If Hubitat supported xy, this would be easy, too. Since it doesn't, the second-easiest solution would be for CoCoHue to convert xy to hs or ct, but that brings us to the second problem: xy to hs conversion is nearly impossible to do accurately (and yes, I have Googled those pages a few people have found from apparently old Hue API docs 
), and xy to ct conversion isn't much better and you have to know that you're in ct range in the first place.
If you only manipulate the lights from Hubitat, it should only send hue and sat values, which will keep the Bridge in colormode: hs. Similar for color temperature. However, as I've noted, the Hue app strongly prefers colormode: xy nowadays, especially for RGB colors but often for CT shades now, too, especially if you save it as a scene (for the duration of in-app manipulation, I still have seen colormode: ct).
Basically, there isn't a good way to handle the xy colorspace, and I'm open to ideas for how to parse these better. The best bet is to avoid it if possible, and I think diyHue accurately reporting colormode would also help CoCoHue from thinking this might be happening when it isn't.
(Side note: you may recall issues from the past with Ikea's color bulbs: they only support xy color, not hs color--either reporting or receiving; this is unusual--so they don't work well on Hubitat.)
I've sent a request to see if they can add a hook to force the reporting mode. What does the genuine Hue Bridge do when you make a change in the Hue app? Does it report in HS mode or in XY mode? There also might be a different way to define the lights in DIYHue (since i have complete control) that will force them into HS mode all the time.
In the Hue app, I've noticed lately that changing things in the RGB color wheel puts the lights into colormode: xy. It may have used hs in the past; I can't remember. Modifying it in the color temperature wheel puts it in colormode: ct (yay!), but when I save that as a scene and recall it later, it's xy (noooo!). In general, however, my interpretation of the Hue API docs--so probably what diyHue woud want to do--is this:
- when you send a
hueand/orsatvalue to the Bridge, the light will update those values and go intocolormode: hs(so: what will happen if you send a color, hue, or saturation value from Hubitat) - when you send a
ctvalue to the Bridge, the light will update that value and go intocolormode: ct(so: what will happen if you send a color temperature from Hubitat) - when you send a
xyvalue to the Bridge (not sure many humans really do this and Hubitat definitely won't but the Hue app seems to use this behind the scenes of the RGB wheel), the light will update that value and go intocolormode: xy - if you send more than one at the same time (no idea why you would), all values will be updated (but I assume not all may be accurate unless you know what you know exactly what you're doing), and Hue will update
colormodewithxy>hs>ctpriority - one ore more of
hue,sat,xy, orctmay be returned from the Bridge, butcolormodedetermines which is guaranteed to accurately represent the current state (I have noticed that at least genuine Hue bulbs on the Hue Bridge are good about updating the value ofcteven if in xy mode if the light is really in a color temperature space, as might happen if you recall a formerly-CT scene like Concentrate or Read; I assume this behavior varies between bulbs, and gain there are some like Ikea that implement only xy).
But DIY hue is doing all of this today. It's when changes are made on the BRIDGE that there's a problem.
If that's what the Genuine Hue Bridge is doing, why should DIYHue not do it? If they are trying to emulate the Bridge itself? That's the part I'm not understanding.
I see a lot of examples of how to convert from XY to HS online. They solved this problem on HA. And even if it's not 100% accurate, close is better than totally wrong.
It can do it this. However, since color can be represented in either hs or xy, I don't see a reason to prefer one mode versus the other. Either should work (though Hubitat plays a lot better with hs color--and it's a lot easier to visualize--so I prefer that space myself whenever possible). The most important thing is that colormode gets reported so other integrations know how to interpret the rest of the data that are reported.
Right; when a change is set to the Bridge (I assume that's what's happening--something, either the Hue app or another, sending the commands to the diyHue Bridge?), the Bridge should report back a colormode (assuming the bulb is of type Color or Extended Color--and maybe Color Temperature if any of those, for who knows what reason, happen to use xy instead of ct).
If you can summarize the algorithm they used, I would totally do the same as them. Otherwise, I've tried this and similar formulae I can find elsewhere (apparently used to be part of Hue's docs somewhere) with little success. I'll try to come back to this on my own someday, but it's not a big priority for me right now. I'm definitely open to providing options to interpret xy data differently in the meantime.
Yeah, that's similar to the one that I found.
Oh, me either. The only groups I'm using presently are for CT lights or to shut off a bunch of color lights (so even the level doesn't matter). The only reason I noticed is I brought in a whole bunch of lights to try out something and brought in their group too to reset them for testing. Otherwise I wouldn't have even noticed. So, need to work on it on my account. Just seemed odd to me so I thought I'd run it past you.
Basically, the DIYHue setup also has software for DIY addressable light strips run off a microcontroller. With one board you can break up a length of LEDs into individual Hue Lights so you can control them individually for color and brightness. I was trying to work out an animation for something I'm thinking of doing for my stairs, where it fades up lights in sequence on a delay. Great part...it worked the first time!!! But that also meant that what I was hoping would fill my whole Saturday and Sunday was done in about an hour. I needed to fill all that time somehow, so I started trying to figure out why this wouldn't work. 
Hi,
I've been meaning to try this app / drivers for some time because of the scene support and more advanced status updates for bulbs / groups. I decided earlier today to finallly start to move my accessories off my hue bridge and onto my HE, and I quickly realised cocohue was the way to achieve that.
I just have a few questions, some of which may have already been covered:
-
I started by movig a dimmer switch. Can you please advise on the best way to configure this along the same lines as the hue bridge? Is it to setup a single rule with a button device trigger and variable to allow for the cycles of scenes using the On button, button 1? Described in an earlier post on this topic. This also leads onto my next question...
-
When I press the On button I would like to trigger a different scene per mode, at least for the first press, the rest can be a set order of scenes. Is that possible? Or at least just triggering a different scene per mode in general. I will want to do a similar thing when I move over my motion sensors. I achieved this on the hue bridge by overriding (re-capturing) a "Current Scene" each time I went between Day and Night modes, then the Current Scene was what I activated on motion in the bridge rules. I was hoping to remove the need for the Current Scene if possible.
Thanks again for your efforts, both in developing the code and the time taken to help people on this thread.
Simon
