Motion sensor tripped changes from 0 to 1 question

This is a simple question. I have a Reactor sensor set up as shown below.

I expected the motion sensor (reardeck_motion_sun) condition to act like a pulse and would momentarily go green/true (when watching in the status window). However, it stays green/true for the time equal to the motion sensor’s reset time.
Is this what I should be seeing?
I set up my actions to turn a virtual switch (rear_floods_motion_c) to 1 to indicate the motion sensor turned on the light.
This allows me to turn on the light manually and not have the automation turn them off. But with the above, I cannot manually turn off the light until the motion sensor resets.

I am not sure how ‘pulse’ in the group would help - it seems once the lights are manually turned off, the group is true again if the motion sensor has not reset. I don’t think I can set a latch for a duration, because a manual light turn-off will reset the latch enabling the group to go positive again. And I am not sure if the ‘activity’ is only when the group goes true or is executed as long as the group is true (I am limited in my testing right now).

I have read through the Reactor documentation and missed what I need. Any recommendation is appreciated.

Activities are implemented when the group changes from true to false or false to true, so I could set the group’s pulse to equal to or slightly longer than the motion sensor’s reset time? which could also be the amount of time I want the light to stay on?

In the absence of options that modify the default behavior, a condition will follow the state of the controlling device. So by default, if the motion sensor has a 4-minute reset period, that’s how long the condition will remain true. That’s in the default “follow” output mode. You can set the output mode to “pulse”, and that would cause a single shorter pulse when the motion sensor trips (assuming you set the pulse duration shorter than the reset time). You would get only one pulse until the motion sensor itself resets/untrips (and then still not until it trips again).

Conditions only trigger on changes, and activities only run on changes. They are “edge-driven”, not “state-driven”. When a condition group goes true, its activity will run, but will not run again until the group has transitioned back through false.

If you haven’t seen it, you might watch the video about simulating the behavior of DelayLight, which provides both automatic and manual control and timing: Reactor: Tutorial and Cookbook Videos on YouTube - Reactor - Ezlo Community (video #006)

Thanks for the help on this. I revamped the Reactor sensor.
I used the ‘pulse’ output control in several conditions to ensure no conflict and as you can see from the attachment, one condition will be true most of the time. I also learned how to use the Variables feature. Nice software!!