Trying to check event data in automation condition

I’m actually trying to do this in a blueprint, so that might change the answer…

TL;DR How can I remove a dependency on an input_boolean for a condition when the input_boolean state is determined by an event that is not the trigger event.

Problem: I want to prevent an automation (motion detection triggering light to turn on) from running for X min after a given event has been fired (light switch turned off). The event is a switch press for a Deconz switch, that can only be checked via listening for the deconz_event event.

The issue I’m facing is, I only seems to be able to use event data in a condition, if the event was part of a trigger for the automation (using trigger.event.xxx). However, my trigger is a motion sensor and not the light switch.

I have previously got around this by having the light switch event toggle an input_boolean and then my automation checks the state of the input_boolean in the condition section. This doesn’t scale for my blueprint, as I’d need to create a new input_boolean for every instance of the blueprint or else share state between instances, neither of which are suitable.

I can see the deconz_event in question has an attribute time_fired that is an ISO format date, so I thought if I could grab that and compare the current date/time, it might be a handle to use in a condition. But I can’t work out how to read that attribute (*see next comment).

The other option might be to add the light switch event as an additional trigger and then do some magic to prevent the action from running in some way… Not sure how this would work, if at all.

Thanks in advanced.

Answering my own question - I think it might be possible to trigger on the light switch event and then use the action: choose: conditions: sequence feature as demonstrated in this gist I came across. By adding a wait when the switch is triggered, which will block on any motion events until its finished running.

I’m also rethinking my aversion to having dedicated input_booleans for each room. If each room has its own light, motion and switch entities, then adding another one is probably OK. It just irks my developer sensibilities, as it should be possible to do it without this extra dependency.