Using a variable or capture to return Hue lights to prior scene?

Two things I can think of that could be happening:

One:

As you mentioned, there could indeed be a polling-based issue. The built-in Hue integration relies exclusively on polling; CoCoHue does by default but can also use the "experimental" (actually think they're considering it prod-worthy now...) v2 API for instant status updates, which works aside from some odd cases where I think Hubitat's websocket interface has some problems. You can try enabling that if you haven't already.

You can verify or sure by checking the device detail page for the problematic devices before capturing. If "Current Details" (towards the top or top right of the page) isn't right, Rule Machine -- or any app -- won't capture the correct state either. This represents what the hub knows.

Two:

Hubitat works with the so-called hue/saturation (HSB or HSV) color model. Hue does too, but it actually supports a second color mode, xy (or CIE XY). I've noticed the API spitting out xy values more and more lately instead of hue/saturation values. Conversion is difficult, and neither the built-in integration or CoCoHue attempt it at the moment. (There is a third model Hue can use, CT or color temperature. This is fine but can also be represented in xy, which they might be using more since it's capable of representing any color or color temperature.)

If your bulbs are only reporting xy values, symptoms will be similar to the above -- "Current State" values that do not align with reality. Unlike the above, however, a poll will not fix it. (Actually, in some cases, it might, since CoCoHue and built-in polling still uses the v1 API, which normally also gives hue/saturation values, unless you're dealing with third-party bulb that don't report it back under any circumstances...)

To fix:

Seconding the advice above, making the changes from Hubitat would avoid either problem above: the first because even with polling, either CoCoHue or the built-in integration will report new states back immediately after an apparently successful command, even without waiting for polling. (The issue is exclusive to changes made outside the hub.) The second problem is avoided because Hubitat will only send CT or hue/saturation values and will generally avoid the xy problem.

Just a couple guesses and possible solutions; looking at the current states may give you a good idea of what the problem might be and where to start troubleshooting. If all looks good with both of those, there are more things you can still try.

Ok so did some experimenting. The incorrect on/off state was just me testing too quick. Seems the poll or refresh rate or whatever is around a minute to see an accurate state in hubitat. Not really much of an issue in actual usage.

The real problem I'm seeing is incorrect color after a restore. Every time it restores to a highly desaturated version of the original. I check the device details of the bulbs and wait until they are showing as accurate. After capture and restore, the Hue and saturation changes. If I check it out in the hue app, it appears to be putting it into the "white ambiance" color wheel instead of the RGB. See before and after below.



I tried setting a scene through cocohue instead. Each light ends up reporting as CT mode still, and even through this method, still the capture and restore doesn't work.

I tried setting individual lights through cocohue using the "set color" command - this shows as RGB in the device details, and the capture and restore does work afterwards.

From your screenshot, the resotre actually appears correct as far as Hubitat sees. Note that it sees "colorMode: CT" (color temperature) and correctly restores that color temperature.

I know I said something about "doing things from Hubitat" above to avoid the problem, but activating scenes is still one exception -- just like when done via the Bridge, as I mentioned above (and all CoCoHue really does is tell the Bridge to activate the scene), the bulbs getting stuck in xy mode is still an issue. I believe both the built-in interation and (I know) CoCoHue look at the CT values in this particular case due to the issue I mentioned above with conversion, and at least CT (which for most bulbs does still seem to get updated when appropriate, even if xy is the only guaranteed value) normally seems to be accurate and at least gives you something.

This is what I'd expect; note that Hubitat sees "colorMode: RGB" and, presumably, has the expected hue and saturation values (a hue of 0 is red, saturation 100 is maximum).

So, at this time, is abandoning my Hue scenes the only workaround to get a true backup and restore? And would that mean simply setting every bulb individually through hubitat?

And then it sounds like the other related option is using variables, and instead of "restoring" I'd have a conditional set scene/scene off depending on the variable state? But in that case I need to do basically everything within hubitat to avoid the variable getting out of sync?

Thanks again for all the help

Not the only workaround; if your scene are all color temperature, those could still work, or if you set color from Hubitat directly, that would etilll work. Hue scenes with color are the biggest problem.

But it might be the easiest, depending on your setup.

I completely understand and was in the same boat about a year ago. We might want to start from the beginning. How are you currently using the Hue Bridge? Is it just automations and maybe the Natural Light scene? A good starting point is getting Hubitat to activate scenes at your desired times.

This is generally true, but is easy to work around. With Hue Scenes, they generally come on once their pushed whether from the Hue App or via Hubitat. When someone creates an automation and adds a fade time, the Hue App adds a transition time parameter to that scene only when the scene is activated via the automation. Selecting the scene from the room/zone still works the same way. It is possible to modify the scene to add the transition time parameter via a third party app or interacting directly with the API. @bertabcd1234 has looked into it for CoCoHue, but it is easier to just modify the scene directly. To give an example, at 7:30pm my family/dining/kitchen combo transitions to tropical twilight over 30 minutes and the master bedroom fades down to 2000 over an hour. Hubitat controls the activation, but I modified the scene. If you want to learn how, just let me know.

