Closed dlech closed 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.
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?
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.
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
?
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
.
Thanks for the review!
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.