That’s exactly what I tried. Didn’t seem to work. Didn’t look into it any further.
libjna-java-3.2.7 works with both openhab 1.7.1 and 1.8.0, running as user openhab. Unexporting of gpio is done is the start script for me (echo > /sys/class/gpio/unexport).
Using 1k resistors in the wired sensor/switch paths.
BTW:
The current 1.8 builds still come with JNA 3.2.7, which is rather outdated. Will the final (and ultimate) build be with 4.1 or will OpenHAB1 stick to the old JNA?
Quite a few people seem to use it on Raspbian, which shows the problem (as any new debian would - but there aren’t that many Debian-PCs with GPIOs out there).
it works now!
at first i tried the method @TSchenkel suggested, but something went wrong.
when i did the uninstall (sudo apt-get autoremove libjna-java), the gpio bindings are removed too, automatically.
so i installed libjna-java_3.2.7-4 and then again the binding via apt-get.
after a reboot i couldn’t access the webUI, a quick look into syslog revealed that some java errors caused OH to shut down…
then i started all over again, fresh JESSIE install with openhab via apt-get, install gpio binding via apt-get and just replaced the org.openhab.io.gpio…jar as @Steamrunner suggested --> that works now!
i hope in 1.8 the newer JNA is used!!
thx @ both of you for working on a solution!!
After a bit of experimenting with version 1.8 I downgraded again to 1.7.1. Didn’t manage to get it to work with the jar I compiled earlier. Didn’t try to recompile yet.
what can we do now, where to start really fixing this? 
i mean, GPIO not working on raspian JESSIE even with the latest OH 1.8.0 is really frustrating…
it’s basically useless.
who wrote that binding?
thx,
stefan
This binding is really a bit troublesome 
Apart from the problem I described in my previous posting (race condition) there is a problem with the jna libraries. The original binding comes with jna-3.2.7 which is really outdated (as also noted by TSchenkel). The actual version is 4.2.1 (see https://github.com/java-native-access/jna#download). Important for jna is also a library named libjnidispatch.so. When the installed library (for example with apt-get install libjna-java) does not correlate with the used jar the whole thing does not work.
I have substituted the jna-3.2.7.jar in the binding package with the actual jna-4.2.1.jar which also comes with the libjnidispatch.so for lots of different platforms (although for gpio we only need arm).
I have also included my previous fix to prevent the race condition with udev scripts. I changed it so it is no longer an infinite loop. No it has a timeout and throws an exception when the files in /sys/class/gpio are still not writable. The corresponding reserve method is as follows:
/**
* Exports the pin to user space, creates and initializes the
* backend object representing the pin. Updates the registry for
* initialized pins.
*/
public GPIOPin reservePin(Integer pinNumber) throws IOException {
final String SYSFS_CLASS_GPIO = sysFS + "/class/gpio/";
GPIOPinLinux pin = null;
/* Variable 'sysFS' may be null if mandatory pseudo file system 'sysfs' isn't mounted or mount point can't be determined. */
if (sysFS == null) {
throw new IOException("Mount point for '" + SYSFS_VFSTYPE + "' isn't configured and can't be determined");
}
/* Sanity check, negative pin number is illegal. */
if (pinNumber < 0) {
throw new IllegalArgumentException("Unsupported argument for 'pinNumber' parameter (" + pinNumber + ")");
}
/* Acquiring write lock guarantees atomic check/set operation */
try {
if (gpioLock.writeLock().tryLock(GPIOLOCK_TIMEOUT, GPIOLOCK_TIMEOUT_UNITS)) {
try {
if (gpioRegistry.containsValue(pinNumber)) {
throw new IllegalArgumentException("The pin with number '" + pinNumber + "' is already registered");
}
/* Exports the pin to user space. */
Files.write(Paths.get(SYSFS_CLASS_GPIO + "export"), pinNumber.toString().getBytes());
/* Create backend object */
pin = new GPIOPinLinux(pinNumber, SYSFS_CLASS_GPIO + "gpio" + pinNumber, defaultDebounceInterval);
/* wait until udev scripts gives write access to current user */
try {
Thread.sleep(udevWait);
} catch(InterruptedException ex) {}
if(!pin.isWritable()) {
throw new IOException("Pin with number '" + pinNumber + "' is not writable.");
} else {
logger.info("registering pin with number '" + pinNumber + "'");
}
/* Register the pin */
gpioRegistry.put(pin, pinNumber);
} finally {
gpioLock.writeLock().unlock();
}
} else {
/* Something wrong happened, throw an exception and move on or we are risking to block the whole system */
throw new IOException("Write GPIO lock can't be aquired for " + GPIOLOCK_TIMEOUT + " " + GPIOLOCK_TIMEOUT_UNITS.toString());
}
} catch (InterruptedException e) {
throw new IOException("The thread was interrupted while waiting for write GPIO lock");
}
return pin;
}
There is now an extra option in openhab.cfg: gpio:wait wich gives the time to wait for udev scripts in milliseconds. If not specified the default wait time is 50ms.
Now there is no necessity to install jna on linux and no parameters have to be given in /etc/defaults/openahb. This solution worked out of the box on various of my raspberries with different systems. I hope it works for you too and we can close this thread 
Here you can find a compiled and packaged binding: https://www.dropbox.com/s/zn3nroyks9odizz/org.openhab.io.gpio_1.7.0.jar?dl=0
good luck
I haven’t tested it but i don’t see why it shouldn’t work.
I have this problem too,
the binding above doesn’t work giving me no inputs or outputs.
sudo dpkg -i libjna-java_3.2.7-4_armhf.deb from post 18 doesn’t work as it has the error below
libjna-java depends on libffi5 (>= 3.0.9); however:
Package libffi5 is not installed.
I have opened a GIT issue on the binding page so hopefully it can be fixed.
I am running Openhab V1.8.0 released version, and happy to help test any fix. I have a selection of input and output items.
Have you tried
apt-get install libffi5
dpkg will not install dependencies, as apt-get would.
TS
Could you please post the relevant entries and files? What items you have defined. Is openhab executing as root or as openhab?
Sure, the entries are exactly the same as used in Wheezy as I copied over the full configuration folder albeit in a slightly different path so I edited the relevant bits to point to the new path. I’ll just pick the first example of each to save room.
From default.items
Doesn’t work
Contact WashingDone "Washing Done Contact" { gpio="pin:21 debounce:250" }
Works
Switch HWC { gpio="pin:16 activelow:yes" }
Openhab IS operating as root, From /usr/lib/systemd/system/openhab.service
User=root
Group=daemon
WorkingDirectory=/home/pi/data/openhab
The whole installation sits in the directory above which is the same setup as in Wheezy
from the startup script, added after loading the old version of jni, contents of this folder is libjnidispatch.so dated 04-12-2011 23:33
-Djna.boot.library.path=/usr/lib/jni
Please let me know if you need any more details
Thanks, that fixed that error. Will try the binding again and see if it works
@TSchenkel
Sadly I didn’t fix the error, so I’ve started with a blank SD Card and a full copy of Jessie together with the same copy of Openhab V1.8.0 I used with Wheezy, with all its items stripped out apart from 1 x GPIO contact and 1 x GPIO switch. I’ve added to them a physical LED on the switch and a physical contact on the Contact item, so I can test on a spare Pi.
So far I’ve discovered
Test setup works flawlessly with Wheezy.
Current Binding and New BInding above doesn’t work on Jessie, adding libjna-java_3.2.7-4 doesn’t fix it in either case (added parameter to startup script to point to libjna). Openhab V1.7.1 won’t run on my copy of Jessie, I’ve installed it be replacing the V1.8.0 runtime files with V1.7.1 so there may be something else that needs changing.
I’ve now ran out of time (GMT+13) so I welcome any suggestions for tomorrow when I can try them out.
Just a thought, does the binding in post 27 now require a version 4 libjna?
No the jar in post 27 comes bundled with its own jna (4.2.1) so it doesn’t need to be installed separately. Neither is there need of -Djna.boot.library.path=/usr/lib/jni.
I will try a clean Jessie image and openhab 1.8 this weekend.
Thanks, I’ll try removing the path just in case
@AlejandroGuirao I removed the path with the following results:
Leaving the path in on V1.7,1 crashes it when the GPIO pins are processed on starting
V1.8.0 needs both the rewritten org.openhab.io.gpio binding and also org.openhab.binding.gpio-1.7.1
It does not work when the rewritten io is combined with the V1.8.0 binding.gpio.
Putting the working V1.7.1 combination together on V1.8.0 crashes it if the JNI path is set.
I’ll put the working combination onto my V1.8.0 live system later today and give it a thorough test.
Assuming it works I guess we need some form of V1.8.0 released version to prevent confusion.
Additionally the GPIO Binding always sets the outputs active when the PINS are initialised, do you think this behavior can be changed to read a openhab.cfg variable and behave accordingly?
TI’ve now put everything live and it works a charm. Apart from GPIO 17 being held on my system by something outside of Openhab on the image I’m using. Changing to another clean image fixes it, Can anyone suggest where to start with finding out what’s keeping it busy?
The GPIO Pin 17 problem was traced back to another module on my Jessie distribution holding the PIN. I’ve now rebuilt another image with out the problematic module and all works well.
Is there any way of getting this binding put into the original release so nobody else has the same problems getting it to work on Jessie?