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…
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.
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.
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.
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.