Bluetooth Binding not supporting RuuviTags (OpenHabian 2.4.1)

communig8 · May 30, 2019, 4:50pm

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

communig8 · June 1, 2019, 3:08pm

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_Graeff · June 1, 2019, 3:36pm

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

communig8 · June 1, 2019, 5:19pm

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?

David_Graeff · June 1, 2019, 7:21pm

No that’s not normal. But a buildsystem change itself is not normal and usually only happens if inevitable. Please bear with the maintainers that not everything could be tested. The migration took already 2 month and the 2.5 release is still delayed.

Please help if you can.

communig8 · June 2, 2019, 1:22pm

I’ve had a look through the code, although it’s been a good few years since I’ve worked on Java. It seems to be a combination or poor error handling and the Native libraries, libtinyb.so and libjavatinyb.so, not installing. If you could tell me where the libraries are supposed to be, I’ll try manually putting them in place and re-testing.

David_Graeff · June 2, 2019, 4:02pm

Hm. As far as I know native libraries do not work yet with the new buildsystem, at least we have problems in Allplay and other bundles. @J-N-K, that’s still correct isn’t it?

communig8 · June 2, 2019, 4:10pm

Please.

Gad_Ofir · June 2, 2019, 4:26pm

Hi did you have a look at this

J-N-K · June 2, 2019, 7:22pm

Natlive libraries are included but not properly referenced in the bundle manifest. Please open an issue for this. My plan is to get rid of all wrapped libraries in the first place and then remove all embedded libraries, this will also help with the native code.

communig8 · June 2, 2019, 9:05pm

No because I specially needed support for RuuviTags which has turned into a complete nightmare.

communig8 · June 2, 2019, 9:07pm

I assume this request (for a issue to be opened) was not directed at me but rather the guy that broke it all?

J-N-K · June 2, 2019, 9:23pm

Who ever discovers a bug should enter an issue.

communig8 · June 3, 2019, 6:06am

Bluetooth BlueZ Binding fails as Native Libraries not deployed #5680 submitted.

communig8 · June 22, 2019, 5:57am

Hi the problem loading the Tinyb libraries has now been resolved and RuuviTag support is there now. However, of the three tags I have only one is being recognised as a RuuviTag, the other two are only showing as generic Bluetooth devices.

F7:9C:78:D0:51:61 not recognised
EA:2D:46:F5:83:8E not recognised
CD:21:B7:E1:6E:DF recognised

ssalonen · June 22, 2019, 9:06am

Hi @communig8, good testing there.

The devices are detected using using manufacturer ID as reported by the devices.

Let’s try to troubleshoot what is going on:

please output bundle:list -s |grep bluetooth output from the karaf console, specify openHAB version
can you please enable verbose logging to whole org.openhab.binding.bluetooth?
check the properties of the thing, and share them here (we should see the manufacturer ID)
see if the official python library is able to discover the devices properly, python3 /usr/local/lib/python3.5/dist-packages/ruuvitag_sensor -f (installation guide: https://github.com/ttu/ruuvitag-sensor)
use e.g. core beacons iOS app to find out Manufacturer ID of the devices (expecting 0x0499 (hex) or 1177 as decimal)

communig8 · June 22, 2019, 9:39am

bundle:list -s |grep bluetooth
239 │ Active │ 80 │ 2.5.0.201906131930 │ org.openhab.binding.bluetooth
240 │ Active │ 80 │ 2.5.0.201906131930 │ org.openhab.binding.bluetooth.bluegiga
241 │ Active │ 80 │ 2.5.0.201906201458 │ org.openhab.binding.bluetooth.bluez
242 │ Active │ 80 │ 2.5.0.201906131930 │ org.openhab.binding.bluetooth.blukii
243 │ Active │ 80 │ 2.5.0.201906131930 │ org.openhab.binding.bluetooth.ruuvitag
244 │ Active │ 80 │ 1.3.3 │ org.sputnikdev.bluetooth-manager-tinyb

openHAB 2.5.0~S1611-1 (Build #1611)

Recognised Tag Things shows vendor Ruuvi Innovations Ltd (Oy)
Unrecognised Tags show no vendor information

pip install ruuvitag_sensor
worked ok but “/usr/local/lib/python3.5/dist-packages/ruuvitag_sensor” is a directory not an executable.

What logging level do you mean by “verbose”? (TRACE, DEBUG, INFO, WARN, ERROR)

ssalonen · June 22, 2019, 10:41am

Thanks

All right, so everything is bleeding edge.

This is interesting indeed. Logs should tell something hopefully.

Do all the sensors have the same firmware version? or any other difference? Are they in “raw” mode?

Thanks, did you notice the python3 before the folder:

python3 /usr/local/lib/python3.5/dist-packages/ruuvitag_sensor -f

Let’s try with TRACE to be sure we do not miss anything.

communig8 · June 22, 2019, 1:12pm

It had to be to get Bluetooth working with TinyB.

All 3 bought as a 3-pack so all the same Firmware and raw.

Obviously not

python3 /usr/local/lib/python3.5/dist-packages/ruuvitag_sensor -f
Finding RuuviTags. Stop with Ctrl+C.
Start receiving broadcasts (device hci0)
End Of File (EOF). Exception style platform.
Stop receiving broadcasts

I’ll do that and post the results

communig8 · June 22, 2019, 1:50pm

Just to make certain I get a clean start for the logging, I rebooted all three tags.
I’m now getting them recognised as RuuviTags.