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!
1st - Super sorry
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.
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.
@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.