Bug Report: runIn function fails with delay < 60

General Discussion
1

For the lack of a better place to put it, I am posting this here:

The runIn function does not work as expected, if the delay (in seconds) is below 60.

Consider this simply app:

preferences {
	section("Title") {
	}
}

def installed() {
	log.debug "Scheduling someHandler..."
	runIn(15, someHandler)
}

def updated() {
	
}

def someHandler() {
	log.debug "In someHandler..."
}

This fails with the following error:
"Cannot invoke method size() on null object"
Note, that there is no stack trace given, so in a real-wold scenario this took me longer than it should to figure out (all “printf”-debugging).

The documentation of the schedule function mentions that the invocation frequency cannot be higher than once per minute. According to the documentation for the runIn function, there is no such limitation.

Also, note that the official Smart Security SmartApp operates under the assumption that the delay can be less than 60 seconds, in order to delay turning on the siren after the strobe light. Currently, this means that anyone out there who has this delay set to less than 60 (app preferences) will never have their siren go off. Seems like that could be bad.

Mentioning @duncan and @urman (sorry guys) to get some eyes on this and advise. Thanks!

2

woah! Ok so here’s the deal.

1st - Super sorry :frowning:
2nd - We’re going to remove the restriction temporarily
3rd - We’re going to send out an email to developers or post here about the change and instructions on how to fix it.

3

Cool, thanks for jumping on this so quickly.

4

@urman,

Is this related to the apparent change in the command(delay: XXX) not being allowed to be great than 60 seconds?
http://build.smartthings.com/forums/topic/delay-commands-greater-than-60s-not-permitted-since-when/

5

@chrisb yup. It should be fixed now. Using runin is preferred over delay for 1-59 seconds. Anything 60 seconds and over should use runin.

6

@urman,

I want to make sure I understand correctly:

For a wait of 1-59 seconds runIn is preferred over delay.
For a wait of 60+ seconds runIn is required.

The first statement is the one I’m not sure on. The way you worded it make is sound like runIn is always preferred but delay can be under for small waits.

7

@chrisb, 1-59 seconds using either delayed commands or runIn should serve you well, neither one is necessarily preferred over the other. Even though delayed commands longer than 60 seconds are now allowed again it is preferred that you use runIn instead due to stacking issues that delayed commands don’t handle whereas runIn will.