Bluetooth Binding not supporting RuuviTags (OpenHabian 2.4.1)

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 :slight_smile:

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 :frowning: 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).

OK but the problem is that as it stands now the whole Bluez Binding is broken.

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.

Cant be reverted unfortunately, the change was part of the buildsystem migration. Someone with hardware must now need to test and fix the binding

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?