Delay Commands Greater than 60s not permitted -- since when?

General Discussion
1

I have an app that turns on a light when a door opens, then turns it off 5 min later via the switch.off(delay: ) method… this has worked fine since I bought smart things in Oct… now all of a sudden it does’t and I see in the logs “Delayed commands greater than 60s not permitted” – huh?

2

Thanks for that post Steve,
I have the same issue. Two of my apps no longer work correctly.
How can the powers to be with ST deprecate or change a command without a replacement.???

3

I tried this alternative and it works for me…

runIn( MinsDelay, ‘function to be executed’ )

hope it helps

4

Yeah, I was able to get my apps back in business by using runIn() as well. It’s probably cleaner code that way, but some warning would have been nice.

5

Did anyone find out what happened with this? Is this related to stacking of commands similar to what happens w/ the Power Allowance App?

6

Yeah I noticed this too on one of my apps. But for me it isn’t working at all. I put my delay down to 1 second and my lights still didn’t turn off e.g. lights.off(delay: 1000). It would be nice if the change was added to the documentation if it was a change. To me it feels more like a bug.

@duncan and @urman can you give more on this?

7

@stevesell,

Thanks for this thread!! I have an app this has stopped working correctly lately and this explains why that’s the case!

As for why ST might be making the change, my guess is that it’s because of “stacking” problems. There’s a bit if this discussion in this thread: http://build.smartthings.com/forums/topic/power-allowance-app-alternative/

What it boils down to is that the delay commands can stack up. For example, if I run a problem that says: When this switch turns on, turn it off 10 minutes, then in this scenario, strange things happen:

7:00 enter room, physically turn on light.
7:05 leave room, physically turn off light.
7:07 someone else enters room, physically turns on light.

The problem is that the delay command will fire at 7:10. The fact that you turned off the light and then turned it back on at 7:07 does not erase the delay off at 7:10. That still run as commanded.

This led me to create the Improved Power Allowance app that uses the runIn instead of the delay command. The runIn will cancel previous scheduled attempts when trying to reschedule so as you said Steve, it’s cleaning and work “correctly.” That is, it works the way that people generally expect it to work.

That said, warning of the change would have been very nice.

8

It seems that this silent API change affected quite a few SmartThings users. It’s understandable that ST has to tweak their API now and then, but I think everyone would appreciate a little “heads up” notice. After all, a published API is a sort of a contract with developers. @ben_edwards, what say you?

9

Thanks @chrisb that was an excellent explanation. Last night I started playing with my app that was broken with this api change. I started using the runin command and it seems to be working well. I think I need to run some more tests but at least my app works again.

Quick question on the runin, can paramaters be passed with it to the method?

10

First off, we’ve re-instated the use of delayed commands longer than 60 seconds, so those of you that are still using it in your apps they should start working again. If your’ve already migrated your apps to runIn then please keep them as is, that is the recommended approach for actions being executed > a minute out and most susceptible to stacking issues. For shorter delays, the use of delayed commands is just fine so no need to migrate those. We deeply apologize for any of you that incurred app breakages due to this change and we’ll see that proper communication is sent out well in advance before that functionality is removed for good.