reconnecting to a rebooted device

[karlp]

Hi,

I've been struggling with this, and trying a few workarounds, but I feel this might be something that is hopefully user error...

I'm trying to implement OTA flashing for silabs efr32 devices, which basically involves writing to a characteristic to trigger a reboot into a bootloader, and eventually, writing to the same charactistic uuid to reboot back into the application. The handles change, and the device disconnects and must be reconnected to.

I've tried making a new client for the second stage (as suggested in #121) , and I've tried using a single client, and calling .connect(), but it never works reliably. I've tried the workaround from #713 (comment) and have used workarounds to select the correct handle, instead of using the UUID, but it never reliably reboots both times. I can normally connect, request the first reboot, and then connect again, but the request to write to the characteristic after reboot invariably fails.

I've got demo code and logs available at https://github.com/karlp/bleak-demo-ota The demo code attempts to use a single client object.

I've tried the approaches in #549 and read far too many bug reports and discussions to link them all relevantly.

Any advice greatly appreciated.

[dlech]

The device itself must implement the GATT Database Hash characteristic or the Service Changed characteristic in order for BlueZ to correctly re-enumerate the device. There is some discussion of this at bluez/bluez#191.

Also, Bleak does not handle service change events, so you need to create a new BleakClient instance each time you connect to get the new attribute layout.

[karlp]

Ok, SiLabs says that they don't provide the service changed indication in their bootloader, so that's already a problem. I have the database hash characteristic in my own app, but testing with NRF Connect (where I can happily reboot and reconnect between the two endlessly) I see that the SiLabs bootloader doesn't provide the Gatt database hash characteristic. (Hashing is part of BT 5.1 anyway isn't it? is there no way of doing this before then?)

I can try using a new client for each stage again, but will that help if I don't have the DB hash in one of them? Service changed notifications only seems to apply if you've "bonded" with the device and it's not supported by the bootloader anyway...

[dlech]

If you have a new enough BlueZ that has the bugs fixed from the issue I linked, then you could possibly turn off caching in the BlueZ config as mentioned in that issue.

Another option could be to use a different Bluetooth address from the bootloader so that the regular boot mode appears as a completely different Bluetooth device.

[karlp]

I got this "working" in the end by editing /etc/bluetooth/main.conf and setting Cache=yes instead of the default Cache=always

With the default, even though I have a new client, somehow the BleakGATTServiceCollection remains the same, or, more correctly I guess, is refilled by the cached values from blueZ, giving me the errors like so

2022-05-05 13:07:45,853 [ERROR] bleak.backends.service The service '1' is already present in this BleakGATTServiceCollection!
2022-05-05 13:07:45,855 [ERROR] bleak.backends.service The characteristic '2' is already present in this BleakGATTServiceCollection!
2022-05-05 13:07:45,855 [ERROR] bleak.backends.service The descriptor '4' is already present in this BleakGATTServiceCollection!
2022-05-05 13:07:45,860 [ERROR] bleak.backends.service The characteristic '15' is already present in this BleakGATTServiceCollection!
2022-05-05 13:07:45,860 [ERROR] bleak.backends.service The characteristic '17' is already present in this BleakGATTServiceCollection!
2022-05-05 13:07:45,861 [ERROR] bleak.backends.service The characteristic '19' is already present in this BleakGATTServiceCollection!

I would like to believe that this is "fixable" though, so I tried using what bluezero does, where they "remove" devices to keep getting beacons, see: https://github.com/ukBaz/python-bluezero/blob/main/bluezero/observer.py#L64 and https://github.com/ukBaz/python-bluezero/blob/main/bluezero/adapter.py#L260

I tried adding this into the bluezdbus/client.py: _cleanup_all(), but it didn't work. I suspect I'm just "doing it wrong" though, it certainly seems like removing the device like this should absolutely get rid of it's cached services/characteristics.

        self._bus.send(
            Message(
                destination=defs.BLUEZ_SERVICE,
                path=f"/org/bluez/{self._adapter}",
                interface=defs.ADAPTER_INTERFACE,
                member="RemoveDevice",
                signature="o",
                body=[self._device_path]
            )
        )

I can work with just changing my bluetooth/main.conf, but this feels very close to being able to work out of the box, so I'm sharing this in the hopes that someone else who knows this stuff more can push this further, if I'm on the right track.

[karlp]

I never pair with these devices, so it's fine to leave it at Cache=yes, from the docs, and from testing. Cache=always is the problem, as it caches from any device, even unpaired.

I'm using bluez 5.64, which is the latest release version, and the commits you reference above are from over a year ago, so I certainly believe I have those fixes, but I don't see anywhere in bleak that we actually use that remove device call? Certainly where I added it seems to have no affect at least?

[dlech]

Thanks for the clarifications. Do you create a new BleakClient object each time you connect?

[karlp]

I do, I've committed the final functional version here, hopefully it may be of use: https://github.com/etactica/host_utilities/tree/feature/bluetooth_ota_python_bleak/bluetooth_ota_apploader_python_bleak

[karlp]

It feels kinda gross to mark my own reply as the "answer" as I would never have gotten here without your replies, but what's the best way of closing this?

[dlech]

It feels kinda gross to mark my own reply as the "answer"

There is no shame in doing this 😄