3rd Party Bluetooth Binding. Beta testers needed

Have a look at “minew keyfinder”, so far it is the best beacon that I tested. It also supports multiple button events, e.g. single click, double click etc. Please note that their android app is not very good, but device itself is good.

Hi to all.
After changing to openhab 2.3.0 i have this error and warnings by starting the service:

2018-05-31 06:36:07.522 [ERROR] [binding.bluetooth.transport.bluegiga] - FrameworkEvent ERROR - org.sputnikdev.org.eclipse.smarthome.binding.bluetooth.transport.bluegiga

org.osgi.framework.BundleException: Could not resolve module: org.sputnikdev.org.eclipse.smarthome.binding.bluetooth.transport.bluegiga [200]

  Unresolved requirement: Import-Package: gnu.io

	at org.eclipse.osgi.container.Module.start(Module.java:444) [?:?]

	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1634) [?:?]

	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1614) [?:?]

	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1585) [?:?]

	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1528) [?:?]

	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1) [?:?]

	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) [?:?]

	at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340) [?:?]

2018-05-31 06:36:08.638 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler BluetoothDeviceHandler of thing bluetooth:ble:D43F78F48F71 tried checking if channel online is linked although the handler was already disposed.

After this, i think all functions i use runs normaly.
Any idea?
Thanks,
Markus

First searching before writing! :slight_smile: Found it a couple of days before. Thanks to dibbler42.
The command line solved the problem.
But why is this problem in the Version 2.3.0 and not in the 2.2.0?
And the warning already exists:

2018-05-31 06:50:32.967 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler BluetoothDeviceHandler of thing bluetooth:ble:1C232C011E22 tried checking if channel online is linked although the handler was already disposed.

For all Bluetooth items by starting service.
Thanks,
Markus

Hi @Master79, do you use a bluegiga adapter at all? If not, you could uninstall BlugigaTransport, this error will go away. If you use BlueGiga adapter, then run this:

feature:install openhab-transport-serial

Thanks to @Dibbler42^^

1 Like

Thanks for reporting, please ignore that error for now, it is not critical.

1 Like

how can i stop or reduse the adapter spaming my inbox with all those devices i dont need?I tried to ignore them but they keep coming with changed mac.Tried to turn of discovery on the adapter but then iam losing my added devices also.Any advice?

Hi @Constantinos_Contis, do you live on a busy street or something? How bad it is, is it overfooding your inbox? How many devices? The binding should remove stale devices (that are no longer in range).

i am talking about 20 to 40 devices in my inbox and because of them i get a lot of flow at my log files by descovering and removing them making my setup slow.

Hi vlad.
Have seen that the refresh time is standard set to 10 seconds. On the pi i can’t change it, or better the refresh time doesn’t change. On my Intel nuc with Ubuntu i can change it to 5 seconds and it works.
For my presence detection it’s a lot faster with 5 seconds. Any ideas how to change it on the pi?
Greetings,
Markus

Hi @Constantinos_Contis, I can see your problem, I’ve added a ticket to fix that: https://github.com/sputnikdev/eclipse-smarthome-bluetooth-binding/issues/53

1 Like

Hi Master79, making it very low will overload your system. I really do not recommend to set it to something less than 10s. Furthermore, the update rate setting won’t change much. This will change only performance of detection when devices get lost. In other words, the update rate does not affect performance of how fast new devices get discovered (or existing devices re-discoverd).

It might that your nut is just more performant than PI.

Okay i understand.
But i don’t speak about the RSS refresh time. I thought that this option would make my System or cpu slow. Not the normal item refresh. And the RSS has a standard time of 5 seconds?
What is the best setting for presence control?
Greetings,
Markus

Hi @Master79,

RSSI refresh rate does not affect presence detection at all, this is just to “unload” OH by skipping some RSSI readings, all RSSI readings internally are respected.

What I recommend is to build a chart for your beacon devices would show you how the binding performs, e.g. something like that:

And then tweak the “bluetooth devices update rate” so that your graph looks smoother (e.g. no false-positive drops).

