Connection handling enhancements about bleak HOT 3 CLOSED

There are no plans, no. It is a good idea though and I do not think it is very hard to do, at least not in the BlueZ backend.

The auto-reconnection is somewhat breaking the idea of BLE, is it not? If the connection is not used, better to let it die and let the peripheral save energy until it is actually needed and let the client reconnect then?

from bleak.

I could provide a PR for the API and a BlueZ implementation, but I have no idea about .NET or the Darwin backend...

Out of experience there are multiple reasons why a BLE connection might drop, especially if the connection intervals are not properly set up. Typical cases are interferences and reflections in crowded environments and getting out of range. We always try to have a very resilient auto-reconnection on the peripheral side since you typically want to have long-lived connections where you can react to events from the peripheral in real time. But this is of course very use-case specific.

Anyways, this logic can be definitely pushed to the application if we have a proper disconnect callback.

from bleak.

This is implemented and merged into version 0.5.0 which has now been deployed to PyPI.

from bleak.