Motion sensors, phrases, and scheduled events

Hi All,

I’ve been having some undesirable interactions between an Ecolink motion sensor, a coupled connected lights, and the Hello, Home phrases. I think I’ve figured out what the problem is, I’m just not sure how to solve it – maybe someone here has cracked this nut already and can help?

Here’s the puzzle’s logic:

  1. Motion sensor is tied to lights through a basic “Lights & Switches” -> Turn on when there is motion. I have it configured with a “Wait this many minutes to turn off after motion stops” = 15 minutes.

  2. Motion will be sensed and lights go on according to plan. Motion ends, and a “lights off” event gets scheduled for 15 minutes in the future.

  3. During this 15 minute gap, I change the house mode with a custom “movie time” phrase. In this configuration, I’ve disabled the motion sensors so we don’t lose lights mid show and find ourselves sitting in the dark. When I say “disabled” here, I mean the house mode changes to a mode that “lights turn on during motion” is supposed to ignore (that is, the “Only when mode is…” does not include my “movie time” mode).

  4. As planned, the scheduled “lights off” event takes place and leaves us in the dark – Oops! Yes, this is how the various apps are configured to work, but it’s not the desired outcome. In an ideal world, the house would realize the house mode changed and cancel the scheduled “lights off” command.

So, it seems to me this should be a solvable problem involving “de-scheduling” (that is, canceling scheduled events, or having scheduled events be mode sensitive). However, short of writing my own SmartApp, I haven’t found a clear solution. Any community help would be much appreciated!

Cheers to you all and thanks for your input!

1 Like

I run into this same issue. I think the solve for this needs to be more at the “ST Core” level and not via a SmartApp. There should be options to disable various countdown timers when changing modes.

I’m curious to see what others in the community have come up with.

@brianlees I guess it’s just surprising this is even an issue. It seems so simple that I’m sure I must be doing something wrong…

There is an easy way to do this: There are two different actions in Lights & Switches that apply. “Turn on when there is motion”, and “Turn off when there is no motion”. What you do is turn your lights on with “Turn on when there is motion”, but do not select the option for “Turn off when motion stops”. Instead what you do, is use “Turn off when there is no motion” to turn them off after 15 minutes. Place the mode restriction on the latter, to not turn them off if mode is “movie time”.

So, they come on as you describe, and will stay on for 15 minutes. But, in the interim mode changes to “movie time”. Now, “Turn off when there is no motion” will not run, because it’s the wrong mode, and they won’t turn off.


@bravenel Yup. It’s so simple, I had to miss it. :slight_smile: Many thanks friend!

1 Like

@bravenel, thank you so much. Ive been dealing with this for a year or 2. Built my own apps to solve this. Didnt realize the funtionality was so simple just had the logic a little wrong.

its been over a year now and am curious if this recommendation above is still the best way to do this. When i use the function to “turn off when there is no motion” and set it to turn off after 15 minutes, it states “beta: not yet supported for local execution”. Anyone know what that means? Is it reliable?

I’ve been using @bravenel’s solution since the beginning of this thread without any problems. In fact, it’s worked so well, I never needed to investigate whether any platform updates offered better solutions!

As for the “beta” blah blah… This sounds like the app is telling you that the command will be scheduled from the cloud rather than from the local hub. This means that in the event of an internet outage or a ST server crash, the event will not take place. The whole idea of “local execution” was rolled out with the 2.0 version of the hub a couple years back where ST offloaded a bunch of basic features to the new hubs rather than have them run on the cloud. This was (eventually) a major improvement for stability and reduction in latency – a command fired from the cloud takes about 500 ms for the command to get from your home to the cloud server and another 500 ms to get back from the cloud server to your home. When commands are executed directly on the hub, this “travel time” is reduced to basically zero.

Thanks Jesse for your reply. To turn off, I actually just used the “Power Allowance Exceeded” function instead and set it to turn off after 15 minutes. Seems to work just the same! Anyways, looks like this will suit my needs just fine in the meantime.