Check me on this--I don't see a way to operationalize this use-case with the Motion Lighting App: one of the lights in the automation is turned on manually, which then triggers the lighting off delay as if there was motion, even where there isn't.
This seems to be a WAF/SAF-driven need because others will walk into rooms managed by motion lighting, mindlessly flip on the switch, and then leave the room thinking, "well, the lights in this place go off by themselves, so all good." Then my wife wonders why lights are left on around the house and concludes this automation stuff must not be working!
Suppose I could write a rule in RM5, just wondering if I'm missing the option for manual-on-auto-off in the built-in Motion Lighting App.
Gonna need to know more about the mindless happenings in order to understand what you are trying to accomplish. How is the switch related, why does motion lighting not know about these people, etc.
I’m thinking about the specific case where one of the switches that normally triggers by motion is turned on first manually. The switch gets turned on manually before the motion triggers the switch to turn on. Say for example a switch so close to the entry to a room that the hand gets there before the motion is triggered. Or maybe it’s turned on by a dashboard.
In such a scenario, I still want the off-cycle to occur as if the switch was turned on via motion. Clearer?
I suspected the same. I read the documentation and it suggests the option is for something different (when hub thinks the devices are already on due to incorrect influence from another app, external hub, etc, so it doesn’t issue the on command—this option, as I understand it, essentially says, the device state could be wrong, so try to turn it on anyway.).
Still, I tried that option just the same (one can hope). I found that, unless there was a motion event that triggers the app, it doesn’t work for this use case.
I used to use the motion and mode lighting apps but eventually moved it all over to simple rules or rule machine as I wanted a multitude of conditions to be met (similar to yours).
Everyone has their own personal preference, sorry I couldn’t help!
Did you try the option I pointed to with the arrow? I can't say I have tested it myself, but it at least refers to the situation you are describing.
Do you want to provide a screenshot of your motion lighting setup? Perhaps there's something else at play... A look at the logs would also help, you can turn on additional logging in the ML app / rule that can often give a reasonable description of why things are and aren't actioned.
Love the idea, and I had the same reaction, but I no longer believe that is the correct interpretation of what that option does. See the documentation here. The "Do Turn On if Already On" is described this way:
Motion Lighting subscribes to events from lights it controls and attempts to determine the current state of all the lights it is controlling with a particular Motion Lighting child app. Certain circumstances, may cause Motion Lighting to not turn lights On if it falsely has determined they are already on, due to influence from another app, controls on a remote bridge, or physical control that may have caused the reported state to be out of sync with all of the lights it is controlling. Enabling this option forces motion events to send On commands, irrespective of the state of the lights it is controlling.
I did try the option, just cuz I was desperate. It didn't do what you (and I) thought it would do.
Sure, see below. I think I've come to the conclusion, as has @Ken_Fraleigh, that this isn't doable in Motion Lighting, so I suppose I'll just use RM. But I'd love to be wrong!
Yeah, I think in the end the simplest (maybe) option will be RM. Only other thing off the top of my head I can think of would be looking at options for additional switches to turn on and treating the problematic light as a switch rather than part of the list of lights. I'll find a screenshot of what I am thinking about...
Yeah tried that too, no joy. Appreciate the help just the same. Turns out, in the thread that @gwydionjhr mentions above in this thread, there are a couple elegant solutions mentioned.
