I've got a problem with my circuit builded with my raspberry pi B rev 1. I've got a button which press triggers a function in python, triggered with the line

GPIO.add_event_detect(7, GPIO.FALLING, callback=my_callback, bouncetime=300)

This function change the status of a variable (from 1 to 0 and viceversa) and change the power of two led (1 green led on, red led off, 0 green led off, red led on). But when I accidentally touch a pin of one of the 2 leds, the function are triggered without pressing the button.

The scheme of the circuit is here: https://mega.nz/#!RAoy0b6R!kFVgyj4iJrY7 ... qux1vcwjik

The leds are placed in a led holder, touching it, the pressing of button are simulated.

What can I do to solve the problem ?

back of LED panel breadboard inside a plastic project box

  • When trying to view the circuit, it wants to install an app. That's not what I want to do. Can't you just add an image of it?
    – ott--
    May 25, 2016 at 20:01

4 Answers 4


In my own Raspberry Pi project I see unexplained detections on GPIO inputs frequently. This is despite an appropriate pull-up resistor. I'm getting false positives at the rate of between a few and hundreds per day. The following code filters these perfectly, and I've never had a false indication get through or a valid indication fail, after 24 hours a day for a year or so. The code is labelled "debounce", but it is really also filtering out glitches.

Normally, I call GPIO.wait_for_edge() but then call this routine to validate it:

# debouncedInput reads the specified GPIO pin and 
# returns the first state (0 or 1) that we read three times in a row
def debouncedInput(pin):
    tries = 12
    i, ones, zeroes = 0, 0, 0
    while i < tries:
        if (bit == 1):
           ones = ones + 1
           zeroes = 0
           zeroes = zeroes + 1
           ones = 0
        i = i + 1
        if (ones >= 3):
            return 1
        if (zeroes >=3):
            return 0
        time.sleep(0.5) # wait a bit

    # indeterminate state, tries exhausted
    logging.error ('Bouncy input: %s', pin) 
    return (bit)   #best effort 

My lack of confidence in my own hardware skills and in hardware in general led me to write this code before the hardware was finished and before I had any problems with false inputs. Surprisingly, this code turned out to be extremely necessary and it worked right away.

You could probably get away with a much shorter sleep period. In my case, a second or two didn't matter and reliability was more important than promptness.

  • Have you considered finding the root cause of the false signals instead?
    – joan
    Jun 29, 2016 at 13:10
  • For a "debounce" you actually want to use a relatively short time (<150 ms; if you look at oscilliscope measurements of bounces online they don't go on longer than that) when the button goes down, then the same when the button goes up; this means you don't have to assume the user is just going to press the button down for a minimum duration of 1-2s (it is pretty much impossible to do it for only 1/10s) and allows you to measure the duration of a press in contexts where that might be useful.
    – goldilocks
    Jun 29, 2016 at 13:10
  • @joan Yes. I failed to eliminate the glitches. I added some external filtering and an external pull-up resistor. I kept the wires to the switch as short as possible (~12 inches). My best guess is that my GPIO port suffered some accidental damage by contacting higher voltages, and that this is the root cause. But, hey, it's working fine for me.
    – Jamie Cox
    Jun 29, 2016 at 13:16
  • This is working well for me so far. With some experimenting, I am finding that a value of 0.01 for the sleep value makes it so that its extremely hard for me to try and click the button too fast. It appears to register all of my clicks. Also, it does not register a single click multiple times. And most of all, so far it is filtering the random false events that were happening out of nowhere. Thanks for this @JamieCox
    – jrel
    Dec 4, 2020 at 5:00

A false positive suggests there is no electrical reason for the edge being detected.

In this case there is an electrical reason - noise in one part of your circuit is affecting another part of the circuit.

The first thing to ensure is that you have a pull up or pull down on your button to ensure a stable state. You can set an internal pull up or down using a software option (look at the documentation for RPi.GPIO) or you can add an external resistor. If the button reads low until activated use a pull-down to ground (0V) otherwise use a pull-up to 3V3.

  • I've put pull down resistor to ground as you can see in the electric scheme. The led holder are made of conductive material but the led doesn't touch it. Mar 26, 2016 at 12:55
  • @FloydCrimson Schematics are not very useful in diagnosing problems. There is often a disconnect between a schematic and the implementation. Clear photos are far more useful.
    – joan
    Mar 26, 2016 at 13:02
  • 1: mega.nz/#!MExXWQBY!hHfOpvu8dhKMZbaJwTADM4eQO699d4N2vwE-q1u24K4 2: mega.nz/#!hBwzwbpR!r3y4wCGBCSSZdz9aQJFSOqs_4mLeIS88gGpCGpbHQLQ In the first photo you can see the setup of the two leds (upper) and the button. In the second photo you can see the implementation: the red wire near the yellow one are connected to the 3.3V of the raspberry, brown wire to GND and the red one on the same line of the grey wire are connected to gpio input port. yellow and grey wires are connected to the button. Mar 26, 2016 at 13:25
  • 1
    @FloydCrimson You should edit additional detail into your question NOT in comments. Also the link fails on my browser.
    – Milliways
    Mar 26, 2016 at 22:26
  • Sorry, I've tried links in another browser and they run well... Mar 27, 2016 at 14:35

I cannot confirm on the fact of not seeing the rest of your code, but here are some things to look for:

  • List item it seems that you are using RPi, make sure that your pi connection pins and your "GPIO.setmode" are correct with each other.
  • If you are manually creating a pull-down resistor and setting one up on the Pi via code, for ex "GPIO.setup(25, GPIO.IN, pull_up_down=GPIO.PUD_DOWN)", these could cause conflict between one another

EDIT: I also learned that it is good practice in coding embedded systems to test with only zero in statements:

if (input != 0) # Besides if (input == 1)





if (input == 0)




Which makes sense in ADCs

  • Also to add, you must test when the button is release so you don't repeat it numerous times.

  • A good measure to testing is to try holding it down before you run the script. then, run it, wait a minute, and release.

Here is a good example of what you are trying to do: http://raspi.tv/2013/rpi-gpio-basics-6-using-inputs-and-outputs-together-with-rpi-gpio-pull-ups-and-pull-downs


I found the wait for edge is only good for digital signals, not buttons... Similar to Jaime Cox, I implemented some "consistency" logic... Relative to the OP, this is actually triggering on the release. To find the rise, you would count inside the range loop.

import os
import RPi.GPIO as GPIO
import threading
from time import sleep

pins=(17, 27, 22, 10, 9, 11)
for pin in pins:
   GPIO.setup(pin, GPIO.IN, pull_up_down=GPIO.PUD_DOWN)

class buttonThread (threading.Thread):
   def __init__(self,threadID,pin):
      self.threadID = threadID
      self.pin = pin
   def run(self):
      print("Starting Thread: "+str(self.threadID)+" Pin: "+str(self.pin))
      while True:
         for i in range(0,100,1):
            if GPIO.input(self.pin):
         if count:
         if count > 10:
            print("Pin "+str(self.pin)+" triggered")

for pin in pins:
   thread=buttonThread(pin, pin)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.