Routine corruption

I had a routine that had a dependency on Saturday at a specific time suddenly yesterday (Tuesday) start firing, shutting off most of my lights at odd times of the day. Always a pleasant event, with the wife WTF’ing (ok I was too)…

The routine is designed to shut the lights off Saturday night at 11:50pm if there had been no motion in a room for the past hour:

11:50pm Saturday
Location mode: Away, Home, Night, Not Home - precondition
Bedroom Motion Sensor: no motion for 1 hour

Run scene: Good Night

From the History I could see this routine was firing an hour after Bedroom Motion Sensor logged No motion, starting on the second No Motion event of the day. Never mind that it wasn’t Saturday at 11:50pm, the thing fired at 7:11am, 8:32am, 11:03am, 2:42pm, 4:28pm… you get the idea.


But wait: it gets better! If there was an intervening motion event on the bedroom sensor during the 1 hour period, it still fired!!! Wait, what? Yep.

5:34am Motion
6:11am No motion
6:55am Motion
7:11am Routine activated
7:32am No motion
8:32am Routine activated

Double head turner. Ready for a triple?

The hub rebooted due to the firmware update, and even after the reboot this was still going on.

This was PERSISTENT corruption in the routine data of some sort.

After realizing this, I went into the routine and saved it and wouldn’t you know it… problem disappeared.

This is what I get for migrating early from a Webcore piston (story for another post)… VERY disconcerting.

1 Like

I believe I’m having the same issue. My lights are turning off at very random times. I check the events history and I see automations firing when they are not supposed to. I re-saved and turn on/off the automation, waiting to see if it happens again. If it does, I may need to delete the automation & recreate it

Did it also start happening back on Tuesday?

There was a hub firmware update about two days ago, and at different times for different people.

In the past, some people have reported that any timers they have set or routines based on specific times can get confused when the hub is updated and run at the wrong time the first time they run after the update.

I don’t know if that’s what happened here, but it does seem like a possibility.

@JDroberts I thought I was clear. The problem manifest BEFORE the update as well as AFTER the reboot.


I noticed it about two days ago. It’s happening with automations that include motion sensors which should trigger at night but they are triggering during the day. I tried re-saving the automation but not helping. I had to delete them. I’ll try recreating them and see if the issue persists.

Sorry, I meant that for @ny_robert , I know yours started before the update.

That was happening to me too. But in my case, the automation had another condition for Saturday at 11:50pm and it was still firing on Tuesdays. It was the motion sensor changing from motion to no motion that was causing it to fire, ignoring the day/time condition.

My original motion condition had “No motion for 1 hour” – did yours also have a timed state?

Yea I had a night light automation - if it’s between 11pm & 5am & there’s motion turn on lights for 5 minutes then turn off. I checked the app history and it was happening anytime there was motion and completely ignoring the time.

I’m able to reproduce this – there’s definitely a bug in the day calculation. I can reproduce it in a new routine. Can someone else try this and confirm:

  1. Create a new routine
  2. For the first condition, add Time 11:50 PM, repeats only on Saturday
  3. For the second condition, add any motion sensor - no motion, and custom for 1 hour
  4. For the Then action, add an SMS text/notification that the routine fired

This routine should only fire on Saturday evening at 11:50pm if the there was no motion for at least an hour.

Instead, it is firing any hour/day of the week an hour after there is no motion from the sensor.

Obviously I used different numbers, but, yes, to me it appears the payload is activated regardless of the time, and also regardless of whether the set time has happened yet.

It doesn’t seem to also activate at the time if the motion condition isn’t met, so it’s not like it is a straight OR. The one thing I didn’t test is if it activates at the time if the motion condition is met, thus giving a potential extra activation. That could easily be implemented by adding a separate ‘if’ in the underlying Rule just to trigger the Rule to run.

The time is neither flagged as a precondition, but nor is it part of the main condition group. So something is a bit different. Also the timer can be set to fire once rather than repeat, after which the Routine will be deleted, which I wasn’t aware of as a feature of Rules, so it makes me wonder what else might be happening.

Whether it is a bug depends on what it is supposed to be doing.

I agree, on the surface it’s hard to decode what this should be doing.

Anyone at SmartThings can comment?

One clue: I can say that if you change the time condition to a Period of time range, eg. Saturday 11:50pm - 11:51pm, it doesn’t fire “randomly” based based on 1 hour after the no motion event.

I wouldn’t expect it to do anything in that case, unless the no motion time happened in that minute by fluke. That’s only what I’d expect though.

I keep well clear of app Routines for a number of reasons, and it not always being obvious what logic is supposedly being implemented is one of them.

1 Like

I’m trying to wean off of WebCore, can’t do that if we have no idea how Routines with any complexity actually run. And, they may run one way today, and another tomorrow. Pfff.

Agree – that’s in fact what my testing bears out. The 1 hour must be handled as an “event” not a “state”