It takes a while to get your head around RM 4, but thinking about it in the right way makes things simple.
A trigger is an event that happens. A door opened (just now).
A condition is a state that persists over time. A door is open (maybe it's been open for a millisecond; maybe it's been open for a week .. doesn't matter)
An action is something you want to happen if the trigger occurs while the condition is true.
So take your example quoted above and let's break it into parts:
Trigger - the motion sensor detected motion
Condition - it is between 23:59 and 04:00
Actions - 1) Turn on the light, 2) wait 5 minutes, 3) turn it off
I'd suggest making this an RM 4 rule to start. Then after a while you'll realize that you want to complicate it a little bit by saying that you want to restart that 5 minute wait every time motion occurs. You can do that with RM 4 also, but the Motion Lighting or Simple Lighting app may be a better choice here because the user interface is geared to that specific type of automation.
Is this really what you want, or do you want to turn lights on with motion, then turn off five minutes after inactivity? The rule above does literally what you asked for (the former), but that's a very unusual automation--usually, you'd want the latter. In that case, I'd suggest using Motion Lighting as suggested above, which can handle this case with ease. You could do it with RM (there's a very similar example in the documentation for Rule 4.0, which I'd read before you go too far), but I'd consider that overkill for a simple automation like this.
Although that is correct, the issue with a rule like this is that each time the motion sensor goes active within the time frame a new rule will be spun up.
You then end up with multiple versions of the rule running and errors happening as well as the lights doing od things because it might be completing one rule when it's starting another.
If the trigger was a switch or something that you manually triggered so didn't do multiple trigger by accident it would be fine.
So you would make the delay cancellable, add cancel delayed actions before the ON bedroom spot.
It would also be best to add the on within a simple condition of, IF (spot 1 is OFF) turn on spot 1. That just stops ONs being sent for no reason.
But even all of that still isn't fully correct because if you're in the room and the detector never goes inactive the lights would turn off even if your still in there. Which is why a more complex rule would be needed or use motion lighting as that is easier.
I wasn't trying to be glib. I use rules with no triggers all the time for things that are common. For example my Away and Bedtime modes both call a rule that checks all the locks and windows and announces any that are unlocked/open.
I have so far decided in favor of having one Rule set an RM variable or a Virtual Switch, and then Triggering another Rule on that variable or VS; I prefer that approach because I can monitor that variable or VS from a Dashboard tile. But those Rules could certainly be written as no-Trigger rules simply called from the other Rules that are setting the variable or VS.
Here is a RM4 rule demonstrating how to handle multiple activity event during the timeout period. Each event resets the time out so the lights stay until there is no activity for 5 minutes.
As mentioned earlier Motion lighting is a good fit your case. I assume Motion Lighting code is faster than RM4 code. I have no idea if that is true.
Soon though you will find you want to add more compilacations, you can pile on rules to suit but eventually the time between trigger and action gets to be too long. Not the best for motion detection. This will not be a problem for this case but I wonder, as an exercise, could this case be coded without testing the time every time there is motion? The goal being to write code that is the most efficient for the hub.
P.S. Would you consider using sunset and sunrise instead of specific times? I assume you want the lights on if it's dark out.
Because I hate getting Err 500 and losing a lengthy rule which I've been sweating over I often break out sections into sort of subroutines and call them from the main rule. Err 500 doesn't happen often, but I just try extra hard not to lose any rules. Editing is easier too IMHO.
And example would be if I want to set all my Google minis to a certain volume I have a rule with the actions in it. I can then call that action from multiple rules without duplicating the code.