Automatic routines/modes not working, again


#1

As was reported and fixed a few weeks back, the issue of automatic routines not working has cropped up again this morning. I checked the notification log and my good morning routine, it ran at seven as I requested, but the mode never changed from night to home, my alarm didn’t turn itself off, and i was awakened by a pleasant alarm as my wife tried to open the kitchen door to go to work.

Second time this stopped working out of nowhere in a month.

Are we going to get a comment on this?

Edit: here’s the thread regarding this bug which was reportedly fixed two weeks ago…


#2

I noticed this too. My living room lights were on when I got up this morning, and “Good Night” is set to turn all lights off. I look in the notifications and see that “Good Night” ran, but there was no acknowledgement (changing mode, arming, setting thermostat, etc.). So, of course, “Good Morning” didn’t run this morning because it wasn’t previously in night mode (I use a tasker script with SharpTools that checks the current mode before changing)


(vlad) #3

Looking now - glancing at the monitors things look healthy… Any info to support with:

  1. Shard
  2. Expected exec time
  3. SmartApp name
  4. What happened (Complete miss, timeout, partial execution)
    Would be very helpful.

Thank you


(Jimmy) #4

I had this happen yesterday, but it worked fine this morning. My morning routine is supposed to disarm SHM and change the mode from Night to Home.


#5

Don’t Rely on ST scheduled events. Recommend to use CoRe rule engine to execute routines.


(John) #6

FYI, CoRE is failing too. Lots of timeout errors. Nothing works!


#7

Probably something to do with the ST node you are located on. Could that be it @JDRoberts? I am not having any CoRe issues.


(John) #8

CoRE was failing along with everything else that was using time-based triggers. Plus the timeouts that were occurring added insult to injury with respect to CoRE (it’s so damn big).

Shard can impact it, but this problem has already been identified in another thread.