[Solved] Motion Lighting App - "Don't turn off if already on"


I'm migrating over from SmartThings, and I really like the Motion Lighting App. Can replace a lot of custom rules/pistons. However, I can't seem to get the "Don't turn off if already on" option to work. Here's my setup:

  • One motion sensor on my front porch. (It's actually a Virtual Motion Sensor in HE, if that matters.)
  • One GE Z-Wave Plus Switch (NOT a dimmer) to control the front porch lights.
  • Trying to use minimal settings:
    • Motion Sensors: Virtual Front Porch Motion Sensor
    • Lights to Turn On: Switches per mode: Porch Light, Modes: Away, Day, Evening, Night
    • Options for Additional Sensors, Lights-Off and Off options: Delay off for 0 minutes, Don't turn off if already on
    • All other settings at defaults.

What I expect: If the front porch light starts as "off", then it will turn on when the motion sensor goes "active", and turn off immediately when the motion sensor goes "inactive". BUT, if the front porch light starts as "on", then motion events will have no effect on the front porch light.

What's actually happening: I start the front porch light as "on". I then trigger motion "active". Then I trigger motion "inactive". When motion goes "inactive", the app is incorrectly turning the front porch light off.

Do I have the app misconfigured?


The first question to answer is:

"While watching the GE Switch Device web page in Hubitat, does the state of the switch properly change when you manually/physically turn on and off the switch?"

If that does not work properly, then you must troubleshoot that before troubleshooting the Motion Lighting App.


Ok, I just tested. Yes, the HE web page does correctly update if I manually turn the switch on. And this did not affect the behavior. The switch was still turned off when motion went to "inactive".


Ok, it sounds like it should work. Perhaps you could post a screen capture of the Motion Lighting rule. Sometimes a picture is worth a 1000 words.

I am not a Motion Lighting App guru...perhaps someone else with more experience will chime in?

If you need help from the Hubitat team, just send them an email at hubitat@support.com. They are a very responsive team.


If it helps, here are my logs during this process:

app:87 2019-01-09 09:59:36.445 am info Override ended by Porch Lights

dev:3 2019-01-09 09:59:36.369 am info Porch Lights was turned off[digital]

app:87 2019-01-09 09:59:36.068 am info Turning off

app:87 2019-01-09 09:59:36.020 am info Motion inactive (Virtual Motion Sensor) Front Door Motion

dev:69 2019-01-09 09:59:35.988 am info (Virtual Motion Sensor) Front Door Motion is inactive

dev:3 2019-01-09 09:59:34.282 am info Porch Lights is on [digital]

app:87 2019-01-09 09:59:33.999 am info Turning on switch [Porch Lights]

app:87 2019-01-09 09:59:33.972 am info Motion active (Virtual Motion Sensor) Front Door Motion

dev:69 2019-01-09 09:59:33.940 am info (Virtual Motion Sensor) Front Door Motion is active

dev:3 2019-01-09 09:59:31.949 am info Porch Lights was turned on[digital]


And here is a screenshot of my configuration:


in your logs it shows your initial turning on of the light was from HE (ie digital). Does it still do the same thing if the ON event is you pressing the button on the device, ie a physical ON event?


I have this same issue with my motion lights. For me, my suspicion (though I have not tested it) is that I am triggering a named "group" of lights instead of a set of individual bulbs (don't want that popcorn effect).

In my circumstances, I never use the physical switch to activate the bulbs, and it is all done through HE.


In the case of z-wave, ive found that grouping lights doesnt really eliminate popcorn effect, they still get the commands serially, ie one then the other. Yes maybe a group might help the serial commands to be issued a bit faster than if the individual lights were triggered by RM or ML etc, but this is not like a hardware or broadcast association, its just a soft grouping. Zigbee lights in a group are capable of getting the broadcast command truly in parallel and should not popcorn.

I was asking about the physical event to try to eliminate a variable with the "dont turn off if already on" issue. Maybe a physical event is whats needed to tell it to be on to where "dont turn off if already on" will be respected, but possibly a digital event isn't considered as On like a physical event is. all wild hypothesis.


Yes, it behaves the same if I physically turn the switch on before triggering the motion sensor.


When I tested groups w/zwave plus lights, not only did it not reduce the popcorn effect (I didn't expect it to, though) it actually turned on consistently slower than just adding the 4 lights individually to my RM rules.

I only made the group to make it slightly easier to specify in rules, but it was definitely slower when triggering the group versus the 4 individual lights. COULD just be coincidence, but I tested it (with a stopwatch) 5+ times both ways...


I believe there is a bug in the latest release of Motion Lighting that has caused this to fail. I am investigating this, and will report back soon.

Update: Bug confirmed: Don't Turn Off if Already On does not work. Fix will be in next release.

Motion Lighting Error with newest firmware

Awesome, thank you for the quick investigation!


Thank you, thank you for finding that!!!!!


I think that the anti-popcorn fix only works with the zigbee lights, which can apparently be addressed as a group (at the level where the magic happens). With others, like z-wave, the lights are sequentially addressed.


Correct. But I would argue that putting zwave lights into a group shouldn't make them slower, though, either. :slight_smile:


I can confirm that the new update today ( has fixed the issue. Thanks!


Many thanks for the heads-up on the update!