On that screenshot:

  • First one: stationary beacon (just for testing, very stable)
  • Second: a beacon that is attached to my keys (very stable)
  • Third: stationary beacon that needs some tweaking

Hi @vkolotov,
Finally, I’ve found some time playing with the bluetooth binding this weekend :wink:
All devices/sensors I’ve tried worked right out of the box. Excellent job, thanks for this great binding :clap::clap::clap:

I’ve tried and can confirm working as expected:

  • Flower mate (had to do the firmware update to 3.1.8 since 2.6.2 and 2.7 haven’t worked)
  • Mija bluetooth thermometer
  • itag (with connection control)
  • iBKS beacon

Two questions though:

  1. Could you recommend some usb bluetooth dongle with a good RX sensitivity? I have one with quite poor reception (China CSR4.0) and a mini-PCIe with excellent sensitivity (Intel AC7260). Unfortunately, mini-PCIe won’t work in my “production-setup”.
  2. How to increase logging level for the binding? Well, it was not required to get things working. But I tried in the Karaf console to increase the logging just for a test and did not got more logging :wink:

Thanks a lot,
Curlyel

Hi @curlyel, thanks for testing it.

I cannot really recommend any particular USB dongles unfortunately. I was going to do some research, but still could not find time to do so. However, I do notice that BlueGiga dongles perform better. Furthermore with the most recent release/fixes, Bluegiga transport works much more stable comparing to TinyB (regular usb). This is due to that we have a lot more control over bluegiga dongles and also there are much less middle tiers between hardware and the binding (e.g. no TinyB, Bluez, DBus etc).

You can turn on debug log levels for the Java Bluetooth Manager which is used by the binding:

log:set DEBUG org.sputnikdev.bluetooth.manager.impl
log:set DEBUG org.sputnikdev.bluetooth.manager.transport.bluegiga
log:set DEBUG org.sputnikdev.bluetooth.manager.transport.tinyb

Be careful, it is very chatty.

Super basic noob question:

To use this binding for indoor positioning, it is recommended that I have multiple Bluetooth dongles, preferably in each room. This makes sense, but what I don’t understand is how these multiple dongles will communicate back to the OH server.
My OH server is running Windows so I think I need to buy some Bluegiga BLED112 dongles so I plug one of them into the USB port of my OH server, what do I do with the rest of them? :confused:

Could someone explain this to me like I’m 5 and maybe I’ll understand and (hopefully) buy the right kit to get it all working! :slight_smile:
Thanks!

Hi @mcqwerty,

You have several options:

  • Use extending cables (passive 5m max, active 25m max)
  • Use some “usb over ip” solutions
  • Use some “serial port over ip” solutions (for BlueGiga only)

Be aware that BluGiga dongles do not discover devices that are of older Bluetooth version (<4.0). This means that some old phones won’t be seen by BlueGiga adapters. Also be aware of that issue: Implement a workaround for mobile phones (recent models of iphone and android) that dynamically allocate MAC addresses · Issue #17 · sputnikdev/eclipse-smarthome-bluetooth-binding · GitHub. I’m working on it to implement a workaround.

However, I do recommend to use BlueGiga adapters as they more stable/accurate comparing to generic usb adapters.

@vkolotov Thank you for taking the time to help me understand and for your work on what looks to be a really exciting binding.

For my situation, it looks like USB over IP is the best option, but the adaptors are quite expensive. Is it possible to use a Raspberry Pi to bridge the Bluetooth adaptor to the network and back to the OH server? Or maybe an even more low cost solution like an ESP32 with built in Bluetooth? I see some mention of this through google searches but wondered if there were any confirmed reports of this working with your binding and the setup used?

In addition to the indoor positioning, I am interested in the Xiaomi devices, Kettle, Mi Scale 2, Mi Flora, etc. I see some talk about these devices in this thread but it is difficult to know:

  1. If each is compatible with the BlueGiga
  2. The extent of the current support

Is there a quick reference somewhere to check these details for a given device?

Thanks!

Hi, @vkolotov

Which beacons are you using and what is configuration that is so stable?
I’m using NUT mini and from time to time it refreshes status even it’s near by adapter.

I confirm that this works for a Windows install too.