Motion Lighting App Inconsistency

The delay-per-mode has been implemented. It is optional, as you will see in the next release. If you don’t choose it, then the same delay will apply for all modes (set as per the app now). Found and fixed another bug with the default delay setting of 1 minute. You can set the delay to 0 minutes, which causes the light to turn off immediately upon motion inactive.


Wonderful! What is the role out schedule for Hub updates?

I can confirm that this had been fixed with the latest firmware.

1 Like

The delay-per-mode feature doesn’t appear to be working for me, or at least not the way I assumed it was designed to. I have set the delays but it is still timing out with the default delay (1 min) even though that setting is no longer available once “per mode” is set.

@bravenel, this is a 2 part issue related to the Motion Lighting smartApp and to RM as well.

First issue (which makes the second issue more problematic) is the lack real world examples of what most of the settings do. We have a lot of options, which is great, but I don’t really understand what each one does and how it affects the rest of an automation.

This leads to the second issue. I now need to test every option based on what I THINK it should do, so I end up adding and removing options and testing functionality. So here’s the problem. I have a functional automation that I want to make this smarter…So I try to add some more complex options. They don’t work the way I expected, so I revert to the EXACT same code that worked previously. Now the original automation no longer works the way it did previously. I now have to delete the entire automation and recreate it. Now everything works as expected. I am really hesitant to test any more complex automations because I fear that I would have to rebuild it for every test.

Perhaps you could describe your need, so we could use that as a real world example to explain.

Thanks for the offer Bruce, but my needs change from time to time. I would prefer not to have to post a question on the forum every time. Don’t get me wrong, I don’t expect a detailed description for every option…just a basic idea of what they are designed to accomplish. “Deactivate on” with a on/off toggle within the option is very confusing without a basic guideline of what it accomplishes.

I’m also a tinkerer, so testing each option to see how it affects things is not a problem. However, I need to be able to easily revert from my test scenario back to my “known good” without having to start over.

1 Like

OK, I'm sorry we don't have enough documentation for this app. We will address that. In the meantime, here is an example, and I will explain it. It covers most of the options. Explanations below image.

This one uses two motion sensors to active the lighting, which is two dimmers with settings for 5 modes.

On Options
The automatic turning on by motion can be disabled with two buttons of two different Pico remotes (buttons 1 or 5). That can be re-enabled with another button on those same two Picos (button 3). What happens is that when we go to bed, the last one pushes one of the disable buttons (these buttons do other things in other automations), and those lights don't come on any more. They will start coming on if button 3 is pressed (unusual), or at 6:30 AM (the norm).

A virtual switch called Bath Time also disables the automation when it is turned on by Alexa. This switch also hits another automation that makes the bath lights bright for when our grand daughters take a bath in the big tub, and we don't want a motion active event to make them go dim to 30 for Evening mode.

These lights will only turn on from motion between 6:00 AM and midnight in any event.

Off Options
The lights will not turn off until the two activating motion sensors are inactive, and these additional motion sensors are also inactive. For example, we don't want the lights turning off when in the shower.

When the main lights turn off, we want additional lights to also turn off at the same time. These were turned on by other automations. For example, turn off the shower light.

Delay turning these lights off for 4 minutes after motion inactive on all of the selected motion sensors. This is because sometimes there won't be much motion but someone is still there. This number came about by ending complaints of "the lights turned off on me".

If the physical switch called Bath Entry is turned off, turn all of these lights off. If the mode is Cleaning, do not turn these lights off when motion is inactive. And, finally, don't turn them off when the Bath Time switch is on. Notice the nuance that Bath Time is turned off itself when the lights turn off. But that's only going to happen when Bath Entry is physically turned off.

Missed Options
The only on options not used were "activate on with button", which is obvious, and a lux restriction, only turn on if lux < some value.

The only off options not used were "Button to push when off", which is for a Lutron system where a button is pushed instead of a switch; "Button to activate off", which is obvious; and, "Button to disable off", which would be like the switch Bath Time, only using a button on a remote, the pushing of which would stop the lights from being turned off automatically.


This is exactly what I needed. Muchas Gracias!

And now I realize why my previous tinkering ended with an unnecessary rebuild. This may seem silly to someone familiar with RM or motion lighting but because I was unsure of what each option meant it made it trickier to troubleshoot.

