runIn() not working correctly

I’m currently working on a smartApp that uses runIn(). I’m setting it for 5 seconds, but I’m seeing through logging and observation that it’s not very consistent. Sometimes it runs in 5 seconds, sometimes it’s 20, 30 or more seconds.

My question is, has it always been this inconsistent, or is this something related to the last firmware release that’s screwed up so much for some people?

You may want to confirm with the documentation but I think that is a best effort kind of thing. The shorter the time less likely you will be close to the time you want. I think the documentation states to try to be 1 min or more.

1 Like

Quite frustrating. I can change the 5 second one back to a pause, I guess, but I was seeing inconsistency with it as well. I do need a runIn for a 90 second timer I have, that one does seem more consistent. The joy of running in the cloud, I guess.

runIn() has never been intended for less than 60 seconds.

Figured that out after reading the full documentation for the method as suggested by Mavrrick.

Given that pause is only good up to 20 seconds, what’s the most reliable way to delay an action for between 20 seconds and 60 seconds?

The maximum execution time of a SmartApp is 40 real-time seconds (and max 20s per statement).

Delays of the duration accuracy granularity you want are not suitable for the SmartThings platform (well… Until you can use the new API).

Think you could always run into problems as long as you are running on a shared resource. I wonder if something like this would work better over a dedicated local server using the new Smartthings API’s

1 Like

Could you tell is more about what the SmartApp is intended to do overall?

With context, we’re more likely to be able to make useful suggestions…

2 Likes