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 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) [?:?]
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
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.
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.
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).
So what has happened is that a change has been made with no way to test the effects (no Bluetooth hardware available). So logically the way forward is to back out the change and re-test it when changes have been made to the calling code and hardware is available. I am happy to test for you.
David, is this the normal way that changes are managed in the OpenHab community? It seems a major and irreversible change has been introduced without any possibility of testing or rollback?