Your triggers are pretty convoluted if that is the goal. Why not get rid of the conditional triggers and just trigger on the actual events? My first guess would be some race condition between your trigger events and the conditions that refer to the same attribute on the same devices, a somewhat odd setup.
As a guide: triggering a rule based on specific events is better than a "changed" trigger for an entire attribute in almost every case, so I'd normally suggest that when starting a rule.
See if that helps, if not, see what logs say again!
Simpler is better. The conditional triggers aren't adding anything to the rule and I'm not sure that having the triggers and the condition be the same attribute is supported.
If you want to reduce the number of triggers where the logic has to be evaluated, trigger only on closed/off events. Your if/then in the actions takes care of the rest
So... if the door opens, no trigger happens.
If the door closes, it triggers and checks the status of the two motion sensors
If the motion sensor turns on, no trigger.
If a motion sensor turns off, trigger and check the status of the door and other motion sensor.
Or, if you must use conditional triggers, you could do some of the logic in the triggers by having each motion sensor conditional on the other:
Trigger 1: Door closes
Trigger 2: sensor one turns off (only if sensor two is off)
Trigger 3: sensor two turns off (only if sensor one is off)
With those triggers the actions would only be evaluated when both motion sensors are off, not when the first one turns off.
Look at the "Zone Motion Controllers" user app. It combines motion sensors into a single zone. I use it in my basement and garage where I have multiple motion sensors.
Triggers don't have much logic; if the specified event happens, the actions will run. Conditional triggers add a tiny bit of logic, but in your case, I don't see anything you're doing with them that you couldn't do by just triggering on the actual event you want instead of "changed." A trigger of "X changed only if X is off" is essentially a convoluted way to say "X is off," and what I meant by race condition is that you might be dealing with tiny timing problems between the generation of this event and checking the resulting state. Maybe not here, though, since it's probably being checked in the same instance of the rule and it shouldn't be running if it didn't see them change, but still, I don't see a reason to write the trigger like that.
(And to be clear, the condition on a conditional trigger applies only to that trigger, and any matching trigger will trigger the rule. The state of the condition on one conditional is trigger will not prevent the rule from triggering if another trigger matches.)
You can put logic that looks at all devices in your actions. (You are already doing that.)
I think the ideas others suggested above may help. And perhaps a look at the docs will make things clearer, as they explain how all this works:
