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

[Ccasj]

Pulling this out of the CocoHue thread since it's not really related.

I'm struggling to figure out how to use Rule Machine to return lights to a prior state after completing various actions. I want to use my inovelli switch to activate a Hue scene when turned on (in addition to simply turning on its physical switch), and then when I turn that switch back off, I want to return the Hue lights to their prior state (in some cases, this could be a scene, like during the evening - in other cases, this could be turning the Hue lights back off, for example the middle of the night).

I see that this could possibly be done via either variables or capture/restore, but I'm running into issues with both. For the variables, I can't figure out how to dynamically set a variable. Most threads I find show "device attribute" as the method for setting a variable based on current state (i think??) whereas what I see just appears to be manually setting the variable true/false based on my choosing. To be clear - I want to capture the state of Hue lights, when they were set outside of Hubitat, in the Hue app. I still have daily on/off automations for scenes in Hue app. So I don't have a logical way of setting the variable based on an action, rather, I need to capture/record a current state.

Then for capture/restore, I'm struggling with that one as well, because I can't figure out how to add both the initial trigger (ON) as well as the later follow-up trigger (OFF) within the same rule.

Essentially what I want to do is:

Inovelli smart switch ON: turn on; capture Hue group state; activate Hue group scene 'B'

Inovelli smart switch OFF: turn off; return Hue group to original scene 'A' if they were on, or turn them off, if they were off.

[bertabcd1234]

I'm not sure how familiar you are with Rule Machine, so feel free to ask if you need more specific help, but here's the general pattern I was thinking of. Reading your description above, unlike before, I think a "plain" capture and restore in Rule Machine might work, unless there are cases when you'd want to turn them off before when they were not previously off.

Trigger: Motion active

Actions:

Capture: Hue Light 1, Hue Light 2
Push button 1 on Hue Scene X  // to activate
Wait for event: Motion inactive and stays for 0:05:00
Restore: Hue Light 1, Hue Light 2

If you really do want to capture the on/off state and do something different in either case, rather than restoring the current state (which would also include being off), then you'd need a variable or some other way to track.

Note that I am hinting above that, assuming you have more than one Hue light in question, you'd need to capture then individually rather than using a Hue group device, unless all devices are set to the same settings to start (as the group has only a single state for all member devices).

[Ccasj]

Thank you again for the reply! I'm really not at all familiar with rule machine, other than learning some basic terms, and generally being familiar with if/then/else language.

I really don't need anything particularly complicated here, I think, but it's also a good opportunity for me to learn. I don't necessarily need to restore the lights to an exact scene, if that's not easy. What I don't want, is for me turning off my switch to cause the lights to stay on when it's 3 in the morning and I was just letting my dogs out (and therefore all lights should be off). I know I can set a time based conditional, but I thought it would be better to learn capture based functionality which might be more broadly applicable.

What I'm getting at, is that I don't mind setting the group (yes, 6 different lights, likely at different colors/brightness) back to some default scene, rather than necessarily the exact scene that it happened to be before I turned the switch on and off. But I do indeed want the lights to turn off if they were previously off. So I'm not sure if that means it's easier to capture every single light, then restore every single light, or if I can just capture that the group was "on/off" and use that as a conditional to set them to a default scene or turn off respectively?

To follow up on your general example, I'm lost on the wait part, since most examples I find are time based. In my case, I want the 2nd conditional action being another trigger - turning the light switch off. Does that make sense to be in the same rule? Or do I need to figure out another method with variables and settings two separate rules for switch on and switch off?

[bertabcd1234]

@Ccasj

, I'm lost on the wait part

This is just an action you can choose in Rule Machine rule actions. See: Rule 5.1 | Hubitat Documentation

@Ccasj

In my case, I want the 2nd conditional action being another trigger - turning the light switch off.

To get this in my rule, you'd want to switch the motion events out for switch events, but the general idea is otherwise the same. So, trigger on "switch on" and wait for "switch off."

