Raspian Jessie / GPIO input

Putting mine into debug and rebooting I get

10:19:11.684 [DEBUG] [o.o.b.g.i.GPIOBindingActivator:30   ] - GPIO binding has been started.
and then
<<<<one message per GPIO Item like the one below>>>>
10:19:11.734 [DEBUG] [i.internal.GenericItemProvider:341  ] - Start processing binding configuration of Item 'DoorBell (Type=SwitchItem, State=Uninitialized)' with 'GPIOGenericBindingProvider' reader.
and then     
<<<<one message per GPIO Item like the one below, and not in the same order as the messages above>>>>
10:19:12.762 [INFO ] [penhab.io.gpio.linux.GPIOLinux:270  ] - registering pin with number '26'
<<<<many messages like the one belowrest of the GPIO Items, one message each>>>>

The next question is what version are you using of the Bindings? You need TWO files, my working ones are called:


I suspect you may have only one of these present

Hi Kevin,

Unfortunately, I have both in my addon folder:

Same result if I change with version 1.9.0.
What is strange is that generally, I read many people had problems with only the Contact but at least the Switch were OK. In my case none of them works.


To answer your question about my version, I have
java version “1.8.0_65” Java™ SE Runtime Environment (build 1.8.0_65-b17)
Linux version 4.4.22+ (dc4@dc4-XPS13-9333) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611) )

What do you get from the command

cat /etc/*-release

I get

PRETTY_NAME="Raspbian GNU/Linux 8 (jessie)"
NAME="Raspbian GNU/Linux"
VERSION="8 (jessie)"

I’m on the exact same version of Java

1 Like

Hi Kevin,

Apparently, we have exactly the same version. This is what I get:

PRETTY_NAME="Raspbian GNU/Linux 8 (jessie)"
NAME="Raspbian GNU/Linux"
VERSION="8 (jessie)"

I guess the only things left are either permissions, or something outside Openhab holding the GPIO Pins, or a hardware fault.
I run Openhab as Root which might be worth temporarily trying. I also installed Jessie as a new install, maybe its worthwhile getting a new clean image of Jessie + Java + OH and seeing if that works. A quick google suggests there may be permissions issues with GPIO after upgrading to Jessie from Wheezy.
If I had this problem I’d get a new SD Card and create my own image of Jessie, then test GPIO, then add Java & OH 1.8 then test again. Interestingly enough there is work being done elsewhere on the forum creating OpenHabian openHABian hassle-free openHAB Setup and the last post asks about getting GPIO to work so perhaps there is an issue that is about to be documented on that thread.


I’ve had the same problem, I copied the 1.9.0 files into the addons folder and it works until one or two switching, but after that it stops displaying the value. I used the pin 17.
After I changed the pin to 27 and removed the debounce option and now it works.


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:

# 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

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)
		GPIO.output(GPIO_LED, False)
def main():

	# Use BCM GPIO references
	# instead of physical pin numbers

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

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

	Current_State  = 0


		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 :
	except KeyboardInterrupt:
		print "  Quit" 
		# Reset GPIO settings
if __name__ == "__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.