Repeating rules stop firing after several hours

[josh]

@Scott_Turner

The second two images show the final log entries of both rules when they stopped working this morning around 6:51am (I took the screenshot at 3:46pm and those were the latest log entries)

From your original rule logs, it looks like the last action was the on() command at 6:51:51 but then the turn off rule (which is triggered by the on event) never received the on event. I would check the SmartThings logs to make sure that the device actually turned on and emitted the on event.

@Scott_Turner

I have included the details of the rule in this screenshot (I’m new so can only include one screen shot):

It looks like your community level already increased, so you should be able to post more images now. If not, PM @support and I can manually increase your level.

I’m glad to hear that the new rule is working for you. That’s odd that the $OneMinuteLoop stays True for 30 seconds trigger wasn’t working reliably for you. If you want to revisit that by setting up another rule and sharing the relevant logs, I’m happy to take a closer look at it.

While we don’t officially support rule looping at the moment, there are a few best practices you should consider:

@josh

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

For example, I noticed you have device logic in your rule loop. If the device command fails to send for whatever reason, that risks the loop stopping altogether.

–

Can you share more details about why this rule needs to loop? I thought I read that it was related to knowing the status of the gate, but I don’t understand why the gate switch has to turn on and back off periodically?