Replies: 4 comments 1 reply
-
|
This question can only be answered definitively by Microsoft. The Windows Bluetooth stack doesn't have explicit connect/disconnect APIs, only the concept of a GATT session. So we can only say that we don't need the device anymore but it is entirely up to the Windows Bluetooth stack to decide when to connect and disconnect. So either there is another application running that is interested in this device or the operating system itself thinks it needs to connect again. I did notice one odd thing in the Bluetooth logs, lines 469 and 471 seem to repeat the same request twice without waiting for a response to the first one. So this makes me suspect buggy code in Windows or the Bluetooth driver. |
Beta Was this translation helpful? Give feedback.
-
|
Anything that Bleak can do upon exit to clean any 'session' it leaves
behind. I tried to call client.disconnect() from a atexit handler (using
the same event loop the client used so far) but that didn't work, still
investigating.
BTW, the session is closed after 30 seconds. I am not sure if it's the
device or Windows that closes it, and how to shorten it to let's say 10
secs.
…On Fri, Apr 7, 2023 at 8:27 AM David Lechner ***@***.***> wrote:
This question can only be answered definitively by Microsoft. The Windows
Bluetooth stack doesn't have explicit connect/disconnect APIs, only the
concept of a GATT session. So we can only say that we don't need the device
anymore but it is entirely up to the Windows Bluetooth stack to decide when
to connect and disconnect. So either there is another application running
that is interested in this device or the operating system itself thinks it
needs to connect again.
I did notice one odd thing in the Bluetooth logs, lines 469 and 471 seem
to repeat the same request twice without waiting for a response to the
first one. So this makes me suspect buggy code in Windows or the Bluetooth
driver.
—
Reply to this email directly, view it on GitHub
<#1276 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAQVMQJ6BUPSLODV4O2SRQ3XAAW6NANCNFSM6AAAAAAWWERCWI>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
If the device doesn't disconnect when the Python process ends, there is nothing Bleak can do. Calling async code from atexit won't do anything since it can't await and starting a new event loop will break things. Use a context manager or try/finally in your test coroutine to ensure that disconnect is awaited. |
Beta Was this translation helpful? Give feedback.
-
|
In my app I don't have control over main, just responding to callbacks from
pyqtgraph such that 'async with' or try/finally are not an option for me.
When the program starts I create a single event loop, save it in a
gloabl directory, and uses it everywhere such that it's also available for
atexit and can't wait, but I couldn't manage to disconnect from atexit
for some reason. I need to play with it more.
The core problem seems to be with the OS since it should close all
connections and. reclaim all resources once the program that owns them
exits. I wonder if there is an avenue to submit a bug report like this to
Microsoft.
…On Fri, Apr 7, 2023 at 9:27 AM David Lechner ***@***.***> wrote:
If the device doesn't disconnect when the Python process ends, there is
nothing Bleak can do.
Calling async code from atexit won't do anything since it can't await and
starting a new event loop will break things. Use a context manager or
try/finally in your test coroutine to ensure that disconnect is awaited.
—
Reply to this email directly, view it on GitHub
<#1276 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAQVMQILI77EAIXIENL64UTXAA57PANCNFSM6AAAAAAWWERCWI>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
After more code tweaks, disconnecting in atexit does work and windows drops
the connection immediately. The only drawback is that the disconnect takes
a second or two which delays the program exit. I wonder if it's possible to
do a partial disconnect which just tells that OS that this connection is
not needed anymore but without waiting for the completion of the disconnect
handshake, since Windows does it outside of the program execution anyway.
My code (probe is a wrapper around bleak client):
Registration:
https://github.com/zapta/ble_stepper_motor_analyzer/blob/main/python/analyzer/analyzer.py#L55
Handler:
https://github.com/zapta/ble_stepper_motor_analyzer/blob/main/python/common/connections.py#L22
…On Fri, Apr 7, 2023 at 5:28 PM Tal Dayan ***@***.***> wrote:
In my app I don't have control over main, just responding to callbacks
from pyqtgraph such that 'async with' or try/finally are not an option for
me.
When the program starts I create a single event loop, save it in a
gloabl directory, and uses it everywhere such that it's also available for
atexit and can't wait, but I couldn't manage to disconnect from atexit
for some reason. I need to play with it more.
The core problem seems to be with the OS since it should close all
connections and. reclaim all resources once the program that owns them
exits. I wonder if there is an avenue to submit a bug report like this to
Microsoft.
On Fri, Apr 7, 2023 at 9:27 AM David Lechner ***@***.***>
wrote:
> If the device doesn't disconnect when the Python process ends, there is
> nothing Bleak can do.
>
> Calling async code from atexit won't do anything since it can't await and
> starting a new event loop will break things. Use a context manager or
> try/finally in your test coroutine to ensure that disconnect is awaited.
>
> —
> Reply to this email directly, view it on GitHub
> <#1276 (reply in thread)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAQVMQILI77EAIXIENL64UTXAA57PANCNFSM6AAAAAAWWERCWI>
> .
> You are receiving this because you authored the thread.Message ID:
> ***@***.***>
>
|
Beta Was this translation helpful? Give feedback.
-
I have the test program below which simulates a crash by terminating without closing the BLE connection. On Mac, the connection is disconnected as soon as the program exists, as expected. On windows the connection is not disconnected when the program exists, so the program sends to the device an application level command to disconnect the connection on its side, a few seconds seconds after the program exists. This does work as expected, the device does disconnect, but the strange thing is that Windows reestablishes the connection even though the test program is not running anymore, as if the program left something 'live'. Any idea what may can cause it?
Attached is a packet log and this is a high level summary of the events
5.771 - Initial connection from the PC to the device
7.586 - Program exists. No more application level transitions from the PC.
13.031 - Device disconnects the connection and starts advertising again
13.118 - PC connects again to the device. At this time the program for about 5 secs.
windows_reconnect.zip
Bleak log
Beta Was this translation helpful? Give feedback.
All reactions