BluetoothLE Disconnection Issue after upgrading from Shiny 3.7.3 to Shiny 4.2.1

[wagenheimer]

Hi!

I am using Shiny BluetoothLE and I am upgrading from Shiny 3.7.3 to 4.2.1.

I managed to make the changes, and everything works perfectly.

I only have one issue... to disconnect from my device, I call
Peripheral.CancelConnection()

In version 3.7.3, it disconnects perfectly (100% of the time)...

But in version 4.2.1, it displays the disconnection messages in the Console:

[BluetoothGatt] close()
[BluetoothGatt] unregisterApp() - mClientIf=13

But in some situations, the device still remains connected (it has a Connection indicator LED that shows it), and if I start a new device search, it doesn't appear (because it's still connected).

I need to wait a few seconds (sometimes even minutes), and then it disconnects and reappears as available.

In version 3.7.3, this problem does not occur, and it always disconnects normally.

I've been testing and reviewing the source code, and apparently, there have been no changes in this part of Gatt disconnection. I couldn't understand what could be causing this; My code is practically the same, the only real difference is the version of Shiny I'm using.

Does anyone have any idea what might be happening that keeps this connection open for some time even when I request disconnection?

Thank you very much for any help in finding a solution to this problem.

[aritchie]

This is not the issues. Please open an with all of the info I need plus a reproducible case.

[wagenheimer]

I apologize for taking up more of your time. I intend to create a complete issue with all the necessary details. I'm currently facing an issue when connecting to a specific device. How would you suggest I create a reproducible case, considering that you won't have access to the same device I'm using for testing?

Would it be sufficient to provide only the source code of how I connect and disconnect in both versions of Shiny? I started the project from scratch using the latest version, keeping it simple for testing purposes, yet the problem persists. I plan to send you this project along with the similar code running in the previous version (where the issue does not occur). Would that be sufficient for analysis?

Once again, thank you so much for all the effort you've put into creating this comprehensive and useful library.

[aritchie]

I just need the v3 code you're using. Include the UUID's. I have a fairly straight forward way to create a test server if needed.

[wagenheimer]

After extensive investigation, I precisely identified the root cause of my issue. I'll provide the details here to assist anyone who might encounter the same problem in the future.

When invoking cancelConnection in two specific scenarios, no errors occurred, but the connection became stuck (remaining connected even after restarting the app), and it only resumed when I restarted the device.

1 - If I called cancelConnection at the EXACT MOMENT when a characteristic.ReadCharacteristicAsync was being executed.
To address this, I introduced a boolean, IsBusy=true, when calling multiple ReadCharacteristicAsync. Before invoking cancelConnection, I now wait until I am certain that IsBusy is false.

2 - If I had an active NotifyCharacteristic at the moment when cancelConnection was called.
To resolve this, I created a CompositeDisposable. Every time I subscribe to a characteristic, I append .DisposeWith(myCompositeDisposable). Before calling cancelConnection, I execute myCompositeDisposable.Clear() to clear all notifications.

By taking these two precautions, I have not encountered any further issues with the connection getting stuck. Perhaps these two cases could be handled automatically in Shiny during the cancelConnection call. I'm unsure if this change is possible, but I offer it as a suggestion, and I hope the details of my account assist others who may face the same problem.

[wagenheimer]

UPDATE: This resolved 99% of the issues I was experiencing. However, there is STILL a lingering problem related to notifications. In some cases, now very rare, the issue persists after disconnection, but only if some notification is registered. I connected and disconnected more than 100 times here for testing (with no notifications activated, only reading values), and the issue did not occur. However, when activating a SINGLE NOTIFICATION, the problem occurred (rarely than before), even disposing all the notifications before disconnecting.

I was able to identify an error message "Error disabling notification" in the console, but I'm not certain if this error always appears when the issue occurs.

Do you have any idea what might be causing this? I will prepare an issue with a case reproducing this behavior.

[wagenheimer]

I'm starting to suspect that this is a general Android issue.... Because when the problem occurs, even Force-Closing the app doesn't make the connections close (the connected light on the device stays on). And closing the app should terminate any still open connections.

https://stackoverflow.com/questions/73107781/devices-with-android-12-keep-bluetooth-le-connection-even-when-app-is-closed

One thing that used to solve it is to toggle the Bluetooth on/off.... In older versions of Shiny, there was a function to do that.... I couldn't find it in Shiny3 anymore, it doesn't exist anymore. Would it be possible to implement it back, or do the new Android versions no longer support this?

[aritchie]

Android BLE radio control has been deprecated by Google.