Capture and restore not working

[JdThomas24]

I have a motion scene that captures lights and turns on switch
As follows.

Front door motion between sunset and sunrise.
Turn on front porch light
Capture shelf Hue and Kitchen group.
Turn shelf hue and kitchen group to red
After 3 minutes
Restore Shelf Hue and Kitchen group
Turn off front porch.

1- the capture and restore work occasionally but not very often. They just stay red
2- how do I time this rule out, for storms ?
Prevent it from firing when it triggers more than X amount of time?

[DubbyDad]

For starters, I'd highly recommend moving the "Between Times" predicate out of that first IF-THEN and into a "Required Expression", so the Rule will not even get evaluated outside of those times.

Next, let the other half of that IF-THEN clause become the Trigger. I'm only saying this because it's unclear to me what is the main trigger(s) that cause this rule to run. Could you screenshot that part of the rule and share it below?

Also, are you quite sure that the Rule has been firing at all, according to the Logs?

[JdThomas24]

Attached Screen Shot

The rule fires off and on. When people come to the door at night. The capture portion and restore portion is the problem. It doesn’t capture and/or restore.
Most of the time the Hue bulbs, Hue Shelf and Kitchen Group, just stay red
Another issue is the frequency of triggering --- We have had a few storm lately and it triggers all night long.

[DubbyDad]

It's a new day, so let me break down my additional input into three categories: The good, the bad, and the ugly.

The Good
Your rule works (almost too tell) except for the Capture/Restore part you're worried about.

The Bad
You didn't mention which driver/integration you're using for those Hue bulbs, but it's the consensus of the Community that CoCoHue: Hue Bridge Integration is the gold standard here, so try it if you haven't yet.
Your Hue subsystem may also benefit from having old/unwanted/forgotten API integrations removed from your Hue Developer account (if any), as a baseline.

WORTH READING (specifically portion about Hue bulbs) this paragraph

The Ugly
As a matter of Best Practices in RM5.1, I again feel compelled to push you in the direction of teasing out that IF-THEN construct, since it unnecessarily duplicates existing logic. For example, just by virtue of having been triggered, you already know that Motion == Active, so why test for that again 1 millisecond later with IF?

Ditto for what I said above about the time constraints. It CAN work how you've written it, but by relegating to Required Expression, you greatly simplify the Rule itself (no more IF-THEN) and relieve the hub of unneeded CPU load (no more evaluating the Rule during quiet hours).

Having said all that, it bears repeating that Hue bulbs sometimes don't do exactly what they're told in this ecosystem (set to a slightly different color temp, for example, or lag/fail when reporting on/off status, etc.). So I'll stand on the sidelines a bit until we're on solid ground vis-a-vis your chosen integration (CoCo).

Lastly, to stop any Rule from running rampant, you could very easily invoke a Private Boolean, as follows:

REQ EXP
Private Boolean == True

ACTIONS
Set PB = False
Do Stuff
Set PB = True with Delay of 00:xx (so Rule cannot fire again for xx secs/mins)

[bertabcd1234]

@JdThomas24

It doesn’t capture and/or restore.

Are you sure? I'd suggest enabling logging for the rule and then see what "Logs" say is happening when. My suspicion is that both are working correctly, but nothing in your rule seems to prevent re-triggering. So, consider this possibility: motion became active, your rule triggered, the states were captured (all good so far...), changed to red, then motion became active again within 3 minutes, causing the rule to re-trigger, re-capture the states (which are now red), etc. When restored in this case, they'll be red...just like you told it to do.

But logs will give the best clues as to the sequence of events that is happening. There are some ways to avoid this. You may also want to consider other ways to write this rule. For example, do you really want to wait 3 minutes after motion becomes active? Normally, you'd wait to wait for motion to become inactive (and possibly also some delay), thus taking care of the case where motion stays active teh whole time and the lights may turn off or whatnot befoe you expect them to. That alone won't address the original issue but is still something to consider.

[DubbyDad]

Agreed. Check Logs first. Then consider adding a WAIT FOR CONDITION action (with optional Timeout value) in the mix to postpone the Restore until Motion == Inactive.

[JdThomas24]

Logging all of this info and I will make some adjustments and report back..

[JdThomas24]

Added- as suggested -
Required Expression of Sunset to Sunrise - IT seems to be acting correctly ATM

Still trying to work out a TIME OUT when we have strong storms.

[JdThomas24]

This is what I came up with to prevent the Rule for firing prematurely. Im not sure if it will work on the 30 minutes wait event... We shall see, its storm season here so it wont take long for me to figure out it needs more tuning.

[DubbyDad]

Looking mighty good from what I see. Nice work, and come back if you hit any snags.

[JdThomas24]

I’m resurrecting this one.

I have come to realize that Hue bulbs don’t always care what you want them to do. Lol
This rule works in a nutshell. No more false alarms during storms. I have added wind speed to the required expression.

My only work around for Hue is to tell them to change colors before turning off. They refuse to capture and restore.

Using standard Hue build-in integration.

[bertabcd1234]

It's not clear what "not working" meant for you, but note that if "off," a capture and restore captures and restores only that particular attribute (switch, technically). So, if you set it to another color in the meantime, as your rule appears to be doing, they will indeed turn back on to this "new" color the next time you do an "On" command via some other means. That is why your workaround to set them back to white before turning off, if that is indeed the intent of your rule (again not clear), causes the outcome it does.

Another workaround is to turn the devices on (the next time) using a specific command like "Set Color Temperature" instead. This, of course, depends on the capabilities of the app you are using to turn them on (or whatever external system you may be using).

[JdThomas24]

The kitchen 1 and Kitchen 2 are OFF during this event. TheHue Shelf is on but on random color.

Im going to use the work around for now.. May come back to it but the work around will work..

Thank you for the inout on the OFF versus color.... That explains the Kitchen 1 and Kitchen. 2

[cuirbear]

Here is my experience with this.
I have the following rule setup for watching TV:

It seems that the capture and restore is not working properly.
If the Couch and Chair lamps are off, they appropriately turn on to a dim state, but they do not restore to the off state.

Looking at the rule, is there anything I am doing incorrectly?

[danabw]

What you describe sounds like there may be an issue.

To help w/determing where/what the problem is, turn on all logging for the Rule and the lighting devices, and then cause the automation to run, and post the logs of the rule and the devices. (You can filter logs by multiple apps/devices so you can grab logging screen shots of just the involved items.)

[cuirbear]

Here is the activation of the rule:

And turning it off:

Couch and Chair lamps are still on. They do write to the logs with on/off command.
(Both lamps are Lutron plug-in dimmers)

[danabw]

It looks like every time your plug reports power >35.0, the rule is re-triggered again and as a part of that process re-captures the state of the lights, You can see it in the first screen cap you posted...

You may need to set a T/F private boolean to keep the rule from re-triggering...I have something like that in a laundry automation that similarly waits for a particular power level below a certain level to be reported:

Tagging @bertabcd1234 for additional insights (he is way smarter than me).

[cuirbear]

Thanks for the input. I can see the issue now myself.
I have never created a Private Boolean before. Kind of hard to understand.

[JB10]

If you didn't want to use a Private Boolean, you could always use a conditional trigger. In this case, your trigger could be: Power greater than or equal to 35 (only if DreamView T1 is off). Since your rule turns on the DreamView, the next reading would not re-trigger the rule since the trigger is now false.

[cuirbear]

Thank you for the input.
What is happening is that the TV power is reporting more than once, thus causing the capture command to happen again.
I don't think that it has anything to do with the Dreamview (lighting) turning on or off.
With that consideration, how would I set up the conditional trigger?