The natural light scene just selects scenes at defined time periods. Room Lighting can handle this and transition the lights between the color temperatures when the time periods shift. I use three Hue scenes (Read, Concentrate, and Energize) that shift throughout the day based on a virtual device. Others use an app like [RELEASE] Day Lights - an iteration of Circadian Daylight to fine tune their lighting and adjust it every 5 minutes.

This is why I go back to let's start from the beginning. If we can get most of your Hue Bridge stuff on to Hubitat, it will help significantly with this question.

I apologize, it's been a while since following up on this as we just had a baby this past week. I figure getting the Hue setup in Hubitat could be a good project for me to work on in between naps :slightly_smiling_face:

There are quite a few things I'm still not totally sure of. I know one basic thing I can do is start moving my Hue app automations (just turning on/off at certain times) over to Hubitat instead. I know I can do this via Rule machine or Basic Rules and cocohue for scene activation. I know there's also the Room Lighting app. Any suggestions? It seems easiest to just do basic rules to say turn on/off scenes at various times, but I'm not sure if there's anything I'm missing out on by not using the Room Lighting app. And is there a reason I need to bring over every single light through coco, or for what I'm doing so I simply need my groups/scenes?

Other things I want to be able to do, is scene transition time (I know you mentioned that, still confused on it), as well as linking in Google assistant to be about to control the lights. And I guess at this point maybe some answers to previous questions will help me decide whether to use something like that circadian rhythm app or just set up a few basic scene transitions throughout the day.

Lastly, I want to make sure I can easily kill these automations when I'm on vacation. I feel like this is something I can implement later (via modes?) once I'm all set up, but just mentioning it now in case that's wrong and I actually need to factor that in from the start.

Don't ever apologize for this. Congratulations on the new baby!

Personally, I would start simple. Bring into Hubitat any bulb, group, zone, and/or scene you want it to control. I do not have every individual bulb in Hubitat since I would rather control via groups/zones/scenes, but I do have a few that I need to control individually. I also have brought in my Hue button devices to help with control too. From there, use basic rules to get the lights activating and turning off how you want.

With this said, what type of automations are you using in the Hue app? If you provided a list, we could help suggest how to do them in Hubitat before moving to more advance things.

Finally, the rest is fairly simple (scene transition is a little more advanced but can be done). Google Assistant and Vacation mode/switch is not a problem.

My list of current Hue automations is incredibly basic. I turn on Natural Light scene in the morning for my living room lights. I also turn my patio lights on and off in the morning and evening based on sunrise and sunset times.

The only thing I really need help with, I think, is transition times. I understand I can set those in Hubitat if I do things on an individual light basis, but I'd prefer to use my Hue scenes since it really seems so much easier to do the initial scene setups in Hue. I was also reading through this party apps I can set scenes to have an inherent transition time, which I think is not ideal either. Any other options or is that pretty much it?

Can you post the scenes (Read, Concentrate, etc…) and time periods you are using for the Natural Light scene? What is the transition time between scenes being used in the Hue App? Finally, how are you turning on and off Living Room Lights?

Basically, Room Lighting can handle this, but the setup is going to be based on the answers to those questions.

To be honest, I was going to change the natural lighting once I understand this all better. I'll post what I have now, but the way Natural Lighting is set up by default the changes are a little bit too quick and abrupt. I was thinking maybe I'd look into that circadian rhythm app, and also adjust the scenes themselves to add a bit of color.

Anyway, for now, I'll just copy what I have.

Natural light scene. Transition time set to only 1 minute, which, now that I realized it, I've changed it to 15 minutes.

All of the read/concentrate/relax scenes are just the default Hue CT values.

As for control, I have a few Hue dimmer switches. My wife and I also frequently use the app to adjust scenes or brightness. I also used to use Google voice commands, but I disconnected that while I was figuring out the smart hub setups.

I did some more digging and maybe figured out the solution (or a solution) that I don't hate. I didn't really understand hubitat scenes and how easy it is to do a scene capture. So it seems I can just set up my Hue scenes in the Hue app, then capture it to "copy" that scene into Hubitat. From there I can set up my automations of the Hubitat scenes (instead of the cocohue scenes), and also set up "Scene transitions" into my automations to fade from one to another without needing a fade time on the scene itself.

Anything I'm missing there? I didn't have a chance to actually set it up yet, but figured I'd reply back if it might save someone the time from explaining the same thing.

I’ll have some more thoughts later, but this could work. One thing that might help is knowing the Hue scenes in Kelvin:

Relax is 2,250 Kelvin
Read is 2,900 Kelvin
Concentrate is 4,350 Kelvin
Energize is 6,400 Kelvin

