It's not clear to me where the switch fits into this rule, so I assume there is something else to account for that. It is, then, also not clear to me exactly what you want this specific rule to handle, but here's my guess: turn on the lights when motion becomes active, then turn them off after a delay, but all only if Private Boolean is true? If so, as written, your "off" will happen even when Private Boolean is false--those actions are outside of the conditional that checks for this--so you'd need something like this instead.
IF (Private Boolean is True) THEN
Dimmers per mode: ... (per mode levels here like you have)
On: Bathroom Fan & Light
Set Private Boolean False
Wait for conditions: Motion inactive --> duration 0:00:30
Off/Dim Lights (etc.)
Set Private Boolean True
END-IF
(If you do want the "Off" to happen regardless, then....good job, and ignore me. 
)
The goal of Private Boolean here is to basically make sure these actions run only once, regardless of how many times your trigger event (motion becoming active) happens in the meantime. Private Boolean is only special because it's built-in to every rule without you needing to create a local Boolean variable yourself, but it's otherwise pretty similar (except you can set it from other rules, unlike local variables, but then there are also hub variables where you could do this). [EDITED TO ADD: you can use Private Boolean for anything you want--it's just a variable, and like any variable, only does something if you use it somewhere, however you may want to.]
Before going farther, it may make sense to ask yourself: do you care to prevent these actions from running more than once? Without this "check" in place, if motion becomes active during day mode, then the lights will get set to 95%, and if motion goes inactive for less than 30 seconds and becomes active again, then lights will then...get dimmed to 95%, which they likely already are. So the only reason you'd really need to do this if you want to avoid sending "On" or "Set Level" commands to your device when it's already on or set to that level--which in most cases is completely harmless (and has no real-world effect)--or if you plan on manually adjusting the level in the meantime and don't want new motion to take it back to the settings in your rule. Private Boolean might just be complicating things here.
Some other things you might want to know about rules in case you don't that may help explain how/why all of the above would work:
- any trigger event cancels all "Waits," so you don't need to worry about the wait/duration for motion inactive--it's cancelled, along with everything after it, and your actions start over with new motion (note: this is for waits, not delays, which behave differently)
- trigger events are the only thing (besides manually running the rule actions or running these actions from another rule or the Rule Machine API) that make your actions begin "running."
- not necessarily a problem, but "adjust by -100" is a bit of an odd action; if you want to turn off, the "Off" action should work, or if you want to perform a fade that the "off" action doesn't do for you, the "Set dimmer" action (which calls "Set Level" on the device) lets you specify a transition time, which most devices obey, and for most devices a "Set Level" to 0 is otherwise the same as "Off"--though, again, some devices may vary here and "Off" might be a safer choiec if it works for you.
Finally, I'm not sure I see anything here that the built-in Motion Lighting app or likely even Simple Automation Rules (which used to be called Simple Lighting if it gives you any clues as to the nature of the app's original featureset) could handle, so you might want to look in those first if you haven't already. Easier than writing a rule.
