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)
