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.setmode(GPIO.BCM)
GPIO.setup(thiscontact, GPIO.IN, pull_up_down=GPIO.PUD_UP)
def watchopen():
thisposition = GPIO.input(thiscontact)
if thisposition == True:
while thisposition == True:
time.sleep(0.1)
thisposition = GPIO.input(thiscontact)
watchclose()
watchclose()
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(("192.0.2.248", 6802))
#Define network signal here:
s.send("1|do+3|255")
s.close()
time.sleep(0.9)
thisposition = GPIO.input(thiscontact)
watchopen()
watchopen()
def exit_handler(signal, frame):
GPIO.cleanup()
raise SystemExit
signal.signal(signal.SIGTERM, exit_handler)
signal.signal(signal.SIGINT, exit_handler)
watchopen()
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.