1 Like

So going back to my original issue from start of thread plus the recent discussion - I tried testing all the built in Hubitat scenes to try to get the patio light capture set up. With Scene Capture and cocohue, I'm still getting the issue where hubitat only captures CT mode on the lights. I guess scene capture is the same as capture within rule machine? Makes sense.

So I deleted cocohue and did the built in Hue hub integration. Scene capture works perfectly to easily copy scenes from Hue to Hubitat. I then reset up my original rule for capture and restore, this time using the Hue bulbs through the Hubitat integration - now it works flawlessly and restore lights with their actual RGB values.

Now I just need to set up my Scene transitions and the natural light copy. So I guess it seems like using the built in hub integration would've been better for me to begin with? I'm not understanding the benefits of cocohue especially with the limitations I'm hitting. The native integration is getting me proper RGB captures, is fairly easy to port over scenes through the Scene Capture app, and I can set up Scene transitions as well. Anything I'm missing or should I just proceed with setting things up like this?

How did you set the lights to these states in the first place, and what does Hubitat report for these devices under "Current States" on the device detail page for each? That's all any app would know to "capture," regardless of what integration you are using. It sounds like you're running into the XY color mode problem we discussed at length above. Different integrations may handle this differently as the hub doesn't have "native" suport for this color model.

Yes, this is the same issue we are discussing a while ago. However what I'm finding is that the built in Hubitat Hue integration is pulling the rbg values even if I'm setting the lights in the Hue app to start (where cocohue was only seeing CT). This allows me to create scenes in Hue app then copy to Hubitat with the Scene creator.

I guess what I forgot to try, and what you alluded to, is I never tried activating a cocohue scene and then trying a capture from there. I'm guessing that would work as well - though I can't think of a reason to do so at the moment since generally the built in integration seems to be playing nicer with more flexibility if I ever manually set things in the Hue app.

Are you only bringing into Hubitat individual lights? I wonder if there is something using polling only versus the eventstream and individual lights versus groups/scenes. That's the only thing I can think of that might explain the differences.

As for this paragraph, what you are finding is that there are many different ways to do things in Hubitat. Personally, I do not use capture and restore. I bring in my scenes through CoCoHue and define what happens to the lights based on Room Lighting and Rule Machine. For instance, my outdoor lights are controlled through Room Lighting on a sunset-30 and sunrise+30 schedule. They are on the tropical twilight scene and adjust their level based on time periods. However, my outdoor motion sensor rule is housed in Rule Machine. Motion activates and it turns my lights to the Concentrate scene. After 5 minutes of inactivity, the rule turns on the Room Lighting Activator device that resets the lights back to their appropriate tropical twilight setting. This is similar to what you want to do, but without the Capture and Restore.

2 Likes

Ultimately, what's likely happening is that your bulbs are getting put in xy mode, which in my experience either scene activation or color manipulation from the Hue app does. Apparently, CoCoHue handles this one way and the built-in another, though in my previous testing it was the same (assuming CT; maybe it's really whatever the last mode was and I have mine in CT most of the time). In any case, with this kind of manipulation, you're likely to find some scenario eventually that won't work for what you want in that specific case with either integration; setting color from Hubitat is almost a ways better if you can.

1 Like

Ok so this is really interesting. Can you elaborate on this bit?

So basically you have one rule that activates another? If for example you have lights on from 7-10pm and your above time activates your room lighting at 8pm, it activates your tropical twilight scene appropriately?

I actually like this approach much more. Sounds like you have normal lighting routines in room lighting and then anything more complicated goes in rule machine?

I'll have to experiment with that - seems like this also does what I want but allows me to go bank to cocohue, bring in my scenes directly, and avoid the whole capture and restore deal.


Sure. This is my every day Room Lighting instance for my outdoor lights. To keep this post somewhat short, the time periods are (1)sunset-30; (2) 11pm; (3) 4am; (4) sunrise+30, Lights come on at sunrise-30 at 100%, they dim to 25% at 11pm, go back to 100% at 4am, and turn off at sunrise+30. The Means to Activate/Turn Off tells you how Room Lighting turns on and off. The adjust light option means that Room Lighting will automatically change with each time period. The activate even if partially activated is the key to my Rule Machine rule for motion. That option allows my motion rule to change the lights, but then go back to Room Lighting control when it "turns on" the activator device.

My rule for motion is fairly straightforward:

Triggers
Motion active
Motion inactive and stays for 5 minutes

Actions
If Motion active, turn on Front Yard - Concentrate scene
Else, Turn on Front Yard Every Day Switch (Room Lighting Activator)

I bet with Room Lighting and/or Rule Machine, we could probably find a solution that does not required capture and restore. What are the time periods for your front lights and what scenes do you use? I see that you have an Inovelli switch, so this should be fairly straightforward to create.