By "de-bouncing" I meant a software scheme to rule out clicks that came too close together. The term comes from the fact that mechanical switches have significant bounce when closed. If software is polling the switch or servicing interrupts fast enough it can read the bouncing as more than one switch action. In a worst case the switch is a momentary contact which is supposed to be a toggle between on and off. In this case the final state of the switch depends on whether the system reads an even or odd number of closures. If it is supposed to merely read the final state of a two (or more) position switch it will eventually read that state correctly. But if it is supposed to take certain actions on each transition it might take them unnecessarily for the bogus closure events.

In either case a de-bouncing scheme is often implemented where the switch is read several times and the same value must be read so many times in a row. In the case of simple events it can read one event then exclude all others for some fixed amount of time. The challenge for the designer then is to know how long that time should be so that real events are detected but bogus ones are not. This could be implemented on the microprocessor in the detector unit or in the display unit. Of course all this assumes that the wireless transmission itself is not confused by other nearby systems.