3rd Party Bluetooth Binding. Beta testers needed

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: https://github.com/sputnikdev/eclipse-smarthome-bluetooth-binding/issues/17. 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.

Just want to inform about my promised tutorial on connecting remote Bluegiga Adapters. Its now online.

1 Like

Hi @orzechszek, NUT mini is OK to get nearly 100% accuracy with BlueGiga adapter even if you set the “online timeout” to 15-25s.

TinyB transport is very unstable. The online timeout should be set to around 200s in order to make it working properly, but this will introduce 200s of latency to detect when your devices go offline (out of range). This is due to a large number of middle tiers between the binding and actual adapter, e.g. Adapter -> USB -> Bluez -> DBus -> TinyB -> OH

Good news!

@xrucka has implemented a new dbus transport for generic USB adapters that does not use TinyB at all and talk to adapters directly via DBus interface! Tons of kudos to him! I was dreaming to get rid of TinyB… We will try to release the dbus binding asap.

Lukáš has also contributed quite a bit into the Gatt parser library and TinyB as well.

He is also currently working on adding support for a bluetooth thermostat: here.

1 Like

Hi @vkolotov,
Thanks for info! Unfortunately I have TinyB adapter… so I’m waiting for your BT binding upgrades :slight_smile:

Hi.
After reboot openHAB


Need reinstall Bluetooth Binding BlueGiga Transport and Bluetooth Binding

I prefer to define my things using .things files but I can’t get my Bluegiga adaptor to show in PaperUI when I define it in a .things file. (It appears fine when adding via PaperUI directly).

Does anyone have an example of defining a blootooth:adapter in a .things file?

I tried the below and a few variations on that theme:

Thing bluetooth:adapter:886B0F6xxxxx "Bluegiga01" [signalPropagationExponent=4.0] 

I just tried this for the first time, and it… worked, but I think something must have gone wrong since it didn’t seem to work reasonably. Hopefully I just did something silly and someone can steer me in the right direction. I’m just using a standard Pi 3B+ with BlueZ 5.43 etc.

Upon adding everything, it very rapidly discovered over 285 things. The older/other BT binding only finds around 20 or so if I run it, and it takes considerably longer to find most of those. After a while, the inbox cleaned itself up a bit, but remained between 25-65 items for as long as I left discovery enabled. I only know what about 5 of the devices actually are, but I don’t live in a sea of bluetooth-enabled everything so I’m not sure the hundreds of items is valid :wink:

I added my phone (Android Pixel, older model, not the 2), but it seems like the binding only reports the phone as being online as long as the phone remains in active discovery mode. Once I closed that, but left BT enabled, it went offline and never seemed to be found again. There was no option to setup pairing etc that I could find.

So I guess I am confused about how this is intended to be used. I don’t want hundreds of spam devices being processed constantly, but I can’t disable discovery if I want to use this for anything. But then I also can’t seem to use it reliably, at least for my phone, unless I keep it in permanent discovery mode, which isn’t possible (or wanted).

Hi @giblet37, please see these tickets:

These are all planned, but I can’t guarantee when it is going to be done.

Hi @vkolotov,
I’m currently playing with a couple of Bluegiga dongles connected to your binding:

216 │ Active   │  80 │ 1.2.2                  │ org.sputnikdev:org.eclipse.smarthome.binding.bluetooth.transport.bluegiga
220 │ Active   │  80 │ 1.1.5                  │ org.sputnikdev:org.eclipse.smarthome.binding.bluetooth

I’ve just discovered some odd behaviour at startup which seems to block other serial ports (a Zigbee dongle in my case). I’ve already asked the maintainer of the Zigbee binding:

But after a some more tests it looks like the bluetooth binding somehow catches/open other serial port even if not matching the adapter regex. I currently have symlinked the Bluegiga’s to something unique, so that some unintended match should have been avoided:

/etc/udev/rules.d//50-usb-serial.rules:

SUBSYSTEM=="tty",ATTRS{idVendor}=="2458",ATTRS{idProduct}=="0001", SYMLINK+="bluegiga%k", GROUP="dialout", MODE="0666"

My adapter regex is:

(/dev/bluegigattyACM[1,2])
... also tried (/dev/bluegigattyACM*) and (/dev/bluegigattyACM[1-2]) as well as some other ;-) 

If I start the Bluetooth binding before the Zigbee binding, then the Zigbee binding can not open it’s serial dongle. Therefore I need to

