SmartThings Community

Frickin' schedules again!?


(Convinced ST will never be unbroken…) #1

3 times out of the last five days time based auto execution of routines have failed.

You guys are never gonna get this right, are you?


(Aaron S) #2

If you have not already, please send a note to support so we can flag the ticket and what’s going on. If you already submitted a ticket, please DM the #


(Eric) #3

Don’t feel bad, you’re note alone! Here too in my office location but not home location! Its a wonderland.


(Chris) #4

My Good Morning routine did not fire at Sunrise this morning like it was supposed to. It’s like it got a partial execution…a couple of the lights turned on, but not all of them, and the mode did not change from Armed (Home) to Disarmed. Contacting support…


#5

I’m having trouble too. I have routines set upon presence detection, and those routines turn on/off security modes.

My log clearly shows my phone arriving, triggering a routine, but the routine never finishes (like good morning) and my security modes stays what it was. I’ve set off my alarm four times in two days. Should I unhook the alarm?

What gives?


(Chris) #6

Mine did it again this morning, I think I figured out that my Good Morning routine is changing the mode from Night to Home but not doing anything else. The couple of lights that actually came on were triggered by a CoRE piston that detected the mode change, not the routine. The rest of the lights and fans in the routine did not turn on, and SHM did not disarm. I have a different CoRE piston that executes the Good Morning routine based on different triggers, that has been prevented from running because there is a Night mode restriction on it. I unscheduled my routine today, will see if the CoRE piston triggers it correctly tomorrow.

Is yours doing the same thing? Mode change only with nothing else happening?


#7

Other people have reported something similar since the recent hub update.


.


(Chris) #8

I think I’m experiencing the inverse of their problem. My mode changes just fine, but none of the routine actions fire.


(Jason "The Enabler" as deemed so by @Smart) #9

@destructure00

I built this piston right after I made the post in the link above. It works great for ensuring my mode has changed.


(Jason "The Enabler" as deemed so by @Smart) #10

That’s what happened to me. The mode changed but the system did not register it so the pistons did not fire.
This piston checks the actual mode and attempts to fix it.


(Chris) #11

That’s pretty impressive, I’ll keep that in mind if I start experiencing mode failures. I’m experiencing the opposite though…mode changes are working fine. It’s my time-scheduled routine actions that are not working. The Good Morning routine is changing the mode from Night to Home, which is correct, but is not performing any of the “On” actions and does not disarm SHM. If I run the routine manually by tapping the button it works correctly.

For me, Good Morning is scheduled to run at Sunrise. I also have a CoRE piston that executes Good Morning if mode is Night and either my wife or I unplug our phones. The past two days the mode has changed at Sunrise, which is preventing the piston from executing. I unscheduled Good Morning, so hopefully tomorrow morning when the piston fires, the mode will still be Night and it will run Good Morning. We shall see…


(Chris) #12

Oh gotcha, I guess I misunderstood. When I checked my hamburger menu though, the mode was being reported as Home, which is what it should have been after the routine was executed. I have one piston that runs just off of mode only, and it fired correctly this morning at sunrise when the mode changed.


#13

The mode changes so that you can see the change in the mobile app, but none of the logic that subscribes to that mode change then runs. So I think you and @bamarayne are describing the same problem.


#14

There is another mode problem which has been reported, and I don’t know if it’s related to what you’re seeing or not, but some of the modes seem to have no labels which is breaking things.

Support is aware of that problem and the workaround they are suggesting is that you add a new mode through the IDE (which apparently will clean up the mode table) And after that you add a new routine. And then all your old code will start running again.

Anyway it’s something you might try.


(Chris) #15

Ok I think you are correct about the mode changes. I just checked the history on a couple devices that should turn off at midnight when the mode is Night and they did not turn off last night. I just ran my goodnight routine tonight though, which changes mode to Night, and checked the CoRE system variables, and $locationMode is showing Night, so that’s correct right?


(Chris) #16

Definitely having the issue described above. Mode “seems” to change, but many things (CoRE pistons in particular) that are subscribed to the mode changes don’t execute.