bleak: DBus backend high CPU usage and it grows over time

https://github.com/igo95862/python-sdbus/ looks interesting as well.

Thanks for all of the logs. I have a new theory about what is going on. BlueZ caches information on each device that it sees where a device is identified by its Bluetooth address. However, many Bluetooth Low Energy devices use random addresses that change frequently. So a huge cache of devices builds up in BlueZ, even if there is only one physical device.

Each time we start and stop scanning or connect to a client, we create an new D-Bus connection and call org.freedesktop.DBus.ObjectManager.GetManagedObjects. In your 2nd log (the one with lower CPU usage), the response to this is 1158 lines long. Compared to the 1st log where the response is 53170 lines long, it is easy to see why it would be using significantly more CPU (it is processing >45x the amount of data).

So, I think the solution will be to maintain a single D-Bus bus connection for monitoring D-Bus objects for the lifetime of a Bleak program. However, BleakClient will still need to have it’s own bus connection for calling the Connect method to avoid https://github.com/hbldh/bleak/issues/472#issuecomment-796330894.

I think it would also be worthwhile raising an issue with BlueZ to see if there is a way for it to not cache devices with random addresses.

What happens if you rewrite the loop like this?

async def start():
    async with BleakScanner(scanning_mode="passive") as scanner:
        scanner.register_detection_callback(
            device_detection_callback,
        )
        while True:
            await aio.sleep(3)
            await scanner.stop()
            print("New devices: ", scanner.discovered_devices)
            await aio.sleep(1)
            await scanner.start()