I didn't say that. You can do anything you want with them. But because of the essence of an asynchronous system, spinning the CPU waiting for something is a quick path to a dead hub. That's why Repeat Actions have a timer associated, to turn them into event driven things. In this case, the event is the timer. Remove the timer, and you just killed your hub.
While loops and repeat-until loops and repeat-n-times loops are tools for building sophisticated automations. The bring additional flexibility and power to RM. But, they aren't replacements for basic event-driven automations.
There are lots of possible examples of what these are used for. Make a chime sound every 10 seconds while a door is open. Send an alert every 5 minutes while some condition is true. Ring the bell 4 times for front door opening, ring it 3 times for back door opening, etc etc.
What not to try to do: Use a Repeat Actions in RM to wait for something to happen. Use a Repeat Actions or an IF-THEN action to replace a trigger event or condition of a rule. etc. These are actions to be run IN RESPONSE TO EVENTS that are the controlling mechanism of automations.
Okay...that makes sense. But isn't that the same thing as repeating a set of functions until a condition changes? I don't see how one is more of a resource hog than the other. For example, you have loop A chiming a bell every one minute until a door closes and loop B doing nothing but a 30 second delay until the door closes. Why is A okay to do but B not?
The way I see it one is potentially infinity happening when it just doesn't need to be until something else happens, the other is only happing for a period of time if or while something else happens but only every X seconds. Back to front
Because I don't want it to happen EVERY time the door closes. Back to my previous example, I don't want the outside light to turn off if the door closes when I'm leaving...only when I'm arriving. So, the trigger for the sequence starts with the trigger of motion being active outside vs the trigger of the door opening.
Complex automations are only possible if you can control the sequence of events and allow for the next trigger to take place. Like I said, probably possible using rule 2.5 with PB but even thinking about it gives me a headache.
In the simplified example, it would be. But what I'm talking about in the broader context is a sequence of event driven actions. The sequence starts, does A, B, and C then stops until X happens, then does D, C and E then stops until Y happens and then does F, G.... Doing all of that with separate rules enabled and disabled with PB is going to get VERY messy if the sequence is interrupted. If it's all in one rule, you have the escape based on Truth Change to the triggered rule at the top.
To me THAT is complex automation.
Ok. I see. Well, we are just at the beginning stages of this capability. Given time I have no doubt @bravenel will be able to optimize how that function works.
We need an inference engine to watch what weāre doing and tell us it doesnāt make sense before we make those mistakes. We could call it B.R.U.C.E (Bring Rules Under Control Engine)
No, not for every action. That doesn't make sense either. But one of the things that I am struggling with now that I have a lot more rules is that when I want to change something, I have to go into 20 rules to change it. That's really tough to manage. But if we were able to keep things within the same rule, then you only have one to go into. My example with the light for example, if the contact sensor for the front door changed, that would be 3 rules I have to go into to update rather than one. If it accomplishes the same thing and doesn't cause a lockup, I don't see the harm in doing it differently. After all, options are good, right?
Another thing that would help with the number of places to make a change would be Time Variables. For example, if i had a time variable set to Sunrise plus 20 minutes and then could write rules using that variable, if at some point I decided I wanted to change that to sunrise plus 30 minutes, I would only have to do it once vs in a dozen or so rules.
rather than a WAIT WC had a condition of if WAS. So in @Ryan780 example it could be if mode WAS away or presence device WAS away and door closes turn off the light. That way its event triggered?
What's particuarly wrong with WAS. I was (he he!) thinking about this at my kids soccer match the other day, and came to the conclusion that WAS could be acheived in RM with cancel on truth change and at worst a virtual switch.
Maybe in RM 9.0. 
