The (automatically downloaded, as im tmp?) serial Port Libraries (libNRJavaSerialv7.so, /libNRJavaSerialv8.so) seem to be incompatible with either Openhab3 or Azul Java. I run OH3 on a RPI1, using Azul Java. I activated the comfoair binding in addons.cfg. During runup, errors appear in the syslog.
Jan 17 09:55:58 raspberry karaf[409]: unsupported JNI version 0x00000002 required by /var/lib/openhab/tmp/libNRJavaSerialv8_HF_openhab_0/libNRJavaSerialv8_HF.so
Jan 17 09:55:59 raspberry karaf[409]: /var/lib/openhab/tmp/libNRJavaSerialv8_openhab_0/libNRJavaSerialv8.so: /var/lib/openhab/tmp/libNRJavaSerialv8_openhab_0/libNRJavaSerialv8.so: cannot open shared object file: No such file or directory
Jan 17 09:55:59 raspberry karaf[409]: unsupported JNI version 0x00000002 required by /var/lib/openhab/tmp/libNRJavaSerialv7_HF_openhab_0/libNRJavaSerialv7_HF.so
Jan 17 09:56:00 raspberry karaf[409]: /var/lib/openhab/tmp/libNRJavaSerialv7_openhab_0/libNRJavaSerialv7.so: /var/lib/openhab/tmp/libNRJavaSerialv7_openhab_0/libNRJavaSerialv7.so: cannot open shared object file: No such file or directory
ll /var/lib/openhab/tmp/libNRJavaSerialv7_openhab_0/libNRJavaSerialv7.so /var/lib/openhab/tmp/libNRJavaSerialv8_openhab_0/libNRJavaSerialv8.so
-rw-r--r-- 1 openhab openhab 62108 Jan 17 09:55 /var/lib/openhab/tmp/libNRJavaSerialv7_openhab_0/libNRJavaSerialv7.so
-rw-r--r-- 1 openhab openhab 62080 Jan 17 09:55 /var/lib/openhab/tmp/libNRJavaSerialv8_openhab_0/libNRJavaSerialv8.so
file /var/lib/openhab/tmp/libNRJavaSerialv8_openhab_0/libNRJavaSerialv8.so
/var/lib/openhab/tmp/libNRJavaSerialv8_openhab_0/libNRJavaSerialv8.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=672f09d88ecbc3880671171218dbd91a06839002, not stripped
So the files seem to be valid binaries for the platform.
Note that I also activated the mqtt binding and it works flawless. So a general setup issue does not seem to exist.
For making sure, I installed Openhabian and retested the issue. Problem is 100% reproducible:
Jan 17 16:22:00 openHABianDevice karaf[4520]: unsupported JNI version 0x00000002 required by /var/lib/openhab/tmp/libNRJavaSerialv8_HF_openhab_0/libNRJavaSerialv8_HF.so
Jan 17 16:22:00 openHABianDevice karaf[4520]: /var/lib/openhab/tmp/libNRJavaSerialv8_openhab_0/libNRJavaSerialv8.so: /var/lib/openhab/tmp/libNRJavaSerialv8_openhab_0/libNRJavaSerialv8.so: cannot open shared object file: No such file or directory
Jan 17 16:22:00 openHABianDevice karaf[4520]: unsupported JNI version 0x00000002 required by /var/lib/openhab/tmp/libNRJavaSerialv7_HF_openhab_0/libNRJavaSerialv7_HF.so
Jan 17 16:22:00 openHABianDevice karaf[4520]: /var/lib/openhab/tmp/libNRJavaSerialv7_openhab_0/libNRJavaSerialv7.so: /var/lib/openhab/tmp/libNRJavaSerialv7_openhab_0/libNRJavaSerialv7.so: cannot open shared object file: No such file or directory
As it looks to me, none of the serial port based binding are usable on Openhabian. At least, not the comfoair binding.
I do not see how this could be hardware-specific at all. I have a pi zero here (which is supported and uses the exact same armhf arch) which shows the same behavior.
Edit: actually, the page explicitly states:
Hardware and OS support
As of openHABian version 1.6 and later, all Raspberry Pi models are supported as hardware.
(I was wondering, as I explicitly checked in advance before giving a try for openhabian. )
I reproduced the issue in a unit test of NRJavaSerial (see: https://github.com/NeuronRobotics/nrjavaserial/issues/200. The owner of the lib confirmed that these errors are just misleading, but not mission critical. The problem I observe (comfoair items non-functional) must be caused by an additional problem in my OH installation.
Interesting though, that the problem occurs with the pure Raspbian installation but also with OpenHabian. (However, everything works fine, as soon as I plug in my SD card with the OH 2.5 installation which I used until today).
The issue was a trivial permission issue. I had to disable the serial console in raspi-config. Afterwards, things started to work as intended. The JNI errors discussed above are still reported, but as explained before, they are spurious.
)