I set my bathroom light to turn on with motion and off with 2 minutes of inactivity. Somewhere in my many tests, I set the “switch to disable off”. When I later removed this option, I did so while the “switchOffDisabled” was still set to true. Even though all the options to disable off were removed, that variable was still set and it stopped my light from turning off after delay. The only way ti fix this without rebuilding is to setup a “switch to disable turning off” device again, turn it off, and then remove the option altogether.

I’m not sure if this something that can be fixed (or if it is effective use of your time…but I think the lack of visibility to these settings can make it tricky to troubleshoot…is it possible to have the “switchOffDisabled” variable (and similar settings) set to false/default once removed?

1 Like

Yes, this is a valid point. I’ve been burned by it also. This is a tricky thing about apps. You CAN see the settings in the app information (circle i), if you can discern the meaning of the variables shown. That’s a pain though.

There have always been similar issues with Rule Machine. When you start changing things and removing settings, un-obvious bad things can happen.

So, for any app, the best rule of thumb is unless you really know what you are doing, if you want to remove settings it’s always a good idea to just remove that app, and do it over. That is guaranteed to give you the result you want. None of these apps takes more than a minute to set up, so don’t be attached to them… Start over instead.

Unfortunately, there are not easy fixes for these sorts of problems. There are hard complex fixes, which in the fullness of time may come to be.

Give your opinion on this question: Would you rather we spend our resources building more apps, or spend our resources bullet proofing the ones we have – if you had to choose ??

From a tinkerer’s perspective…definitely building more apps. From an end user perspective, a lot of small “bugs” can add up to a lot of time spent in unnecessary frustration and WAF decline.

If it’s one or the other…My opinion??..
So can I expect a Hue app by Friday? :smiley:

1 Like

I can tell you from personal experience that Hubitat is a WAF enhancer after ST. It used to be that “small bugs” would really make for a WAF issue, because it got piled on to by platform outages, outrages, etc. Once I moved the system to Hubitat, bam, instant improvement in WAF. These days, she tolerates the small bugs.

I develop on the my home system, while it’s running the house! 200+ devices, 150 automations. Using all of these apps, running into bugs, testing etc etc. WAF is good.


Lol…I hope to be there one day. I got the eye roll when I tried to explain the benefits of this hub and why spending another 100 would be worth it in the long run. So far she’s not impressed because of the time I’ve spent transitioning items and automations. I think once everything is settled and working as expected…and working fast at that…she’ll appreciate the time and money spent.


another request and question.

Feature request: Have an option for Lux exceeds to turn off lights. Use case: Lights come on in the morning but as the days gets brighter turn off the lights based on a lux value exceeding X.

Question: In regards to ‘Use delay per mode’: ON. I have this setup for 2 (i am assuming is minutes) for Off Day for Dawn however it never fires an off command. Same for other modes as well. I will try again tonight when I get home. But is any else seeing this behavior with this option? maybe I am misunderstanding the option. Thanks

No, this is a bug. Found and now fixed. Will be in the next release.

Is your Lux request really asking for a different app? This is about Motion Lighting, where motion events cause lights to turn on or off. There is a Lux restriction in place, where the lights won’t turn on from motion if the Lux is above some threshold. Doesn’t that cover the situation you envision?

Thanks, I see your point, I guess that makes more sense to have it in a different app then. Something along the lines of a power allowance based on lux. Maybe something in RM that says if switch is on and lux is above X then turn off. I will explore once the update is out that allows for refreshing within RM.

RM will do that now.

I'm having a similar but different experience with the new app. I love it's ability to easily configure different settings per mode. However, on occasions specific rooms will just stop functioning. This has happened 4 times, with 2 different room setups. It's happening now in one of my rooms.

Each time, I delete the app, set it back up and it works for a short time then stops again. None of the other setups are misbehaving when the specific app setup stops triggering. Watching the devices in the logs, events and on the device properties page shows the sensors going active and inactive as expected. Manual triggering of the lights works as intended. The only correlation I can think of is there are multiple motion sensors in each of those setups. None of the other setups (the ones that have yet to stop working) have multiple motion sensors. Which correlates also to the reported problem above.

It's really random and weird. I wish I had some sort of diagnostics to provide.

I've seen something similar, and am investigating. I don't think it has to do with multiple motion sensors, but, I could be wrong. None of that logic has changed in the code for a long time, and these automations have been very solid. FWIW, I have one not working right now for unknown reasons.

1 Like