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?
I have built both packages …binding.gpio and …io.gpio with the latest snapshot (1.9.0). They can be found under:
they work also with openhab 1.8.
3 Likes
Thanks Alejandro, I wonder if the mod’s can get this to replace the proper binding.
@watou can you get this added to the bindings? I’m not sure what the proper way to do this is
@kevin are you saying that there was a code change to the GPIO binding that appears in 1.9.0-SNAPSHOT that fixes a general bug, that bug exists in 1.8.1 of the binding, and you believe it should be fixed in a 1.8.2 release as well? If I have that correct, could you summarise the issue? Sorry for not following the subject until now.
@Watou something changed when the underlying operating system on the Raspberry Pi was updated from Wheezy to the later Jessie. This broke the binding. Earlier in this thread a binding was created that had the required OS dependency built in but only worked with the OH matching action bundle from V1.7,. This has now been updated to work with the current action bundle and I think the original binding at least needs it’s read me updating to point to the working one.
The binding has been created / modified by someone other than the original binding developer
Hopefully this makes sense!
There are two points which need to be changed in the org.openhab.io.gpio binding:
-
The included JNA jar is outdated and does not include the native .so libraries. Depending on the installed version of these native libraries the java part blocks trying to allocate a structure. The solution is to build the gpio binding with an actual JNA jar which includes the needed native libraries so there is no version conflict.
-
To allow other users to access the /sys/class/gpio file system it belongs to the group gpio. Thus adding the user openhab to the gpio group allows openHAB to access the gpio. When a new gpio pin is reserved an udev script changes the group ownership and permissions. The gpio binding must wait a few milliseconds in order for this script to finish. Otherwise there is a race condition and the binding tries to write to the pin before is is writable for the gpio group. The solution is to include a small wait time in the method that reserves the pin. Afterwards the pin is checked for read permissions and fails if not.
Beside of these two points which where a quick and dirty solution for me just to get started with openHAB and gpio access I would like to suggest to switch from JNA to Pi4J. The main reason is that Pi4J relies on hardware interrupts when waiting for pin value changes which is more effective than the polling used in the gpio binding.
1 Like
Hi @AlejandroGuirao and @kevin, could you update the currently open issue with your suggestions and knowledge of the issue?
I am very new to OpenHab and Linux, so I apologize for my questions in advance…
I have OpenHab running (on Jessie - raspberry PI 2), and able to get to the web interface, but not able to toggle a LED on/off using the GPIO.
Do I just need to download and install these files into the /addons folder, and not use the binding from the OpenHab site? Is there any other special configuration that I need to do?
Or, should I try to find a version of Wheezy and install this?
Thank you!
If the original files do not work try with the ones posted here. Besides of that you don’t need any configuration in the openhab.cfg or other files.
I seem to face a similar issue when i installed openhab version 1.8.1.
Is there any update on this issue yet?
Thanks
I tested the 1.9.0 gpio binding modules with OpenHAB version 1.8.2 on a RPi 3 with the newest Raspbian/Debian/Jessie distribution, unfortunately it didn’t work.
This was including the JAVA_ARGS setting to the right directory (checked the one to use).
How are we to proceed on this?
I use the snapshots from the above 15th Feb post with Jessie, with an additional patch I added to allow use with 4 port relays, it works well. I use no JAVA_ARGS related to this binding, they are not needed as the dependency is now within the binding file. IIRC adding them breaks the binding
Thanks Kevin,
So output works OK. Did you test the input function? That’s the problem over here.
I use both inputs and outputs without any issues.
Great Kevin,
I’m gonna give it a try again then, thanks.
One other problem you may encounter is if you have followed the following instruction from the GPIO Binding Wiki
“you need to add a parameter in command line which starts openHAB and specify the path to JNA library, e.g. edit the last line in “start.sh” and append -Djna.boot.library.path=/usr/lib/jni right after java”
On my system adding “-Djna.boot.library.path” anywhere in the startup file stuffed up the recompiled binding with Jessie. All was well once I removed this line and installed the new binding which has JNA already built into it
2 Likes