@bravenel I’m tagging you here Bruce, since I seem to recall that ML is your baby.
I currently have an ML rule which is configured to keep lights on when a specific switch is on. The problem I have with it is that if I turn the switch off, the lights will not turn off until there has been motion in the area again and the delay from the motion event has been.
Would it be possible to change this behaviour so that when the “keep lights on” switch is turned off it will schedule the lights to come off after the delay period as if motion had just been detected?
That switch could be selected also under the option "Switches to turn off lights", but there would not be a delay involved. I'm pretty reluctant to start adding more options for options, such as "Switches to turn off lights after a delay".
There is an easy way to do this: Using Simple Automation Rule fired by that switch turning off, turn off the lights in question after a delay. Yeah, two rules when you'd like only one. But this would work and not require more features loaded into Motion Lighting.
Thanks for the consideration Bruce. I’ve currently got a workaround to it which is an RM rule that triggers on the switch turning off which then turns on and off a virtual motion sensor which is used by the ML rule. I was just hoping that this functionality would be able to be built in to ML.
My argument was that since I’ve just turned off a switch which was used to force the lights to stay on, then surely ML shouldn’t just leave the lights on indefinitely which is the current behaviour.
But, as both you and @mark.cockcroft pointed out, the switch could also be configured in ML to immediately turn off the lights or I can continue using my workaround which will turn off the lights after the ML delay but with more moving parts.
ML has a specific design feature that there are separate, and separated, options of turning lights on (or not), and turning them off (or not). This is actually part of the power of this app, this separation. So it absolutely does make sense that an option about not turning lights on has nothing at all to do with turning them off. Otherwise, if we were to cross-pollinate on-options with off-options, you'd end up with dozens and dozens of options that no one could every figure out (or we might as well just call it Rule Machine). You could say that surely your desired cross-pollination should be implemented, but that's a totally slippery slope, since everyone's use case is slightly different.
This boils down to a request, if we are to keep to the model of separated on an off options, of a new option for off that incorporates a delay. So we'd have an optional delay for switches to turn off, buttons to turn off, etc. These are all edge cases. These all have simple work-arounds.