@Ccasj

I don't mind setting the group (yes, 6 different lights, likely at different colors/brightness) back to some default scene, rather than necessarily the exact scene that it happened to be before I turned the switch on and off.

If you want to capture and restore the actual states, what I suggested above should work (although 6 might be a lot of LAN and Hue traffic at the same time).

If you want to just capture the on/off state and restore a scene or an off state instead, you could do something like:

IF (Hue Group Z on) THEN
  Set myVar to true
ELSE
  Set myVar to false
END-IF
Push button 1 on Hue Scene X  // to activate
Wait for event: Switch off
IF (myVar is true)
  Push button 1 on Hue Scene Y // activate "default" scene
ELSE
   Off: Hue Group Z
END-IF

Instead of Hue Group Z, you could also use Hue Light 1, Hue Light 2, etc. However, using a group device is more efficient and more likely to succeed, assuming you have a Hue group (room or zone) containing these individual Hue devices.

Note that myVar above is a boolean variable I assume you've created for this purpose. In this case, all you'd need is a local variable in this rule, though a hub variable would technically work (but is unnecessary since you don't need it anywhere else).

[JB10]

@Ccasj

I want to capture the state of Hue lights, when they were set outside of Hubitat, in the Hue app. I still have daily on/off automations for scenes in Hue app. So I don't have a logical way of setting the variable based on an action, rather, I need to capture/record a current state.

Would you be willing to bring all this into Hubitat? Anything the hue bridge can do so can Hubitat. By doing this, you would be able to track the state a lot easier. CoCoHue brings in Hie scenes as switches, which you could run conditional actions off of to get back to the correct state. You could also use a hub variable that gets change when each of these automations run. Then you just check the hub variable to set the lights back to their previous state.

[Ccasj]

So I tried the capture and restore, and it kinda works, but there's definitely a problem. For the life of me, I can't find any documentation on capture/restore, so I'm not sure if I'm doing something wrong.

The restore portion seems hit or miss. In my testing so far, if the lights were off to start, it seems to succeed in returning the lights to off every time. If the lights were on, I had it keep them on once or two (didn't seem like the right scene though), but most efforts it seems to just always turn the hue lights off regardless of initial state.

Is there some poll rate or time it takes to capture or restore? I know you said I had to to it on an individual light basis - I couldn't take find anything to explain why, or what exactly is being captured (all device parameters?).

[Ccasj]

I'm not at all opposed to that. I'm trying to just slowly migrate to HE as it's semi overwhelming. You say hubitat can do everything but I thought it can't really do Hue scene transitions over time, for example (my understanding is it's just a switch that must be transitioned instantly). Other things like natural light scene seems dramatically easier to set up in Hue, or setting up the dimmer switches. But I'm still totally willing, in the end it's probably a good idea if I can figure it all out.

Regardless, does that really solve the issue with variables? I'm struggling to find answers to that as well. Does the variable actually capture current data, or is totally independent to the actual device? For example, even if I bring my automations to HE, will the variable get out of sync if I go into Hue and manually change scenes or something?

[bertabcd1234]

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.

[Ccasj]

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.

[bertabcd1234]

@Ccasj

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.

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.

@Ccasj

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 afterward

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).

[Ccasj]

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

[bertabcd1234]

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.

[JB10]

@Ccasj

I'm not at all opposed to that. I'm trying to just slowly migrate to HE as it's semi overwhelming.

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.

@Ccasj

You say hubitat can do everything but I thought it can't really do Hue scene transitions over time, for example (my understanding is it's just a switch that must be transitioned instantly).

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.

@Ccasj

natural light scene

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.

[Ccasj]

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

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.

[JB10]

@Ccasj

I apologize, it's been a while since following up on this as we just had a baby this past week.

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.

[Ccasj]

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?

[JB10]

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.

[Ccasj]

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.

[Ccasj]

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.

[JB10]

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