[Q] BlueGiga support?

[curlyel]

I've just noticed your bt-mqtt-gateway project while searching for an alternative to the (likely abandoned) third-party-openhab-bluetooth-binding, see: https://community.openhab.org/t/3rd-party-bluetooth-binding-beta-testers-needed/38492/1060

According to the recommendation of the developer of the above binding, I decided in the past to buy BlueGiga dongles which can be easily distributed via network by ser2net to cover a wider physical area.

Now that I have quite a bunch of BlueGiga's laying around without use :-( I'd love to bring them back into operation.

Maybe I missed something in your wiki, therefore I'd like to ask

Are BlueGiga dongles yet supported within bt-mqtt-gateway?

If this is not the case, is it possible to adopt and support the BlueGiga too? Due to the serial access to the bgapi (BlueGiga bluetooth smart software stack) of the dongles it's quite easy to include BlueGiga dongles on remote devices as written above.

[zewelor]

Aren't they visible in OS like any other bluetooth adapters ? If not then I guess it could be hard to add it. Different workers uses different bluetooth libs for low level access, so it could be some more work. Best would be to test them.

[curlyel]

Thanks @zewelor for your quick reply!

visible in OS like any other bluetooth adapters

Unfortunately, this seems not to be the case. The BlueGiga have the complete Bluetooth software stack in their firmware and present access to it via a serial interface. This makes it that convenient and secure accessing them by read/write on the serial port(s) using the BGAPI api. You simply don't depend on the Bluetooth software stack of your OS where your software/gateway runs on.

Your Python gateway may run on every system where Python is running ( and which is capable of dealing with serial ports ;-) of course).

@vkolotov (the developer of the bluetooth-manager as well as of the binding mentioned above ) preferred the BlueGiga for exactly this reason (OS independent and "more control over the dongle").

That's why he implemented two different "transports" in his bluetooth-manager, see his design (top box is the TinyB transport, bottom is the BlueGigatransport):

https://github.com/sputnikdev/bluetooth-manager#transport-api

By doing so, he managed to get his bluetooth-manager working even on Windows and MacOS and - as said already - it's easy to connect multiple Bluetooth dongles over a wider physical area.

He's developing in Java, so his code would not help here :-(

But: There are some BGAPI-python libs yet available. E.g. pygatt is using the lib from Jeff Rowberg: https://github.com/jrowberg/bglib/blob/master/Python3/bglib.py

Example: https://github.com/jrowberg/bglib/blob/master/Python3/Examples/bled112_scanner.py

Since I'm not a Python developer, I can't judge how much of hassle it would be to add some interface to the BGAPI to the bt-mqtt-gateway. But it would extend the use to other operating systems and add the option for "remote Bluetooth dongles" ;-)

[zewelor]

Almost every worker uses https://github.com/IanHarvey/bluepy for bluetooth connection. Best bet would be to implement it there, and to give higher level libs unified interface.

[curlyel]

Understood. Thanks for pointing this out ;-) I started searching, if (or how) bluepyis interfacing with BlueGiga's. So I stumbled over btlewrap:

btlewrap Bluetooth LowEnergy wrapper for different python backends. This gives you a nice API so that you can use different Bluetooth implementations on different platforms.

... and supporting these backends:

As there is unfortunately no universally working Bluetooth Low Energy library for Python, the project currently offers support for three Bluetooth implementations:

bluepy library (recommended library) bluez tools (via a wrapper around gatttool) pygatt for Bluegiga BLED112-based devices

Surprisingly, in your source code of (at least) the Miflora and MiTemperature worker I found references to btlewrap too:

class MifloraWorker(BaseWorker):
    def _setup(self):
        from miflora.miflora_poller import MiFloraPoller
        from btlewrap.bluepy import BluepyBackend

Does this mean, that you are using btlewrap-api instead of the "native" bluepy api to access the actual Bluetooth hardware? So, are you already using the btlewrap abstraction of (the three possible) backend api's?

If this is the case, how can I modify the setup to use the pygattbackend to get the BlueGiga's adopted?

[zewelor]

If that workers are using btlewrap, that looks it should be possible to swap backends. For test you can probably change bluepy imports to something like:

from btlewrap.pygatt import PygattBackend

Some problem is that not all workers are using same setup. Each worker can use different bluetooth api. Now I don't think its easy doable to make some global change, probably each lib, should be changed to use btlewrap, for easy switchable backends ?

[curlyel]

change bluepy imports to something like:

from btlewrap.pygatt import PygattBackend

Yes. That's what I was hoping to hear ;-) Thanks. I'm going to try this out when I'm back home...

probably each lib, should be changed to use btlewrap, for easy switchable backends ?

Exactly - sounds reasonable!

For me personally, MiFlora and MiTemperature is what I'm after beside some generic BLE beacons (Eddystone+iBeacon). So if switching the backend of the two workers will work, this will serve my needs mostly 👍

Off-topic: Which worker can be used to report some generic BLE beacons (major/minor UID, RSSI, Eddystone URL, battery level)

[zewelor]

I think this: https://github.com/zewelor/bt-mqtt-gateway/blob/master/workers/blescanmulti.py but never used it :D