search

Jakeler / ble-serial

"RFCOMM for BLE" a UART over Bluetooth low energy (4+) bridge for Linux, Mac and Windows
https://blog.ja-ke.tech/tags/#bluetooth
MIT License
263 stars 37 forks source link

Investigate alternative BLE python backends #5

Closed AGlass0fMilk closed 3 years ago

AGlass0fMilk commented 4 years ago

The underlying library behind this project is currently bluepy and has many apparent flaws.

The notification method used in this project is currently deprecated by the API documentation with no alternative suggested. The ability to perform pairing/bonding is dubious. Overall the library does not provide clear and documented ways of performing common interactions with modern BLE devices. Since the main repo has not been updated in 2 years, it is uncertain if any modern Bluetooth features will be implemented.

Possible alternatives:

Jakeler commented 4 years ago

Thanks for looking into alternatives @AGlass0fMilk! On the bluezero wiki is also a list of libraries, it includes the technology, which is interesting.

bluepy is a mix of C and Python, the 2 parts communicate through some internal protocol. Main problems are the open bugs related to threading, that cause crashes. Because no PRs get merged, manual installation of a fork is required... According to the docs waitForNotifications is not deprecated though?

Proceeding to the alternatives, I would first disqualify pygatt, because it calls gatttool, simulates the interactive input and parses the output. This is not solid way to implement a backend, now that it is deprecated makes it even worse. I have actually already used it a while ago and it needed patching to get the full notification data out.

pygattlib is pure C, it just includes python headers to allow usage from python scripts. Looking closer at the history shows after 2016 only 5 commits, in addition many open issues/PRs. In this regard unfortunately similar to bluepy...

bleak and bluezero are both pure Python and use DBus. This is the recommended API from BlueZ and used by the current official tools. Both are relatively new projects, with bluezero being even more in a early stage. Dependency wise bluezero is pretty clean, only needs aioblescan for scanning. bleak not so much, it depends on txdbus, which in turn depends on twisted (large network lib) + zope.interface, constantly, incremental, Automat, hyperlink, PyHamcrest. Seems a bit unnecessary, because Pythons standard lib includes DBus support. But bleak is a bit more active... Probably have to try both.

Notable are in addition gatt-python and bluew, not really popular and not active, but with simple code and zero dependencies.

AGlass0fMilk commented 3 years ago

I am thinking we should seriously look into bleak, it is quite active and claims cross-platform support on Linux/Windows/Mac.

Jakeler commented 3 years ago

I am thinking we should seriously look into bleak, it is quite active and claims cross-platform support on Linux/Windows/Mac.

Agreed, it is indeed still active + gaining more traction and the cross platform support is nice to have. I have now tried their uart example and it already works well. Also they recently switched from txdbus to dbus-next, which has no other dependencies, so that is pretty nice.

I will now try to put it into ble-serial, it needs a few changes because of asyncio, but otherwise it should be quite straightforward.