I have a working theory that the scheduled event is completing before it’s scheduled due time (suggesting it actually triggers a second or so before due date), so when the scheduler looks at the next due event it is on the same day a few msec in the future, but by the time it writes this into the schedule that time is passed so it can’t trigger. The simple fix would be for the scheduler to periodically check for waiting schedules past due and reset them. But I’ve no idea how feasible that would be. Can I try to be the first to use the > Dumbthings Label??
my “turn off after sunrise” event is no longer working. Stopped working yesterday.
Should I reboot my hub? Very frustrating, it was working fine prior to yesterday, and I changed nothing.
I just hard rebooted my hub yesterday morning, but my timed routines still failed last night and this morning. YMMV, but I’m currently having zero timed routines working.
UPDATE: I found one Routine with next scheduled time in the past that also had a blank value in “At a specific time” even though it is set up to run at sunset+30. I removed the specific time and then refreshed the smart app online and the schedule updated. So, maybe it will work today
Rebooting the hub is the least likely thing to help this problem. The hub is just a transceiver of z-wave and zigbee messages. The cloud is the brains.
As you discovered, your failed routine did not get scheduled correctly. That has nothing to do with the hub.
My suggestion is to delete that Routine completely, and start over with it.
I’m still getting random failures of scheduled routines. No messages in logs in the app or on the server, complete silence. Seems if I update the routine, hit done, it’ll work for a while. Really lousy bug for a HA platform, I mean really, is this just basic foundational functionality!?
had another random failure yesterday. This time it was different. It missed its timed task for sunrise (turn off patio lights), but without my intervention, it picked up and took care of its sundown task (turn on patio lights).
So as others, I am seeing random failures still.
I can say that as exciting as this platform is, it is clear they are still ironing out bugs, and for me this one is serious being that this is fundamental stuff here.
I could not imagine using this platform for home security that’s for damn sure!
It’s been 3+ months for me since I’ve made it through a single day of time-based events all working properly. 3 months of frustration, cold house in the morning, coming home to a dark house, and endless troubleshooting trying to find a cause. Time-based event failures seems to be 100% random. I’ve been searching for any sort of correlation or pattern but I’ve come to the conclusion that it is purely random on my end. I tried moving everything to Rule Machine, but that didn’t help. The only “solution” I can come up with is to make three instances of each time-based event, each 1 minute apart, to increase the odds of it running.
Are your times by any chance on the hour or half hour or sunset / sunrise? If so, ST fails with an overload of events at peak times. Change your times to something different, and it might work better.
Mine are a mixture of sunset/sunrise +/- a certain number of minutes and specific non-00 or 30 minute times. They all randomly fail.
For sunset/sunrise times, I would think the load should be spread out on the servers because there are hundreds of different sunset and sunrise times across different cities, unless Smartthings is using more generic times for sunset/sunrise events in different regions.
bamarayne
(Jason "The Enabler" as deemed so by @Smart)
892
Would you mind posting a detailed description of your most common failing rule in this thread?
It is very possible that what you’re experiencing has been seen a thousand times and I’m sure we can figure it out.
I gave up on the SmartThings scheduled events a while ago. I still have a support ticket raised. I now use the IFTTT time channel to trigger SmartThings switches at key times in the day and have my routines and lights triggered on switch events. It’s the most reliable it’s ever been. The only downside is being limited to 15 minute time slots on IFTTT.
@bravenel, curious, do you know this for a fact that ST has issues with being overloaded at peak times or is it just a suspicion? Because I had the same suspicion and moved all my events to +/- 30+ minutes from sunrise/sunset and it was no better. Plus my most unreliable scheduled event is just a simple timer scheduled for 7:50am.
± 30 minutes could collide with other times. I’d try something more random, just a thought.
One thing that’s nice about rule machine is you can use anything as a trigger. I tend to put related things like motions in as triggers rather than depend on times. It is the biggest single issue with the platform, and I wish we knew that there was a plan for it…
I caught it this morning completely by accident killing a scheduled job that was scheduled for 9:00:07. That time was purely coincidental, just something that happened testing something. That job was killed for running over 20 seconds. So what they’re doing is queuing things up when there is a flood of events, which I understand and doesn’t matter much. But then they kill the job as it goes stale in the queue. I bet that most of the scheduling problems arise from this one thing. Why in the world they kill a job that’s in a queue that they use to buffer high event loads is beyond me. Maybe they don’t know how to distinguish a genuinely bad app that’s in an infinite loop from one that they’ve stuck in a queue.
After the Xmas break I went through the routine (which used to be daily) of fixing all my time based apps that got stuck waiting. at the beginning on November I had set up IFTTT as a back-up trigger so I hadn’t been watching ST for a while.
However since the fix at the beginning of this week not one time based smart app has failed to trigger on time. that’s about 15 time based triggers for 4 days without a failure this is some sort of ST record for me. If it keeps up I might even start to trust it…Go on fate do your worst