With automations, funky Z-Wave issues, People (kids?) pressing buttons--there are a number of uncontrollable situations that could trigger an app multiple times in a row.
Are there any good solutions?
In some cases, it would be helpful to simply ignore anything that re-triggers the app withing mm:ss amount of time.
In other case, it might be helpful to "queue up" the requests so they wouldn't run for mm:ss amount of time.
Bonus points for being able to include this app and related ones in those times. 
This may be good "feature request" for something in the future--but I was also wondering how people deal with this now?
It came up for me-because my door locks can generate multiple (often 2) trigger events at once, which created some unexpected behavior (thankfully, nothing crazy--when my rule ran again, it recognized it had little to do, but I'd like to avoid the "two threads of an app at once" scenario as several of my rules can take a few minutes to run.
I suspect I can think of some ways to do this with global variables, etc. I shy from the Private Boolean, only because it could be all to easy for "bad timing" to leave that in a bad state far past the time window I'd want.
Perhaps, a global time variable for each app group, with a time. Then, first thing, the app(s) could compare the current time to that--and either exit or wait if it was too soon (would the Rule Manager allow a second instance to start and exit/wait like that?). This would only work for a second instance tho--as instance 2, 3, 4, etc. would all fire at the same "expiration time" if I wanted them to queue up--not sure the RM is able to easily manage a "stack" (ugly, but one could code a fixed number of times--but it would be a hard coded limit).
Thoughts?
