Could this be the cause of Time-based events failures?

I hope somebody from ST staff reads these forums. For the last week, none of time-based events worked on my ST. This is not some “degraded performance”, as stated at ST status page, this is just a total failure. Anyway, I was looking at my ST IDE for clues when I noticed that one daily event stuck at January 18th (today is 1/24).

Does this mean my ST clock is skewed? Most of timestamps in various logs are current, but I suspect these logs are cloud-originated. How do I check if my ST is actually in sync? Is there a way to reset it without erasing apps? And finally, when ST staff will take their heads out of where they put it and fix this?

Yes, that’s one example. You can resynch it by changing the time and resaving the app.

What you see is not the cause, but the result of the scheduler failure. The scheduler process that was supposed to execute your app, rule, routine or whatever, was killed, terminated or exited abnormally, most likely because of a resource shortage (e.g. VM run out of memory, database connection timed out, process exceeded maximum run time, etc.)


The result will not skew the timestamp

I’m not sure where you see ‘skewed’ timestamp. The “Job History” table is stale. They’ve stopped updating it last week. I guess you’ve missed the memo. :smile:

And I guess you’re looking at the wrong part of the table :smile: “Scheduled Jobs” is not the “Job History” and it shows the handler as waiting.

Knowing ST’s developers level of competency, I wouldn’t be surprised if their code would wait indefinitely for a missed event. Even though this is hundreds times more embarrassing than a skewed clock.

And btw, if you’re dishwasher suddenly stops working, all because you’ve “missed the memo” from the manufacturer, would you **ever ** buy same brand dishwasher again?

That’s exactly the point of my original post. It’s not skewed. It’s “waiting” in the past. The scheduled job never ran, so the DB entry was never updated. The worst thing is that it will never run again, until you go in and manually re-schedule it.

1 Like

So the last night I went ahead and re-scheduled all time-based actions. It worked once before it stopped again - no heat in the morning.

I’m done with this crap. I’ve pre-ordered VeraPlus, the moment it arrives the STeaming pile of vaporware goes into the attic. Too bad I’m our of the return window.

1 Like

The re-sell price on Amazon is not that bad. :smile:

1 Like

Well you and @geko are correct. It’s a matter of perception of the bigger issue. Definitely your screenshot shows the CAUSE your app is no longer running at scheduled time. And most certainly @geko is right that the CAUSE your schedule failed is the scheduler process that gets hung up in some sort of backend glitch. The good news is that you can fix it by restarting your app, that’s your quick fix, while ST fixes the scheduler. Your fix takes a minute, ST’s fix takes years and counting, but is coming…‘in few weeks’

No, this will not fix the issue, you didn’t read my comment above. I’ve tried and changed timing on all schedules, saved and saw it working last night. The only problem none of schedules still worked this morning.

Writing a schedule application is a good job interview task (I have 25+ years of software development). In my book, ST developers shouldn’t be hired in fast food industry, much less to develop home automation.


The scheduler issues have gotten progressively worse since the V2 release probably due to surge of new accounts. I’ve been watching these issues since summer 2014 and typically, the time between failures was from several days to several weeks. Now, it a matter of hours! I’ve implemented a watchdog in my Pollster app and I see it’s been restarted 3 times (!) yesterday.

I also noticed that as well. Used to be couple of months. Now it’s every other day.

Well it fixes temporarily, because the root cause is not fixed lol. I know what you’re saying. And I am sorry for your issues. Been there, done that.