Delay not working?


(Paul) #1

Has “delay” stopped working as a modifier for device actions?

def initialize() {
	subscribe(switch1, "switch.on", onHandler)
}

def onHandler(evt) {
	switch1.off([delay:2000])
}

When I turn the switch on, it just stays on. If I change the delay to something 999ms or less, it does turn off the switch, but it seems to do so immediately, instead of waiting for any amount of delay.

Am I doing something wrong? Or has this changed? I’ve definitely used delays longer than 999ms successfully before…


Delay changed, am I crazy?
(Geko) #2

I guess delay has become a victim of recent platform “improvements” and “upgrades” among few other things.


(Bruce) #3

I noticed “delay” failing a day or two ago also. I don’t know what’s going on with it…


(John Lord) #4

it’s broken the vlc thing app also. I had to jack up the delays to insane amounts to have it function correctly.


(Ben Edwards) #5

Looking at this guys.


(Paul) #6

Thanks, Ben.
12345678910
~P


(Ryan Applegate) #7

This has now been fixed and delays < 60 seconds should now be working as expected again.


(Tim Slagle) #8

@rappleg is my favorite


(Paul) #9

Thank you thank you thank you


#10

Hello,

I searched the forum for awhile but couldn’t find anything saying that delay had been changed or broken recently, so if it’s there and I missed it I apologize. I did find a post from last year where it wasn’t working for < 60 sec delay, and the devs got it fixed.

What I noticed was that over the last couple weeks my Photo Burst When was only ever taking the first pic and not continuing on to take the following bursts. After much troubleshooting and testing, it appears that the “delay” parameter now takes real seconds instead of milliseconds? In testing in the IDE “camera.take([delay: 5000])” wasn’t doing anything, so on a whim I changed it to “delay: 5” and it returned in 5 secs. Tried a full burst of 5 pics with 5 secs between and it worked great (aside from it ranging between 4 and 6 seconds).

Is that just a quirk in the IDE simulator or did it really change for everyone? I haven’t changed/published my app to test it because I’m not home to trigger it. The docs still show milliseconds.

Side note: is there a way to kill off any delayed commands that are scheduled? I’ve been testing this thing a bunch with high delay numbers, including using light switches… I’m afraid my lights are going to start turning off and on randomly over the next few days.


(Jason) #11

Edited out off topic info.

I assume that this has to do with Ticker, and the recent lack of general system reliability.


#12

That may be the case for runIn(), but I’m just talking about delay. Below is the example given in the docs under “Working With Devices”:

// wait two seconds before sending on command
mySwitch.on([delay: 2000])

If you ran this code now I think it’d be 2,000 seconds. The ST code template for “Photo Burst When” still has 500 as the default burst delay, too.

I changed my smartapp last night to plug in seconds instead of milliseconds and it now works as intended. If they do find that it’s a bug and change it back I guess I’ll have to change my code back.

I’ll input a ticket and try to find out.


(Joe) #13

Let us know what you find out… I’ve been experiencing the same thing. I’ll have to try updating my code to use seconds instead of milliseconds.


(Paul) #14

This seems to have been broken for at least 3 days… maybe longer? I’m seeing it using the milliseconds delay on Rule Machine. @bravenel have you seen this as well?

Such a shame… [delay: xxxx] was perhaps the most reliable part of my setup over the last year and a half. I’m opening a ticket.


(Joe) #15

It looks like it was changed to seconds. My quick test using seconds instead of milliseconds worked.


(Paul) #16

Ah I see… I totally misread that. Hmm… I wonder where that change was announced :smirk:


(Joe) #17

It is things like this that make the difference between ‘possible to develop for’ and ‘developer friendly’, I think.


(Bruce) #19

I can confirm this. It appears that [delay: msecs] now delays that number of seconds, not that number of milliseconds. Hey only off by a factor of 1000.

Submit a ticket.

@slagle, @Tyler, @jody.albritton, @Jim:

device.off([delay: 25]) now delays for 25 seconds instead of 25 milliseconds. Confirmed behavior.


(Jody) #20

I am trying to find the root of this issue.


(Bruce) #21

Ticket # 204239

There is no scheduled job shown in the IDE for this type of delay.