Steven R - Thanks...you are 100% correct in that there is a serious flaw in my logic. I really didn't think past raising the DELAY in the macro greater than the preset delay (before OFF transmission) from the I/R sensor. I was really more concerned in trapping conflicting OFFs from multiple sensors controlling one light, which it seemed to do (I try to explain this below).
Anyway, I spent most of last night and this morning obsessively trying to find a way to do a longer DELAY but I finally ended up with so many flags and conditionals that it became nonsense...so, OldTimer's advice about simplicity looks pretty good at this point. But I still would really like to avoid the exact problem that Oldtimer describes with the bathroom light - it's disturbing when you are in there reading and the light goes out...and you have to do the hand wave-thing but a delay is a delay and that issue would persist no matter what. My real aim in using that as an example of what I wanted to 'fix' was to apply that fix to my Lanai lights and my outside spots where I use multiple I/R sensors (same house code, different Unit codes for each) to control the lights. This is where that 'fix' would be really useful.
Simply put (and assuming a 1 - minute default preset delay in the sensor), if I walked past one sensor in the yard and it turned on the outside spots (via it's macro), and then walked further down the yard and tripped another sensor to turn on the same lights (via it's macro separate from the 'first' sensor's one), I would like to have the OFF ignored from the first sensor and only have the lights turn off in response to the most recent OFF from the sensor most recently tripped. Otherwise, if after tripping the first sensor it takes 50 seconds to walk down to and trip the second sensor, the spots are still going to turn off at the one-minute mark in response to the first sensor's OFF (if I'm thinking about this correctly). I hope this makes sense...working around this seems like it should be an easy thing to do. Thoughts?
I've twisted my brain on this one now, but I think that as long as I keep the DELAY in my original code less than or equal to the delay programmed into the I/R sensor, the timing will stay such that all re-trips withing the DELAY period will extend the overall delay by the delay, in perpetuity (although one or two might slip by now and then between the 'real' time delay and what we'd calculate on paper). I think this fixes the two-sensor problem I've described above, but I'm not sure. So, just in case I'm making sense at this point, I'd like to know if you'd agree.
Once again, thanks for the help!