I'm running Raspbian Jessie 4.9.35-v7+ on a Pi 3 Model B. I cobbled together a basic python script to monitor a GPIO pin and send a network signal to a remote application, made two copies of the script to monitor two different GPIO pins for two different network signals, and I launched the scripts from rc.local. I was originally using GPIO pins 2 and 3, which I later learned have physical pull up resistors fitted, but as I didn't initially understand that, I was running code including "pull_up_down=GPIO.PUD_UP" for GPIO.setup() in spite of that. Here is a sample of the baseline working version of that code:

#!/usr/bin/env python
import RPi.GPIO as GPIO
import signal
import socket
import time
#Define GPIO pin here:
thiscontact = 2
GPIO.setup(thiscontact, GPIO.IN, pull_up_down=GPIO.PUD_UP)
def watchopen():
    thisposition = GPIO.input(thiscontact)
    if thisposition == True:
        while thisposition == True:
            thisposition = GPIO.input(thiscontact)
def watchclose():
    thisposition = GPIO.input(thiscontact)
    if thisposition == False:
        while thisposition == False:
            s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
            #Define network server here:
            s.connect(("", 6802))
            #Define network signal here:
            thisposition = GPIO.input(thiscontact)
def exit_handler(signal, frame):
    raise SystemExit
signal.signal(signal.SIGTERM, exit_handler)
signal.signal(signal.SIGINT, exit_handler)

This was doing exactly what I wanted it to do, but one day the second copy (thiscontact = 3) got stuck in the watchclose() loop (while thisposition == False:) even though the connected switch wasn't closed. When this happened, I switched the physical connection to another pin and modified the script to use that pin. The script started working again, but I would intermittently get very brief false close detections (maybe 2-8 per 24 hours). The other copy of the script continued to work fine, so I assumed this was a physical issue, but decided I would deal with it later if the new pin I was using failed the same way pin 3 had. Much later, I had to modify the script and the new version started running into an exception, so I started logging. I didn't want this logged every time the scripts ran:

RuntimeWarning: A physical pull up resistor is fitted on this channel!

In researching that message, I found a way to disable the warning, but I figured the right way to do that would involve changing the GPIO.setup() parameters, and I figured it'd be easier to use a different pin than to research GPIO.setup() again (especially with two copies of the script and pin 3 presumably failed), so I moved the physical connection from pin 2 to another pin as well. Lo and behold, I am now intermittently getting very brief false close detections on that script as well (again, maybe 2-8 per 24 hours, and not necessarily at the same time as the other script). Because of this, I'm wondering exactly what I've stated in the title, do I need to install my own physical pull up resistors instead of relying on GPIO.setup to provide the pull up (and if so, at what ohm rating and to which voltage)?

In case it is relevant, both pins are connected to SPDT switches where the opposite throw is connected to a separate device (which is monitoring for an open as the Pi is monitoring for a close). Since there is only one common on a SPDT switch, the common on the other device ("Common") and the common on the Pi ("GND" per the hat I'm using) are bonded together, and IIRC, the common on the other device is also bonded to an earth ground (by manufacturer design). I believe this is the right way to deal with this scenario, and I am including this information only in case I need to be corrected.

  • You have 2 SPDT switches and 2 GPIO pins to read the switches. in your case, I would properly use 4 or even 6 GPIO pins and 6 SPDT switches, to compare and contrast. As I remember, most of the GPIO pins has 50k pull up, except the I2C pins (or also the UART pins, I forgot) have 1k8 pull up. Just to compare, I would also add 10k pull up in parallel, and see what happens. In short, no harm using 6 pins and 6 switches to compare, and 10k on top of the Rpi built in 50k/1k8 to compare. Do this trials and errors is of course faster than waiting for suggestions.
    – tlfong01
    Commented Jun 14, 2019 at 14:40
  • The 2 SPDT switches are for completely different inputs to control completely different outputs. They are hundreds of feet from the Pi in different locations. From what I've read, only 2 pins have pull-up on the 3 model B, but I never would have guessed at 50k. I believe one answer I was looking for is that the pull-up would go to the 3.3V, I read this after posting while researching debounce in case I could debounce this issue away (don't think I can since the switch isn't actuating). I guess I can trial an error different physical pull-up, just have to re-read about GPIO.setup first.
    – rpseu
    Commented Jun 14, 2019 at 14:49
  • I am confused. Do you mean that you connect wires from Rpi GPIO pins to SPDT switches hundred of feet away? If that is the case, then there are at least two problems: (1) the long wires are like antennas picking up 50/60Hz mains noise around, (2) SPDT switches, if connected to inductive loads, might send back EMF, EMI, sparks which might interfere logic circuits and Rpi, through the connecting wires and though space.
    – tlfong01
    Commented Jun 15, 2019 at 1:24
  • Yes, this is what I mean, but technically, they are door contacts, they are made for this (with hardware other than RPi, of course), and they worked fine on the pins with external resistors built-in, so far it appears that the solution is in the marked answer, PUD_UP is 50kOhm resistance, and that is too much resistance for a clean pull up in this environment.
    – rpseu
    Commented Jun 17, 2019 at 12:55
  • Thank you for your explanation. In you case of door switches, I think it is ok for long wires, because you are only reading DC voltage levels, not high frequency signals, which could be affected by noise.
    – tlfong01
    Commented Jun 18, 2019 at 8:06

1 Answer 1


You need to pull the GPIO to either 3V3 or ground in each switch position.

If you connect one end of the switch to ground it would be normal to connect the other end of the switch to a GPIO with a pull-up to 3V3.

If you connect one end of the switch to 3V3 it would be normal to connect the other end of the switch to a GPIO with a pull-down to ground.

You can either use the internal pulls or add your own.

The internal pulls are quite weak - about 50k ohm. It sounds like they are not strong enough to always overcome the antenna effect of your wiring so you get some spurious signals. That suggests you will have to add your own stronger external pulls.

  • You are saying that the internal physical pulls are 50k, right? I think that would imply that 50k is strong enough with pull_up_down=GPIO.PUD_UP, but what is that the equivalent of?
    – rpseu
    Commented Jun 14, 2019 at 14:52
  • The internal pulls (up and down) are all the same, about 50k ohm. GPIO 2/3 additionally have external 1k8 pull-ups to 3V3 as they provide the I2C bus.
    – joan
    Commented Jun 14, 2019 at 15:04
  • Just to clarify. The higher the value in ohms, the weaker the pull.
    – joan
    Commented Jun 14, 2019 at 15:05
  • OK, so does the internal 1800 ohm pull up on pins 2 and 3 paired with the PUD_UP pull work the same as a parallel pull in real life (leaving actual resistance below 1800 ohms when PUD_UP is on)? Put another way, if the PUD_UP and PUD_DOWN does about 50k ohm, but I wasn't having the problem on pin 2 (internal 1800 ohm) and I am having the problem on pin 4 (no internal 1800 ohm) with the same program, does that mean I actually need to add a physical resistor (to reduce resistance) to pin 4?
    – rpseu
    Commented Jun 14, 2019 at 16:09
  • It certainly sounds like it. I'd try something like a 10k resistor. If that doesn't work something like 4k7. Go down until the false signals disappear. This assumes that it is interference and not switch contact bounce.
    – joan
    Commented Jun 14, 2019 at 16:43

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.