Sleep() and/or longer timeouts with Hub 2.0?

Developer Programs Writing SmartApps
1

My latest project is a Hue-based notification SmartApp.

Part of it includes turning red to indicate that a door is open and then changing to green when the door closes. Currently, my only option is to do a runIn(60, …) which makes for a very long and somewhat random length notification.

Since Hub 2.0 will be doing most processing locally, is there any chance we could get access to groovy’s sleep() command or have an app timeout length of longer than 20 seconds?

Alternatively, I could loop through a bunch of slower commands as a sort of no-op, but calling that a hack is beyond generous.

1 Like
2

I think we can expect better scheduling-related functionality in the future, both with hub v2 and other platform improvements planned.

I don’t know that we’ll open up the sleep() command, but if we do we will be sure to communicate that out.

3

Thanks, @Jim.

I totally understand restricting sleep() on the cloud platform, but maybe give us access to a wrapper function that only lets it work if it’s running on a local hub?

1 Like
4

I fear that SmartThings would be opening up a huge can of wormthings if they introduced anything that has a fundamentally different semantics when running locally vs. Cloud.

5

You’re right, of course.

So while I’m making architecture decisions for ST, how about a flag for SmartApps to force them to run locally?

6

Opening an old thread, I agree that there needs to be an option to sleep or pause etc. runIn is a major problem since ST limits only 4 schedules at a time. Some apps could possibly have 5 or 6 functions which are called using runIn and in a potential condition if they happen to occur together the apps will stop working reliably. Either increase the limit to a higher number (say 100 or so) for runIn or provide access to alternative mechanism for small delays, say upto 10 seconds.

1 Like
7

+1.

I’m writing a service manager app and I need a way to let the code wait for a few seconds for the cloud service to update.

@btk, did you find a reasonable workaround for this?

8

If it is really only a few seconds and your total time is < 20 seconds, then just busy wait (ie, a while loop that keeps checking the time).

Very inefficient, but it definitely works and seems to be the only available option for the “few seconds” time range.

9

Yep. That’s what I ended up doing. It’s really the only way available.

10

Thanks guys!

So, something like this perhaps?

def mywait(ms) {
	def start = now()
	while (now() < start + ms) {
    	// hurry up and wait!
    }
}

Would you recommend putting anything inside the loop?

11

Nope. The conditional expression is plenty of useless work.

12

Personnaly this is how I do it:

def count = 0
    while(VariableFromAnotherLoopOrEvent != true && count < 19){
    count++
    log.debug "wait($count)"
    
    }

19 iterations because beyond that ST forbids it this gives a little time for a loop to finish before it is triggered again by a different event

the debug matters because it takes some time. The longer the debug, the longer you make your loop wait before ending