I understand that this is a popular approach with the community for looping, but I want to reiterate that we don’t officially support looping and thus don’t have an official recommendation on it.
That being said, there are some general best practices that could be used here. 
I agree with the approach of using a ‘state stays’ as the trigger. Using true vs false as the target value shouldn’t matter here as long as you’re consistent.
Here’s a few thoughts (again, general concepts, not an official recommendation for looping):
- Use a ‘state stays’ trigger for the variable
- This automatically dedupes multiple events and has some inherent consistency features that are useful
- Keep your ‘loop’ isolated as its own minimal rule to prevent impact from other actions
- You’re already doing this in your case
- I’ve seen other examples where people have the loop and their device actions all combined together. In that case, a failed device action could kill the loop.
- You’re already doing this in your case
- Only have a single rule act on the ‘loop’ variable
- This minimizes the chance of other things inadvertently killing things or causing parallel loops (state-stays should prevent the parallelization)
- Minimize the use of delay actions in your ‘loop’
- Each time you use a ‘delay’, you’re effectively pausing the rule and putting it back onto the queue. In the event of high load, the system has some precautions in place to prevent DDoS / Overloads so some queued items may release later than expected.
- That being said, the ‘state stays’ gets queued too, but its on a dedicated queue with different thresholds
It sounds like there may have been heavy load at that time, so I’ve tweaked some of the overload protections to allow more items through the queues just in case. When we’re back in the office, we’ll take a closer look.