Fun fact: sometimes you actually can do this in a rule to work around devices with wonky reporting. 
For a while, a lot of Z-Wave contact sensors were generating duplicate open/close events in quick succession, and so people with rules that notified them of these events were also getting duplicate notifications. A temporary solution was to use a local variable to tell if the rule had recently been run (not technically whether it was still running, as its execution would likely be fairly quick and have finished before the duplicate event comes in, but all of this generally within dozens or hundreds of milliseconds).
The best solution here is really for the device to not send the duplicates in the first place (for Z-Wave, there are often two "command classes" it may use, the "basic" one and one geared more towards its specific purpose); if that's not possible, the driver ignoring whichever it doesn't need would also be better (I think this is what Hubitat ended up doing; normally the platform also filters out duplicate events unless you tell it not to as the driver author, but these were coming in so quick the first hadn't finished processing yet). But if all of this is out of your control--as this was for most people for a while here--working around it in an app/rule is about all you can do.
Oh, and a local variable works better than Private Boolean here, or at least that is what the RM author mentioned when this "debouncing" issue came up. They sound similar but are apparently implemented differently (not sure how; I assumed both went to state and not one to state and one to a setting, so maybe there is something else--like how they get set) in ways that matter here.
