Still maintained?

[psychonetic]

Hi,

I just wanted to know if this library is still maintained. Because there are a lot of open pull requests and also the latest commit was almost two years ago.

[CLDiego]

Hi @psychonetic, I'm afraid that it is pretty much an abandoned project. I learned about BLE using bluepy last year and while it offers great functionalities and documentation, it's been hard to make it work with every Bluez update.

I switched fully to pygatt, it not as well documented as bluepy but at least is more stable.

Good luck!

[rzr]

May this project a candidate for @abandonware transfer ?

[IanHarvey]

I would really appreciate having some co-workers on this project.

There are, it seems, a lot of people currently using bluepy and above all I don't want to make new releases which break currently working code. So while it's tempting to just hit merge on all the PRs, it needs a lot of code review and testing. (In particular, people installing this from PyPI deserve complete stability).

The second, more structural, problem is that almost all of the work is done by BlueZ code. (There isn't really a BlueZ user-mode API, just a big pile of C code for various utilies / daemons, talking directly to the kernel's sockets interface(s); I've adapted BlueZ's gatttool sources into bluepy-helper and put a Python wrapper around it). We've ended up with a lot of bugs which are somewhere in this C code, but often require a very specific setup (platform, BLE adapters, peripherals) to reproduce. Debugging these is not an appealing prospect.

Ideally, I'd get rid of BlueZ altogether, and have a pure Python implementation of the whole stack down to the kernel sockets. There's a POC of this in the bluepy.device repository (for a BLE peripheral, not a 'central'). This needs a lot of time, and more BLE hardware than the handful of SensorTags and a Thingy52 which I've got here.

I'm happy to add suitably qualified collaborators to the project.

[gandy92]

Hi Ian, good to hear from you!

I'm using bluepy in a project for my home-automation system where several raspberry pies collect passive advertising frames with sensor data and report them back to a central where the frames are correlated and further processed. The project is based on twisted, which is why I've written an asynchronous version of btle.py that also makes use of bluepy-helper. This is working mostly flawlessly on several raspberry pies in 24/7 operation for more than two years now.

Actually, one of the reasons I chose bluepy for my project is that it does not require python to run with special privileges. Aside from bluepy I've tested pure-python implementations, all of which suffered from the lack of being able to run with reduced privileges. I would much appreciate bluepy keeping this (to my knowledge) unique feature. This obviously would require bluepy-helper to work reliably.

I have only limited time to offer, but if it helps, I could take a look at one or the other pull request. As for qualification, I did some quite extensive digging into bluepy, especially bluepy-helper, and anything involved to get the passive scanning code working, that I've contributed with PR #214 - If you feel that is enough, please let me know.

[DenisBY]

Could you apply patch from here: https://github.com/IanHarvey/bluepy/issues/239#issuecomment-549021485?

[attermann]

@IanHarvey Have you considered creating a stable branch, call it "1.0" for example, and noting in your README that this is the "stable" version for those who are more interested in stability over new features? Then you wouldn't need to be so concerned about what you merge into master. IMO it would be a shame to see this project fade into obsolescence, especially with so many willing to help. Just my 2 cents.