That’s unfortunate - all I wanted was a way to refresh a single thermostat so a rudimentary SmartThings automation could be executed correctly on very infrequent occasion during the winter months.
I can’t bring myself to pay an annual fee for just one custom variable of very limited use.
So I got rid of the variable and simply made a sequence of rules to refresh the thermostat, each one 15 minutes after the previous one between the hours of midnight and 5:00 am. That’s all I really needed, and I avoid any fees.
You can also trigger on other events, such as motion, lights changing, etc to get you around the variable requirement. I guess it depends on how often/when you need it refreshed.
@Sgt.Flippy_PJ , this is brilliant! Very elegant solution!
It solves a pretty interesting problem for me. I am using smartthings & sharptools as a security system. With this, I am able to have a heartbeat service that checks the online status of my hub every minute (using a HTTP action). As soon as the hub is offline, I will receive a pushover alarm on my cell.
I spoke too soon. I noticed that the rule execution stopped after some time for no apparent reason. The log file just stops after a while after a series of clean executions. @josh is there any type of limitation by any chance how often a rule can be triggered?
What do your rule logs say? If you ran into an execution limit, that would be displayed in the logs. It’s 200 executions per rule per 10 minutes at the moment. It’s much more likely that your rule ran into an issue which didn’t allow the second part of the ‘loop’ to reset. While I don’t necessarily recommend building a looping pattern like this, if you are going to do so, it’s better to keep the loop as its own separate rule and keep it as simple as possible to avoid any potential side effects from the rest of the rule logic (especially something like an HTTP action where there’s potential for timeouts and things of that nature that could cause the rule to error out).
Hi Josh,
I have several timed loops that I use for polling devices and updating configurations. Every once in awhile one of the loops will stop running. Is the 200 executions you refer to a rule running?
Per rule. And the rest of my original comment still applies… the design of how the variable is looped is critical. If you have other actions within your rule, if any of those fail and the rule doesn’t run to completion, that can break your rule.
Thanks. I was not aware of the 200 execution limit. My loop only sets the loop variable, nothing else involved. Is there anything else on the back end which could cause the loop to not execute?
My rule is fairly simple. It executes once / minute. Far less than the 200 / 10 minutes. However, I do make an HTTP call as a part of that rule. While the logs do not show any issue, I have changed the design of the rule as follows. Now i believe the rule should still execute even if the HTTP call fails.
I have a few loop timers (5, 10, and 30 min) that I had been using for about 8 or so months using the set variable/delay logic described above. These had been working somewhat reliably until recently where they timeout at some point during the day and I have to manually restart them by resetting the variable status what seems to be daily. Has anyone else had this issue?
Thanks @Nezmo - Do you have a good work around? I was considering building a rule to stop and reset these in the middle of the night but was hoping I was just overlooking something simple. @josh any insight? -Ryan
While the approach used in this thread is popular with the community, it’s not something we officially support since it doesn’t have the reliability we would expect. For example, if there are other actions within the rule and those fail, then the rule can abort before it gets to your ‘loop’ variable.
We’ve been working on some pretty significant platform updates behind the scenes and one of these is a new scheduler mechanism. As part of that scheduler, we are considering introducing native ‘loop’ functionality. We still don’t have the details ironed out and I still have some hesitation as looping is generally an anti-pattern when event-driven rules can accomplish the same thing.
I’d love to hear the community’s use-cases for looping so I can better understand them as we consider a first-class looping feature. Please share if you have one.
We are working on identifying the impacted rules so we can automatically reschedule them. In the meantime, if your Timer Trigger rules were impacted, you can re-save them which will automatically reschedule them.
I’m asking what the use-case for a loop is that isn’t better suited by an event-driven approach? Can you tell me about the rules you are creating that need to loop rather than being triggered by an event?
I’d love to hear the community’s use-cases for looping so I can better understand them as we consider a first-class looping feature. Please share if you have one. 