Raspian Jessie / GPIO input

I’ve found the debounce option to be tricky to get right with contacts. The devices on PIN 23, 24 & 25 have been my tricky ones, debounce is globally set to 100 which seems to be a good compromise. Haven’t had any problems with the outputs as long as I reset the items to OFF on boot before I apply power to the relays

I installed the 1.9.0 files and set the debounce globally to 100. The contacts work now, but not reliable. Sometimes the signal is missed and the status in openhab is not correct. The command gpio readall shows the correct readout. So the solution with 1.9.0 is not reliable yet.

That’s interesting, what are your actual contacts?
I use the locking mechanism on my uPVC doors to complete a circuit so that could be causing multiple bounces as the locking mechanism slides. We are heading into summer around here, so this will become more noticeable if its unreliable. If it does I will investigate further and put an oscilloscope on the output to see what is going on. I may well end up putting a capacitor across the contact GPIO pins for each door to get rid of any bouncing, although that may cause problems at the point when it switches from logic 1 to logic 0.
I wonder if the Openhab 2 binding is better

I use Pin 17 and 18, 27, 22, 23 and 24. All have the same problem. The readout of GPIO readall is allways correct, so it must be a timing problem in the driver. I think it reads the status only once.

Are you planning to try openhab 2?

I also tried GPIO:wait=xx on several values, but no improvement.
If the status readout is wrong, and I make the change the contact again form High to low, it will follow again. It is only sometimes, 10 % of the time, that the status is not correct. So it is not reliable at this moment.

Are all your pins exactly the same? Just wondering if one of them has a different contact bounce profile that makes it worse.
I will try Openhab 2 eventually. My 2 OH 1.8 instances are highly developed and working well. As they control pretty much everything in the house I need OH2 to be just as reliable as OH 1.8 with an easy upgrade path to limit disruption before I make the move. I also need to have sufficient spare time to do the changes and rollback if everything doesn’t work out.
Currently there is an issue with running OH2 on the read only image I use on my main system too which needs to be solved before I can migrate - details here Trying to install OH 2 beta 4 on OpenEnergyMonitor image
I don’t have this problem on OH1.8 as I manually installed it into its own read write folder

Having looked at this over the last couple of days I’d say mine is at least 90% reliable which is different to your 10% reliable

No it is the same. 10% of the time the status is not correct. I call that unreliable.

1 Like

As a workaround I wonder if its possible to read the status of the GPIO contact Pins every few seconds from outside Openhab using executeCommandline and then update them? Unfortunately this goes beyond my knowledge of Python / Linux / Java so I’m not sure where to start.

Yes Kevin. I could do that in Python, it is realy easy to that, but I think the GPIO binding is a basic function in openhab on a Raspbarry pi, so it needs to be fixed.

Since I did not get any input from my PIR but could turn on an LED on my Raspberry Pi from OpenHab, I wrote a short Python script to monitor the pin to make sure that the PIR actually worked. It did. I doubt that it would be particularly difficult to send a REST command to one’s OpenHab server in response to such a change. You don’t need to poll it, you can wait on the interrupt. Here is my [hacky thrown together] script:

#!/usr/bin/python
#+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
#|R|a|s|p|b|e|r|r|y|P|i|-|S|p|y|.|c|o|.|u|k|
#+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
# Based on a script by:
# Author : Matt Hawkins
# Date   : 21/01/2013

# Import required Python libraries
import RPi.GPIO as GPIO
import time
import datetime

# Define GPIO to use on Pi
GPIO_PIR = 4
GPIO_LED = 24

def motionChange(pin):
	
	Current_State = GPIO.input(GPIO_PIR)
	now = datetime.datetime.now()
	
	print now.isoformat() + ": Motion state = ", Current_State
	
	if Current_State == 1:
		GPIO.output(GPIO_LED, True)
	else:
		GPIO.output(GPIO_LED, False)
		
def main():

	# Use BCM GPIO references
	# instead of physical pin numbers
	GPIO.setmode(GPIO.BCM)

	print "PIR Module Test (CTRL-C to exit)"

	# Set pin as input
	GPIO.setup(GPIO_PIR,GPIO.IN)      # Echo
	GPIO.setup(GPIO_LED,GPIO.OUT)

	Current_State  = 0

	try:

		print "Waiting for PIR to settle ..."

		# Loop until PIR output is 0
		while GPIO.input(GPIO_PIR)==1:
			print "Waiting..."

		GPIO.add_event_detect(GPIO_PIR, GPIO.BOTH, callback=motionChange)
		
		print "  Ready"     
		
		# Loop until users quits with CTRL-C
		while True :
			time.sleep(1)      
			  
	except KeyboardInterrupt:
		print "  Quit" 
		# Reset GPIO settings
		GPIO.cleanup()
	  
if __name__ == "__main__":
	main()

However, before you go to the trouble of figuring out how to add REST calls to the script, I was able to get the GPIO working with OpenHab @AlejandroGuirao two jar files. OpenHab 1.8 Raspberry Pi running Jessie and without the -Djna.boot.library.path environment variable. Big thanks to @AlejandroGuirao.

The alejandroguirao binding does work about 90% of the time for incoming contact items and all the time for outgoing switch items, The problem is occasionally it misses contact items changing, my system’s problem is very noticable on 2 of my contacts

I guess I spoke too soon. Contrary to your findings I don’t seem to be able to turn on an LED via an output GPIO. The missed contact items is not really much of an issue to me since I use if for a PIR motion detector. If it misses one it’ll usually get another shortly afterwards and I only care about motion not the lack thereof.

I’d try using another pin in case it’s being held up by something else running on the Pi outside of OH

Well now I’ve had time to research the LED issue a little more thoroughly it turns out it was a bug in my code. It works fine now.

1 Like

@kevin, do you know if an issue / bug was reported for the GPIO incoming contacts? If so could you pass the link / number (I could not find it in this thread)

@Jeroen I don’t think it has a bug report, although there might have been one for the GPIO pins not working at all when Jessie came out. The inputs problem is a recent discovery

I would just like to add that I’m experiencing the same problem as reported by @kevin. Status of items in openhab doesn’t always correctly reflect the actual status of the pins as seen by the OS. I’ve experimented extensively with the wait and debounce options to no avail.

@maintainers can you advise how this intermittent GPIO binding contact problem can be reported as a bug and hopefully fixed please.
Several people in this thread seem to have the same problem

OH 1 issues can be reported here.

OH2 issues can be reported here.