Rule Loop Failed - Fix and Alternative Approach

[Peter_Lin]

I’m using sharptools with Smartthings.

I created a rule ‘Greenhouse Temperature Check’. It uses variable $greenhouseloop as trigger to check a sensor temperature, and turn on or off based on the state of temperature. This runs every 10 minutes.

This rule engine works for 2 days, and then stopped. I did not make any change.

I check the rule engine and it is enabled. when it works, there is log file. there is no log file.

I restarted Smartthings hub v2.0. I reconnect Smartthings to sharptools.

What else can I try?

Thanks.

[josh]

It sounds like you are using your $greenhouseloop variable as a trigger in your rule and toggling the variable state to try to get it to ‘loop’. Keep in mind that this approach to looping can be finicky and is not something we officially support or recommend.

In general, it’s an anti-pattern to use looping in most cases. Where possible, it’s preferred to use event driven automations – for example, your greenhouse temperature sensors should automatically report their temperature updates and you should be able to use that for your trigger.

For example, you should setup a rule like:

Trigger: Greenhouse Sensor: temperature changes to greater than 80

Flow: Greenhouse Fan ▸ on()

And if you wanted to combine additional scenarios, you could use multiple triggers and then leverage Context Variables to determine what kind of action to take.

Trigger:

Greenhouse Sensor: temperature changes to greater than 80
Greenhouse Sensor: temperature changes to less than or equal to 80

Flow:

IF $context.event.value > 80

THEN
  Greenhouse Fan ▸ on()

ELSE
  Greenhouse Fan ▸ off()

That being said, there are some best practices you can follow with the $greenhouseloop approach:

@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

In your case, it seems like you’ve mixed the concept of toggling the ‘loop’ variable with other smart home platform commands – so if any of those smart home platform commands fail, that will cause the rule to fail before it toggles the variable back to true so it won’t loop.

[Peter_Lin]

Thank you josh. I rewrote rule engine to use greenhouse sensor update as trigger. It’s working great.