David Lechner

This sounds like the expected behavior (from the point of view of BlueZ and Bleak). If manufacturer data changes, the old value is replaced.

I would suggest logging Bluetooth packets to see what is different between the working and not working cases.

According to the logs, the disconnect happened because the device failed to respond. So maybe the device is going to sleep after a while or something like that?

Please see https://bleak.readthedocs.io/en/latest/troubleshooting.html to enable debug logging and how to log Bluetooth packets. Bleak only reports the value returned by BlueZ so this is likely a BlueZ issue or an...

As seen in the second line of the logs: ```console 2024-01-05 14:22:14,983 bleak.backends.bluezdbus.manager MainThread DEBUG: received D-Bus signal: org.freedesktop.DBus.Properties.PropertiesChanged (/org/bluez/hci0/dev_00_00_00_00_00_00): ``` BlueZ thinks the device address is all 0s.

I would start with logging Bluetooth packets. If the device is actually sending the address 00:00:00:00:00:00 then there is nothing wrong with the software.

Can you run the same program with debug logging enabled? If that doesn't provide enough info you may need to log Bluetooth packets as well. https://bleak.readthedocs.io/en/latest/troubleshooting.html

It depends on what `XXXXXXXXXXXX` is. Windows blocks access to certain characteristics, like HID characteristics.

In that case, I would log Bluetooth packets to see if the error is coming from the ESP32. Maybe pairing is required?

Instructions are at https://bleak.readthedocs.io/en/latest/troubleshooting.html#windows-10