I think I have a way to get this to work:
First of all, at a conceptual level you need to separate the tasks that might be fired by the double-firing device into two parts. Part one are ones that it doesn't matter if they are done more than once. For instance, turning on a light. You can send a second On command to it and that doesn't matter. Part two are those tasks where it is important that they only run once. These are the ones that are problematic and need protection.
For technical reasons Rule Machine uses a form of scheduling that doesn't help in the resolution of this with respect to part two. For part one things, an ordinary rule can be used. We need a small custom app for part two to do the debounce. What the app does is subscribe to the double reporting device. It schedules a handler within the app to run some number of milliseconds later. The normal scheduling approach has each new schedule request overwrite any existing schedule request. So, assuming that part two can wait 200 to 500 msecs, this would guarantee that part two only runs once. It could be that the total delay in this app could be reduced to 100 msecs -- would just have to check out if that works.
Here is the debounce app.
Give that a try. It creates a virtual contact sensor that is debounced. Both open and close are debounced. Here is a sample of what happens:
While this case has the double event happening in about 150 msecs, as opposed to the very short times you showed, it should work for both cases. Notice that the debounced contact actually opens in this case a bit less than 200 msecs after the last open event on the double reporting device. There's slop in this logging timing.
This app could be used as a template to debounce a double reporting motion sensor.
