This “logic flaw” occurs elsewhere too. If “Sunrise/Sunset” occurs in the middle, etc. “if 10pm…” occurs in the middle. Anywhere there’s a lengthy event and the conditions of the event change before the end.
example: “turn on light by motion between sunset and sunrise - turn off 15 mins after motion stops [cancel]” <-- walk into the room 8 mins before sunrise and the light will never turn off.
Here's what I have been using for my hallway motion sensor and light that I prefer to be active 30 min before sunset, and to stop reacting af 1 am. I used to do this with ST and Stringify. Most of the time it worked, but it was sometimes a bit slow to react, if and when everything cloud and internet was working.
This turns on my hall light 30 min before sunset for 4 min if motion does not continue. It also turns off the light after 10 min if it is manually activated by the nearby Lutron Connected Bulb remote. This was a compromise I made, since Hubitat cannot know the state of the button, only the state of the bulb. So this limits the annoyance of the light turning off in
4 min when someone has intentionally turned it on via the switch, but is not in range of the motion sensor or they have not moved for longer than 4 min.
Might be some unnecessary settings in this Rule, as I'm still learning the ropes, but it's working exactly as expected and reaction time is finally instant on a consistent basis!
This is the way around the restriction problem. There really is no way for restrictions on mode to mix nice with things that turn off after some amount of time. By definition, the restriction applies to the actions of the rule, and you wouldn’t want it any other way.
If you look at Motion Lighting as an example, it separates the options about when to turn something on from the options of when to turn something off. Ultimately, this is the way you have to think about this type of lighting automation --> and was one of the reasons Motion Lighting came into existence.