Hi, It appears that a restriction in Simple Lighting becoming false may be cancelling the turn off delay. My office light was still on today at 11am after having been triggered while it was still dark at around 6:30am, but I assume it got light during the 10 min timeout, so the "turn off when motion stops" was canceled by the lux restriction?
Surely a "turn off after" delay should still be honored even if the restriction happens to change state in the meantime?
No, because it doesn't know the difference between on and off in your restriction. If you wanted it to work correctly, you would need two separate rules. Simple lighting is KISS and nothing more. You could create one rule in RM4 but that's a bit overkill for what you're doing here.
Have you looked at using Motion Lighting rather than simple lighting for motion lighting control? Your restriction is definitely going to prevent the simple lighting rule to fire. That's why you can't use an lum sensor in the room that you're controlling the lights for.
By inference, there would only ever be a "turn off after" delay if it was already on, so it only ever would apply to turning off. Im suggesting that once a "turn off after n minutes delay" has been triggered by SL, that it should always be actioned, regardless of if the restriction flipped in the meantime.
Restrictions in Simple Lighting are naïve (part of what makes it simple). I'd agree with the above: Motion Lighting has options to just restrict on (or off) and can probably do what you want. RM certainly could too (restrictions were recently removed from it because they were similarly confusing and it now has conditionals that can do everything they could plus more), but it's probably overkill here.
This still seems counter-intuitive. If you use restrictions in SL, then the "turn off after" delay is pretty pointless as it will be cancelled if it overlaps with a restriction ending, thus leaving the lights on.
In my case I had several SLs that trigger on contacts, so not just motion. Ive migrated one of them to RM4 and came up with this that seems to work.
Sorry to harp on about this. I can see how restrictions in SL would/should apply to both on and off, but I maintain that "what the user intended" is for a delayed off to still be sent even if the restriction changed in the meantime. Otherwise lights being left on will result. Not what was intended. Yes, I get that this is "simple" lighting and its kind of dumb, but this just seems like a simple tweak that would avoid me having to write a not-so-simple RM to handle what is a simple control scenario. @bravenel I'd love to hear your thoughts. Im sure you will come up with a great scenario where my suggestion will break 10 other things... 
This is an old debate. A restriction is a restriction, period. The rule doesn't run while restricted. You can use two SL rules to get what you want, and only restrict the on one.
Rule doesnt run while restricted, of course. I think my argument only applies to delays. If the rule spawned an off delay while it was running, should the off delay really be killed along with the rule? The rule can stop due to the restriction, but the off delay that was triggered should still happen. I would consider this more of a bug, if you think if it in terms of the rule said it would turn it off after n minutes, but it failed to do so.
But the delayed off is part of the rule. I'm just gonna say one thing here....Bruce gave you the solution. Break it out into 2 Simple lighting rules; one that is restricted to turn on and one that isn't restricted to turn off. As he said, this issue has come up many times before. A restriction is a restriction is a restriction. It restricts EVERYTHING within the rule. That INCLUDES the delay to turn off, since it is part of the rule. Think of it this way, a restriction prevents the rule from doing anything at all.
It might not be what you want but that's the way it is. I guarantee you that someone else out there wants the delay off to be restricted.
I get it. Im just wanting to have the thought experiment to explore a possible improvement to the terse way it works, and to avoid the lights being left on, which is probably what most users would expect from something named Simple Lighting.
Okay....but it's not going to change. To change it now would cause issues to people who have the restrictions in place and want them in place. You see, you don't want the off delay to be affected by the restriction so you have an option, use two rules, one that's restricted for on and one that isn't for off. If the restriction did not cancel the off delay, those people that want that restricted have no option at all. So, the current implementation allows the most flexibility and therefore pleases the most people.
Download the Hubitat app
