Restrictions mean 'don't do anything if Restricted'.
This can create a dilemma when you have something Waiting, for example using motion to turn on lights and inactive to turn off, but the Restriction kicks in before they are turned off. If Restrictions meant something else than 'don't do anything', there would be all sorts of unhappy consequences. So, what that leads to is having to separate turn-on logic from turn-off logic if there is going to be a restriction involved, thus allowing turn-on to be restricted while turn-off to be not restricted. But, that leads to having lots of rules. In the built-in app Motion Lighting this is faced head on by having different ways to stop turning on and stop turning off, all in a single rule. If one tried to do what Motion Lighting does in Rule Machine or Basic Rules, you end up with multiple rules for what Motion Lighting does in a single rule. That's just the way this shakes out.
If I am understanding this correctly, the light turns on when the motion is activated and the light level is below a certain value thus also waiting for motion to stop. If the light level raises above the threshold (no loner restricted) and the motion is triggered, the timer is never set therefore the light will no loner turn off?
Seems to me I now recall this being the same thing I had issues with while playing with motion lighting, pushing me to either create multiple rules or to use RM
Seems to me, the restrictions should be attached to the original trigger event and the rule should finish executing regardless of any restriction changes... but that is just me and as since I am not a developer...
Unfortunately Restrictions for Basic Rules, and Pre-Conditions for RM both behave differently. It would make more sense if they work the same way, as I think that's what people expect from Basic Rules, just simplified RM.. It's really not intuitive that Restriction triggers in middle of rule run and cancels it half way through.
Perhaps to you, but not to someone who is counting on a rule not running when Restricted. Restrictions have existed on the platform for as long as it has been available, and they have always worked this way (and do so in all of the other apps that have Restrictions, such as Simple Automation Rule-1.1). Rule-3.0 and before had Restrictions, and this is how they worked then as well. This is also how Restrictions worked on ST back when that was relevant.
Predicate Conditions were just introduced, and while they can be used as sort of a restriction, it is not the same as these Restrictions. There was some discussion about perhaps Predicate Conditions should work the way Restrictions work, but they don't. If Predicate Conditions were intended to be the same as Restrictions, we would have called them "Restrictions", but we didn't, because they aren't the same thing in more ways than the one you are referencing.
A couple of basic points: Your use case is not everyone else's use case, and while you don't like how they work for your use case, what about those for who they do work correctly? We can't so aren't going to change how Restrictions work in Basic Rule.
Haha, no! Basic Rule is intended for beginners, and Predicate Conditions is an advanced feature for Rule Machine, intended for more advanced users. You could certainly solve your particular problem by using Rule 5.0 with a Predicate Condition! RM is not hard, it just has a zillion options and possibilities.
For yours, the trigger is Master Closet motion active; Actions are turn on Master Closet lights, Wait for Closet Motion inactive, Wait for Elapsed time 2:00, Master Closet Off; all with a Predicate Condition of your Restriction.
