So I have a rule that I use as a 5 minute timer. It’s pretty simple, but keeps “breaking”.
Here’s the rule:
Simple description: Every 5 minutes a variable is changed to False. I have “stuff” that uses this variable to check things, or do things.
It runs fine for a while, then just stops working.
Here’s the logs for the last hour. Runs fine every 5 minites until 6:50, then it is stuck.
Is there a better way to create this timer rule? Is something causing this to stop running? Does this rule run locally or on SharpTools?
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.
Here is the log with Debug
Where does the delay “run”? Local or cloud?
@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
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.
Thank you all very much. I’ll make a few of these changes and see how it goes!
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?
This would probably be best as a feature request.
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.