FAQ: Why “after no motion” doesn’t work the way you think it will

There have been multiple questions since the migration about why an automation based on “no motion“ during a specific time range fails.

The short answer is that “after no motion“ doesn’t work quite the way you think it will.

Extending Battery Life: The sensor talks to the hub, not the other way around

Because most of the motion sensors that work with smartthings are based on a mesh network (either Zigbee or zwave), they are NOT continuously monitored because that would use up too much battery life.

Instead, smartthings is waiting for the sensor to send a specific “event occurred” message. And most of the sensors can send one of two event occurred messages: “motion was detected” or “motion has not been detected for my preset period of time.”

That preset is stored in the device itself, and it’s typically three minutes, although sometimes it’s a little different and sometimes it’s configurable.

But whatever it is, it’s a message that the sensor sends to the hub.

Time Range is a Filter, not a Trigger Event

In smartThings, if you have a time range like “between midnight and 6 AM“ That’s a filter not a trigger.

What’s the difference? :thinking:

A filter is applied by the system after a trigger event occurs to see whether the system is supposed to pay attention to the trigger or not.


The “If the time is between midnight and 6 AM and there has been no motion for 10 minutes“ automation won’t even look at what time it is until the sensor has sent the “no motion detected” Event message.

If a message of that type is received, the system will then look to see if it is between midnight and 6 AM.

If it is, it will go onto the next step in your automation. If it is not, it will just stop there and not run the automation.

What the system is NOT going to do is kick off the automation at midnight and then check every 10 minutes to see if there’s been motion. It just doesn’t work that way. That would take a lot of extra system resources.

The system is waiting for the sensor to send it the “no motion detected“ event message, and then it’s going to check what time it is.

Time as a Trigger

If instead your automation said “if it is 12:01 a.m. and there has been no motion detected for 10 minutes“ it would work differently, because when the time is specific, the time itself becomes a trigger that kicks off the automation.

But of course that’s a whole different kind of use case, and probably not what you’re looking for.

Why can’t the system just keep track of the last time there was a “No motion“ event message?

It could, it’s just that the official features don’t. It’s not actually that hard to do: when the rule is created, it could set up a variable to track the sensors involved in the precondition.

But it doesn’t do that.


The only way an automation created with the official features that says “if the time is between midnight and 6 AM and there has been no motion for 10 minutes on the kitchen sensor“ will work is if the Kitchen sensor sends a “no motion detected“ event message to the hub during that time.

And THAT Will only happen if there has first been motion detected, because that’s how those sensors work.

To get a “no motion detected” event message from the sensor, there Has to have been a pretty recent prior “motion detected“ event message from the same sensor.

So if everybody went to bed at 11 PM, the last “no motion detected“ event message probably came at 11:10 PM. Not within the time range of your rule.

By the time it does get to midnight, the kitchen sensor is not sending any more “no motion detected“ event messages, because there hasn’t been any motion to start that sensor’s own internal timer.

So your time range rule “fails.“ :disappointed_relieved:

How can I get smartthings to keep track of when the last motion event message was received?

Using the official features, you can’t. But you can do it with webcore by setting up your own variable to track it.

I know that feels like a lot of work for something which should just be basic, but there we are.

If you haven’t used webCore before, it’s essentially a Community-created scripting language for smartthings. It’s very popular, and even has its own forum, and there are many people there who will be glad to help you create a “piston” (that’s what webcore calls its automations) To do what you want.

FAQ: What is WebCoRE? (And what was CoRE?)

And you will have to do that each time you want to create an automation of this type.


Another alternative, easier but more expensive, Is to get a different system, it’s typically a security system, which does handle “no motion” the way you expect and then tie it together with smartthings.

I’m not saying most people do that, but there are quite a few of us who are running additional systems for whatever reason and may find this easier.


So there you have it. The rule isn’t “broken“ but it doesn’t work the way most people would expect it would from the written description, either.

The sensor has to send a specific “no motion detected“ event message to the hub before the system will even look at what time it is. And those messages are controlled by settings within the sensor itself, usually for quite a short time frame like three minutes.

So if you didn’t have recent motion, you don’t get a “no motion detected“ event message, and your rule won’t run.

@jkp @Automated_House @Brad_ST


I should also add that some people are able to get the results they want using just the official features by having two rules.

They keep the range rule that they always had. That one will work as long as there is first motion during that time range.

Then they add a second rule which runs at the specific time which is the beginning of the range.

So in our example above the second rule would be “if it is midnight and there has been no motion for 10 minutes”.

That would get checked each night at midnight. Then if there HAD been motion, The specific time rule wouldn’t do anything and the other rule would get checked whenever the sensor finally sent the “no motion detected“ event message.

Again, that won’t cover all use cases, but it will work for some. :sunglasses:


That is exactly how my garage door automation works. At 10pm, check if there is motion and the garage is open. If it is open, and there is no motion, close the garage door. If it is open and there is motion, when motion stops, close the garage door. Adding the 10pm trigger was the change that made the automation work.

1 Like

I’m also trying to get confirmation if the “no motion for X minutes” in the automation creator is a true remains statement or if it is a wait that checks the motion state after X minutes. I have a suspicion its a wait and not a remains. Maybe @vlad or @ady624 can confirm how it works.

1 Like

Hi guys, this took me about a week to figure out after migrating to the new app. I had a rule in classsic which said if time is between midnight and 3am and there’s no motion for 30 mins, activate night mode. When I migrated this stopped working consitently, and through trial and error; tweaking the start time of the rule and “remembering” what time I actually went to bed I figured out there had to be motion occuring after the rule start time for it to work in the new app. So having figured this out, I made the quick hack of brigning the start window earlier so it would detect some motion before I went to bed so that the rule would work (unless I went to bed REALLY early). But my question (retorcial) is, why did this get broken in the migration? It used to work pefectly. If I went to bed at 9pm, the rule would become active at midnight and woudl instantly set mode to Night time. I just don’t understand why something so basic has changed. This shoudl have been a basic regression test in the new system. I’ve seen posts from the developers sudgesting the problems people are having with the migration are edge cases. But this is simply BS. This is baisc functionality that is not working anymore. Home / away routines are broken. Nighttime routines are broken. I just cannot fathom how Samsungs development team have allowed this mess to happen. I understand where they are trying to get to. But the new app has been around for well over a year, and for it not to be working at a basic level now they have deprectaed the classic app is qite frankly a joke.

I’ve not looked at that specifically, but I’d be considering ‘has been’ as well. It is tempting to think of an event happening that causes the Automation conditions to then be evaluated, webCoRE style. What if a condition having been independently reevaluated is the important event?

So given the above discussion, how the heck is “Motion for a duration” supposed to work. And if you turn duration off and save… it doesn’t really save and no indication is given that it didn’t save