SmartThings Community

Execution limit - scheduling tasks instead

(Aman Patel) #1

I ran in to the 20s execution time limit. I have a simple task that should turn on and off my espresso machine with appropriate pauses in between. You can see here: (for people who own a espresso machine that they need to clean every once in a while, this is veryhandy!)

def appHandler(evt) {
    log.debug "app event ${evt.name}:${evt.value} received"
    
    // repeatedly turn on/off the espresso machine with delay in between
 
 	backflush()
    pause(10000)

 	backflush()
    pause(10000)

 	backflush()
    pause(10000)

 	backflush()
    pause(10000)

 	backflush()
    pause(10000)
}

def backflush() {
 	theswitch.on()
    pause(7000)
 	theswitch.off()
}

// TODO: implement event handlers

Obviously because I am pausing for many seconds in between each backflush, this task only executes twice and then is killed by the SmartThings device. Is there anyway around this? Do you know if there is a way for my code above to schedule a few ON/OFF events and then delete the schedule after the backflush is done for 7-8 times?

(www.rboyapps.com - Make your home your butler!) #2

How is pause() implemented?

(Aman Patel) #3

pause(msec) is implemented by smartthings. It acts like sleep() call in linux for example. I could not file pause()'s api documentation, but it seems to work (some other threads also make reference to it). I think I might have to look in to scheduling here:

https://docs.smartthings.com/en/latest/smartapp-developers-guide/scheduling.html

Perhaps schedule a backflush to occur in 10 seconds, and then update a global variable. Once the variable reaches a predefined value (say 7 times), I can cancel the schedule (or prevent a new one).

(www.rboyapps.com - Make your home your butler!) #4

Interesting because I thought ST is against pausing apps as it’s supposed to be an event driven architecture and I suspect pause() is a blocking call which then adds to your execution limit.

The right way to handle it would be use runIn and daisy chain it with a state.counter to track how many times it’s run. It’s more overhead but you won’t run into the issues you’re facing with limits.

(Todd M) #5

Just a quick and not necessarily accurate thought but…could this be a network latency problem?

(Aman Patel) #6

Nope. I don’t have any network connections in my code. However the runIn() command will probably address my issue. Thanks all.

(Todd M) #7

I have not written any ST apps so pardon the naivety, but I was thinking this…

Local vs cloud

First, just to get this out-of-the-way, at the present time no custom code runs locally, which means nothing with core or webcore runs locally. In fact, the only things which do run locally are smartlighting (and then only if all of the individual device type handler is being used are also running locally) and a few bits of smart home monitor. That’s it. Not even routines run locally.

However, that said, some people have found that cloud-based operations run faster than local operations. I know that doesn’t make any sense, but has been reported by more than one person, so it’s just something you need to try and see for yourself.

(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #8

As @RBoy says… Use chained runIn()'s.

SmartThings’s execution limiter is very unsophisticated. It is based on real-clock time; rather than the more relevant resource measures of CPU time, memory usage, etc…