UPDATE:
As I watched the logs, I’ve discovered that it stopped working for 20 minutes, then just started working again seemingly not missing a beat. Is it just not working for those 20 minutes? Nothing else will trigger the “FALSE” in the variable.
Could you provide the log with “debug” checked in the filter?
Looks like the delay hicks up.
My first suggestion would be to turn it around.
Use $FiveMinuteTimer stays “true” for 5 minutes as your trigger.
Then Flow, set variable to false, delay a second or more and turn it back to true.
This way the rule isn’t “running” in the background, that should avoid potential rule-running issues.
@JKB121 I’m been seeing the same behavior in a couple of my rules since the updates and changes feature was added. It appears the delays are not being honored and the rule is being retriggered within the same minute. I went in and deleted my trigger and delay, saved, edited to add trigger (with on transition only) and delay back in and all seemed to start working again.
Looks like your rule also wants to run when the variable changes to true. Which seems to not always happen in sync. So the change to true, stops the rule from running when it already started the delay.
Not 100% sure, but it looks like something along those lines. I believe if you try it my way, you won’t see the error.
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.
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.
I have a rule set-up the way as I described above, it has worked for months now.
Last night around 17h30 gmt +2, it ran for the last time. I just now noticed the variable was set to “True” instead of false as it’s supposed to and what the rule says it did.
There’s no history of the variables stored afaik, so can’t check if anything happened to it afterwards. But it’s only shown on my desktop, so couldn’t be changed by any other dashboard… There was nobody at home at that time either.
I know it might be better as a request, but has there been a thought about storing a history for the variables?
It’s primarily used as an internal optimization currently (eg. for ‘state stays’), but internally we snapshot the previous timestamp and previous value for each variable when it’s stored in the database. I suspect it would be relatively straightforward to expose that information – though the bigger question is what interface would be reasonable and intuitive to do that with.
We don’t currently snapshot the source of what changed the variable.
And it sounds like you are also interested in some amount of user-facing history of the variable values (and I suspect ideally their sources too) which is what I believe the feature request would be for.