216 │ Active   │  80 │ 1.2.2                  │ org.sputnikdev:org.eclipse.smarthome.binding.bluetooth.transport.bluegiga
220 │ Active   │  80 │ 1.1.5                  │ org.sputnikdev:org.eclipse.smarthome.binding.bluetooth
openhab> bundle:stop 220

… then restart openHAB and after the Zigbee dongle has been opened by the other binding:

openhab> bundle:start 220

… to get both bindings working at the same time with their serial adaptors.

Is there something wrong with my Bluegiga-regex? Are you checking other serial ports than mentioned in the regex somehow?

Hi @curlyel, the binding (bluegiga transport) does not attempt to open/lock any other unmatched ports. Here is that code that filters them out.

nrjavaserial library is used to do port discovery, I’m guessing that the zigbee binding is using it as well… Maybe they somehow get confused (what could possibly go wrong?!).

What happens if you start zigbee binding first, does bt binding find any serial ports?

Your regex look ok. I’ve got several unittests covering port matching, so it must be something with that nrjavaserial library… I’ll have a look soon.

Hi Vlad, thanks for looking into it.

Yes, this works as it should. When I start the Zigbee binding, let it open it’s serial port and initialize the Zigbee coordinator dongle and the start the Bluetooth binding both are working and can talk to their serial ports.

EDIT:
@chris:

Can you confirm it is the case? If so, do you have some thoughts what may go wrong with the serial port discovery?

What does this mean? It’s not my understanding of the port discovery. I thought that the discovery only looked at the system info to check the PIDs - it shouldn’t involve the serial port library (or so I thought). I’m not overly familiar with the discovery though, so I could be wrong.

Hi Vlad.
After installing 2 new BlueGiga Adapters i get this Warning every 10 Minutes:

2018-07-11 16:36:16.369 [WARN ] [tooth.bluegiga.BlueGigaSerialHandler] - Ignoring BlueGigaPassKeyResponse response which has not been requested.
2018-07-11 16:36:26.265 [WARN ] [r.transport.bluegiga.BluegigaHandler] - Timeout has happened while sending a transaction, retry one more time: BlueGigaHelloCommand

and this

2018-07-11 16:44:26.714 [WARN ] [er.transport.bluegiga.BluegigaDevice] - Unexpected exception occurred while handling bluegiga event: bluegiga://88:6B:0F:A2:BA:8A/3F:BF:1F:27:6D:2B : BlueGigaScanResponseEvent [rssi=-71, packetType=NON_CONNECTABLE_ADVERTISEMENT, sender=3F:BF:1F:27:6D:2B, addressType=GAP_ADDRESS_TYPE_RANDOM, bond=255, data=FF 06 00 01 09 20 02 54 E3 32 F9 DF FC EA E0 A8 FF 0E 1C 00 CE B1 E5 F9 ED 3D 71 50 51 7C] : 255

sender is a not installed device. Only seen it in Inbox.

Is there a problem or it’s okay.
Greetings,
Markus

Hi @chris, there is nothing special in the port discovery. The binding calls NRSerialPort.getAvailableSerialPorts() (which returns a set of available port names, e.g. a set of strings) and then filters by using a regex that is user defined (in the binding config). That’s it. The binding does not attempt to open any unmatched ports. So not sure what’s happening there.

Hi @Master79,

thanks for reporting this. Those errors can be ignored. The blugiga protocol does not have any error correction so we have to look after some anomalies and try to recover from serial communication errors.

BTW, that bluegiga library we use in the binding (bluegiga transport) here is written by @chris, all kudos to him! Excellent work.

Hi Vlad.
I have changed my adapters to extern bluegiga adapters. What i have seen, is that the refresh rate of the RSSI is much faster. So every 5 seconds i get a new value. The CPU rate is higher too. :slight_smile: 1-2%.
But the value jumps. For example from, -82 to -74 without move of the device. How can i set the devices or adapter that the value is not jumping so much?

2018-07-16 18:05:01.194 [vent.ItemStateChangedEvent] - GearS3_RSSI changed from -73 to -80
2018-07-16 18:05:06.214 [vent.ItemStateChangedEvent] - GearS3_RSSI changed from -80 to -82
2018-07-16 18:05:11.231 [vent.ItemStateChangedEvent] - GearS3_RSSI changed from -82 to -74

Greetings,
Markus