I have an app with a 3 second delay that I call with a runOnce in a method that runs at sunset. It works fine in testing (not at sunset) but only works some of the time whilst running on the metal. It could be due to server traffic at sunset. I think arbitrarily moving this somewhat before or after sunset to avoid the peak will have no adverse impact. So, the question is, how far do I need to move the method in order to avoid the peak? 30 seconds enough? If not, what offset should I use?
Hmmm… I have a few things running at Sunset or at before/after 15 minutes, and haven’t noticed delays; but I also haven’t analyzed the logs in detail to see if this is consistent.
Have you asked support@ if they could route a request for someone to dig up the traffic statistics? Ideally it would show a nice graph with a peak at sunset and tapering off; and you’d see how quickly it reaches acceptable tolerances again?
Based on the title of your post, and not knowing where you live, it could be far enough if you moved to Alaska! Probably not much traffic peaking around their sunset… 
So I’m only a sample set of one person and I have only 3 “Sunset” based actions (one with offset -15 minutes, one at +5 minutes, and one at no offset).
Tonight: Per the event log, all of these completed less than 10 seconds overdue.
I am in San Francisco, PST. Probably a relatively high traffic area – lots of first-adopters! (?)
Still – hoping SmartThings will actually share the full statistical distribution!
…Terry.
Ha!. I’m not going to move to Alaska to resolve but thanks for the creative solution, Bruce ;-).
Looks like I may not have been clear in my OP. I am not concerned about events firing a few seconds late at peak times. I DO care about events that don’t fire at all. This is what I am seeing.
I have a process that is divided into 2 actions which need to be separated by more than an instant. The first action is triggered at sunset. Initially, I was using a runIn with a 3 second value to fire the second event but that stopped working. The collective wisdom of the community seemed to be that I should use a runOnce. So I figured out how to create a java time object for 3 seconds from now (not a trivial task for a newb such as myself, but I did it) and coded the runOnce call.
This worked great in testing (not at sunset) but it seems to be working only sometimes now that is in use at my home.
Just a theory, but what I think is happening is that, because of a peak load situation, there ends up being more than 3 seconds between the time my SmartApp determines target time (3 seconds from now) and the time the job is presented to the queue. Then, it appears to Quest (job scheduler) that my SmartApp is requesting a time warp into the past to run a job at a time that has already come and gone . . . and therefore rejects the job and it never happens.
So, if the fist action happens 10 seconds or even a minute after sunset . . . no problem . . . just as long as the second action happens. 3 seconds after the first action seems right to me but, really, it could be value under, say 10 seconds (but not instantly).
So, I’m just trying to figure out if shifting this process before or after sunset just a little bit will help to insure that the second action does fire reliably.
1 Like
Quest really needs a bug fix or feature request such that “overdue” events don’t get discarded,… Right?
1 Like
It seems like jobs that are in the queue don’t get discarded. I’ve not run into any jobs that where in the queue for any amount of time that were discarded. They are sometimes late and this is well documented . . . and not a big deal for anything I’m doing. The only jobs that I think are being discarded are those that are scheduled for just a few seconds in the future.
I would suspect all this is resolved when the cron scheduler is running locally on your hub. Here’s hoping!