Closed AGlass0fMilk closed 3 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.
I am thinking we should seriously look into bleak, it is quite active and claims cross-platform support on Linux/Windows/Mac.
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.
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: