Hi, the docs for the Bluetooth Binding say that RuuviTags are supported but once the Binding is installed they are not listed in the supported devices and when it picks they up on discovery they are just shown a generic Bluetooth devices only showing an RSSI channel.
Anyone else had this issue?
It looks like the OpenHabian latest system image takes you to the GitHub 1.4.1 download page (https://github.com/openhab/openhabian/releases/tag/v1.4.1) but the system image here is 2.4.0.
Can anyone confirm this?
Also, is there a 2.4.1 OpenHabian system image anywhere?
Ah right the 1.4.1 system image upgrades itself first time to the latest release.
So why have I got 2.4.0 on the Pi and not 2.4.1?
Donāt confuse openHABian with openHAB. They are not the same thing and they therefore have different version numbers.
The latest release of openHABian is 1.4.1. The latest release of openHAB is 2.4.
Hi, I am author of the ruuvi extension.
The ruuvi support is not part of 2.4 version, since it was developed after the release.
Furthermore, bluez bluetooth extension needed some improvements to support discovery of ruuvitag. Therefore you need to have recent enough 2.5 pre release version of bluez bundle as well.
Easiest way to go forward might be to go for 2.5 openhab prerelease/milestone release, you would like to have something after March 17 when the hinding was merged to main code base.
Hi thanks, it certainly is a bit confusing 
Hi, Thanks very much for the explanation.
I guess that the latest Milestone 2.5.0~M1-1 available isnāt recent enough.
Hi where can I get a version that supports the RuuviTags? Thanks.
You need to use snapshot version of openhab. Download page should have the links.
Please note that it might not be very stableā¦See e.g. Snapshots 1593, 1596 and 1597 are useless (for me). Does anyone really care about Windows compatibility?
Alternatively perhaps wait for the next release, I expect it soonish
Hi and thanks for that. Iāve upgraded to snapshot 1601. The Binding installs ok but when I add the " Bluetooth BlueZ Adapter" Thing and configure with the Bluetooth MAC from hciconfig I get āStatus: UNINITIALIZED - HANDLER_INITIALIZING_ERROR BlueZ JNI connection cannot be established.ā
In the logā¦
2019-05-26 16:15:17.415 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method āThingHandler.initialize()ā on āorg.openhab.binding.bluetooth.bluez.handler.BlueZBridgeHandler@9cd613ā: BlueZ JNI connection cannot be established.
java.lang.IllegalStateException: BlueZ JNI connection cannot be established.
at org.openhab.binding.bluetooth.bluez.handler.BlueZBridgeHandler.initialize(BlueZBridgeHandler.java:94) ~[?:?]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [133:org.openhab.core:2.5.0.201905250301]
at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [133:org.openhab.core:2.5.0.201905250301]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
Caused by: java.lang.UnsatisfiedLinkError: tinyb.BluetoothManager.getNativeAPIVersion()Ljava/lang/String;
at tinyb.BluetoothManager.getNativeAPIVersion(Native Method) ~[?:?]
at tinyb.BluetoothManager.getBluetoothManager(BluetoothManager.java:304) ~[?:?]
at org.openhab.binding.bluetooth.bluez.handler.BlueZBridgeHandler.initialize(BlueZBridgeHandler.java:92) ~[?:?]
... 10 more
Any ideas?
Sorry, no ideas 
Have you installed bluez system library etc.? Perhaps this points to right direction.
Also, docs say that
Also note that the OS user needs to be a member of the ābluetoothā group of Linux in order to have the rights to access the BlueZ stack.
Make sure you have bluez version below 5.48. As docs say
Please note that at least BlueZ 5.43 is required, while 5.48 or above are not (yet) supported either.
All I did was upgrade from Milestone 2.5.0~M1-1 which was working as far as the āBluetooth BlueZ Adapterā getting going and it picking up the RuuviTags as generic Bluetooth devices was concerned. So I assumed that everything thing Bluetooth-wise was ok. BlueZ 5.43 is installed and the correct group membership was already on place.
Looks like this is the problemā¦
tinyb has changed from 0.5.1 (in 2.5.0~M1-1) to 1.3.3 (in Snapshot 1601) included in the Binding install.
It looks like itās not just a release change but a completely different library. The original 0.5.1 is a Intel library https://github.com/intel-iot-devkit/tinyb and the new is a Sputnikdev library https://github.com/sputnikdev/bluetooth-manager-tinyb. The new library does not have a āgetNativeAPIVersion()ā function. OR I may be going mad having spent too long reading code and GitHub.
Still doubting my sanity but it looks like the tinyb change was https://github.com/openhab/openhab2-addons/pull/5435 and that you are on the reviewers list for this change.
Might be. Have not reviewed that. I am on quite many PR as reviewer since I have contributed some code.
@David_Graeff see aboveā¦ Do you think there might be some accidental change?
I donāt own the equipment, I just ported the binding. If I recall correctly the reason for the library switch was that Intel does not provide a maven published version and that other library is maintained.
Hi, Iām just wondering what the plan is to get this sorted out now. Will you be moving back to the old tinyb or getting the Binding to correctly use the new tinyb?
Itās quite an effort to make the intel tinyb available to our buildsystem.
I really donāt have the hardware to test that, so I canāt do anything unfortunately.
As I understood it, this other library is a drop in replacement. And the compiler should actually error out if a method is not available at build time (āgetNativeAPIVersionā). Maybe this is just related to our new buildsystem in general and not so much the dependency change? (Many addons did not work after the change at runtime).