hbldh / bleak

A cross platform Bluetooth Low Energy Client for Python using asyncio
MIT License
1.61k stars 279 forks source link

backends/characteristic: make max_write_without_response_size dynamic #1586

Closed dlech closed 3 weeks ago

dlech commented 3 weeks ago

It has been observed that the max MTU exchange may not be complete before the connection is established, at least on Windows.

This reverts the previous attempt to work around this on Windows and instead makes the max_write_without_response_size dynamic. This way users can implement a workaround if needed but users who don't need it won't be punished with a longer connection time. The timeout in the previous workaround was also too short for some devices so it wan't complexly fixing the issue.

dlech commented 3 weeks ago

Hi @JPHutchins, this is a different approach to trying to fix your issue.

It is now up to the caller to opt in to the workaround by adding the following code after connection:

            async with asyncio.timeout(10):
                while char.max_write_without_response_size == 20:
                    await asyncio.sleep(0.5)

I feel like this is better because you could still do other things with the device at the same time while waiting for this. And you can make the timeout as long or short as you want.

JPHutchins commented 3 weeks ago

Great! I think that my main question is whether or not it's always OK to use MTU property on Windows and Mac? On Linux we are using the _acquire_mtu() method and it seems OK.

Should I use the MTU property or the max write without response size for reliable MTU?

dlech commented 3 weeks ago

max_write_without_response_size should be working on all OSes as long as you meet the minimum BlueZ version requirement stated in the docs. But the device-level property should be fine to use for the foreseeable future as well.

JPHutchins commented 3 weeks ago

But the device-level property should be fine to use for the foreseeable future as well.

OK! Is it correct that the device-level MTU is valid as soon as the device is "connected", whereas we may have to await the arrival of the max_write_without_response_size?

dlech commented 3 weeks ago

Is it correct that the device-level MTU is valid as soon as the device is "connected", whereas we may have to await the arrival of the max_write_without_response_size?

No, the information is coming from the same place max_write_without_response_size is just mtu_size - 3.

dlech commented 3 weeks ago

Thanks for the review!