Hello HTB oO,
thanks for the update, describing you current rules. That is a good point to start.
Nobody knows why philips did not include a 'flash light once in a specific color' effect, and why it is not allowed to set a color for a light which is turned off. That is why we may have to build rather complicated workarounds.
But on the other hand, your use case is nice to learn a lot about most parts of Hue rules and its parts.
Let's first try to improve your existing rules, by introducing a memory sensor (which we will anyway need later) to also reduce "redundancy".
It is not few work, but just try to follow it step by step. I hope it is easily understandable, so you can use the same method also for other use cases in the future. (Because I don't have a device with an english OS here, I hope my translation of the terms is not so wrong. And as this was recapitulated from mind, I cannot give a 100% guarantee, but still am optimistic that it will work this way).
1) Create a memory sensor for numeric values (should be in an "accessories" section) and change its name directly afterwards to e.g. "OUT, MotionWhenDark"
2) Clone the first rule. When you tap on it, there should be a menu item to do so. (The copied rule should appear shortly afterwards, and is disabled, which is okay for now.)
3) Open the original first rule and remove the condition: Living room = "All lights are on". It then has just the conditions which are identical in both of your original rules. Remove the existing actions and just add one action, to store a numeric value into the previously created memory sensor, let's say the value 1.
4) Now modify the copied rule. Remove all conditions, except: Living room = "All lights are on". Add another condition for a numeric memory sensor (select regular condition here - a trigger will be added later). Chose the sensor "OUT, MotionWhenDark", scroll down to set it to "equals", and insert 1 in the number field. When going back then and saving the rule afterwards, you should be asked whether a trigger condition should be added. Select the memory sensor as the trigger. Doing so you decide that the rule should be evaluated when the memory sensor is updated with a value of 1 (in contrary to another way for interpretation: the sensor could already have a value of 1, and the lights being turned on afterwards). Activate the copied rule afterwards.
At that point, we did a bit of work to ... just have the same behavior as before. But don't be sad, the benefit of this 'refactoring' will come soon. You could name the first rule to "OUT, DetectMotionWhenDark" and the copied one to "OUT Motion, LR on, blink red". This is just an example - having a systematic naming schema (which has to work for you!) helps a lot when the number of rules rises, as the rules are usually ordered by their names.
Maybe you already have an idea what comes next: Improve the "All lights are off" rule.
5) Do the modifications like in step 4 above, but just for the "All lights are off" rule (and using "off" instead of "on"). It should afterwards still work the same way as before.
Now we begin working on the real problem, by splitting it to individual steps:
- store the lightstates into a scene (when motion is detected, but before the blinking)
- do the blinking
- apply the previously saved scene (which could also be holding the state "all lights off" - just as a remark)
In the next step we will use the possibility to delay execution of rule actions. Before doing so, you may clone the affected rule (for having a rule with the same conditions later, without much work - deleting parts of cloned rules is in most cases easier than trying to create a new rule and manually adding the required items, identically).
6) Modify the rule which I would refer to as "OUT Motion, LR on, blink red" (after having created a clone for future usage). Tap on the automatically created trigger condition which should be labeled like "sensor state updated" to modify it. Scroll down then to set the mode to delay, with a value of "00:00:05". That is more than enough time to store the previous state of the lights to a scene (in another rule) before blinking. And you should be able to try out and notice the difference to a rule without delay. Got it working?
7) Create a new scene for storing and restoring the Living room lights' states. Just select the relevant lights for it (or a group containing those lights) and proceed to the point of naming the scene - you can choose colors for testing the scene, but there is no need for it, as the scene will be automatically updated by a rule later. The name for the scene could be like 'LR, storedScene'.
8) Modify the cloned rule, which does still have the regular (not delayed) trigger. Delete the existing actions, and add one action 'store light states to scene'. Select the previously created scene. Activate the rule, and name it accordingly. The scene should now be updated with the current state of the lights whenever motion is detected outside (while dark, and LR lights are on).
Now let's check again the required steps. You still need to recall the stored scene after the blinking has occured. There are several possibilities to do so - but it is not working to just do it in the existing rule "below" the blinking part. Below does not always mean "after", especially for longer lasting operations. The rule just "tells" the light to blink and proceeds to the next step without waiting. The same is true when you start a timer in a rule: the rule does not wait until the timer is elapsed!
I believe you will be able to complete this on your own, in one of the following ways:
- Create a timer with 2 seconds, which recalls the stored scene as action. Start this timer "below" the part with the blinking. If this works, change the timer to 1 second and try if that works better/worse.
OR
- add an action below the part with the blinking, to set the memory sensor "OUT, MotionWhenDark" to a value of 2 (="prepare scene recall"). Then you can create another rule which reacts just on this value change, again with a delay of 1 or 2 seconds in the trigger, to then recall the scene as "simple" rule action without using a timer, and set the sensor "OUT, MotionWhenDark" to a value of 0 (="finished").
For this use case, the second way would probably not have advantages over the first way. But for other ideas it may allow establishing a state model, with well defined transitions, but is probably a bit more complicated and requires further work to get it right. (Think about a traffic light, which goes from "red" [0] via "red+yellow" [1] to "green" [2], and then via "yellow" [3] back to "red" [0] - and usually no other ways.)
As this already got a bit longer, let's take a break here and first see how you get along with it. In case I forgot something or you get stuck at a point, feel free to get back and ask.
Kind regards,
Marcus
P.S.:
HTB wrote: ↑Fri Feb 07, 2020 8:18 pm
TIA is the acronym for "thanks in anticipation."
Fun fact: our former english teacher (texan) told us that many germans use 'thanks in advance' - and that it is wrong (because no native speaker would say so). But as far as I remember, he offered no alternative.
Your TIA sounds much better, so thank you for solving a mystery. ^^
BTW I am HTB, TIA is the acronym for "thanks in anticipation." 
However apologies for the confusion as I'm aware this is not primarily an English language forum.
