Android: disconnect immediately after connect 5 out of 6 times

[gregoiregentil]

As mentioned in the readme file, I'm having trouble on Android with a disconnect event just after a connect.

Here is the log of such problem:

2022-08-26 20:46:30.169 29696-29893/app D/BluetoothGatt: connect() - device: 70:2C:1F:33:19:07, auto: false
2022-08-26 20:46:30.170 29696-29893/app D/BluetoothGatt: registerApp()
2022-08-26 20:46:30.170 29696-29893/app D/BluetoothGatt: registerApp() - UUID=ecf8cf37-931b-4dd9-a0da-2dd65ec9808d
2022-08-26 20:46:30.175 29696-30564/app D/BluetoothGatt: onClientRegistered() - status=0 clientIf=10
2022-08-26 20:46:32.913 29696-30564/app D/BluetoothGatt: onClientConnectionState() - status=133 clientIf=10 device=70:2C:1F:33:19:07
2022-08-26 20:46:32.931 29696-30564/app D/BluetoothGatt: close()
2022-08-26 20:46:32.944 29696-30564/app D/BluetoothGatt: unregisterApp() - mClientIf=10
2022-08-26 20:46:32.950 29696-30564/app D/Device: Disconnected from GATT server.

status=133 is not good. My connect action works 1 out of 6 times. I can't figure out a scenario to reproduce a working or not-working situation.

Nevertheless, I'm using the same BluetoothLE peripheral on a native Android application (not Ionic/Capacitor) using the BluetoothLE library https://github.com/weliem/blessed-android and it's working 10 out of 10 times. The log in a similar situation shows:

2022-08-26 20:28:05.416 7215-7215/app D/BluetoothGatt: connect() - device: 70:2C:1F:33:19:07, auto: false
2022-08-26 20:28:05.419 7215-7215/app D/BluetoothGatt: registerApp()
2022-08-26 20:28:05.421 7215-7215/app D/BluetoothGatt: registerApp() - UUID=1d44d4ad-3c89-44c2-a3fb-e035cac02ac6
2022-08-26 20:28:05.430 7215-7310/app D/BluetoothGatt: onClientRegistered() - status=0 clientIf=11
2022-08-26 20:28:08.088 7215-7247/app D/BluetoothGatt: onClientConnectionState() - status=133 clientIf=11 device=70:2C:1F:33:19:07
2022-08-26 20:28:08.099 7215-7247/app D/BluetoothGatt: close()
2022-08-26 20:28:08.111 7215-7247/app D/BluetoothGatt: unregisterApp() - mClientIf=11
2022-08-26 20:28:08.245 7215-7215/app D/BluetoothGatt: connect() - device: 70:2C:1F:33:19:07, auto: false
2022-08-26 20:28:08.246 7215-7215/app D/BluetoothGatt: registerApp()
2022-08-26 20:28:08.247 7215-7215/app D/BluetoothGatt: registerApp() - UUID=7322b808-72ff-4694-9f85-78cc684d6779
2022-08-26 20:28:08.256 7215-7816/app D/BluetoothGatt: onClientRegistered() - status=0 clientIf=11
2022-08-26 20:28:09.803 7215-7247/app D/BluetoothGatt: onClientConnectionState() - status=0 clientIf=11 device=70:2C:1F:33:19:07
2022-08-26 20:28:09.820 7215-7215/app D/BluetoothGatt: discoverServices() - device: 70:2C:1F:33:19:07
2022-08-26 20:28:10.572 7215-7247/app D/BluetoothGatt: onConnectionUpdated() - Device=70:2C:1F:33:19:07 interval=54 latency=0 timeout=500 status=0
2022-08-26 20:28:11.317 7215-7245/app D/BluetoothGatt: onSearchComplete() = Device=70:2C:1F:33:19:07 Status=0
2022-08-26 20:28:11.345 7215-7215/app D/BluetoothGatt: requestConnectionPriority() - params: 1
2022-08-26 20:28:11.380 7215-7816/app D/BluetoothGatt: onConnectionUpdated() - Device=70:2C:1F:33:19:07 interval=6 latency=0 timeout=500 status=0
2022-08-26 20:28:11.471 7215-7247/app D/BluetoothGatt: onConnectionUpdated() - Device=70:2C:1F:33:19:07 interval=6 latency=0 timeout=500 status=30
2022-08-26 20:28:11.853 7215-7215/app D/BluetoothGatt: configureMTU() - device: 70:2C:1F:33:19:07 mtu: 184
2022-08-26 20:28:11.867 7215-7245/app D/BluetoothGatt: onConfigureMTU() - Device=70:2C:1F:33:19:07 mtu=184 status=0
2022-08-26 20:28:11.869 7215-7215/app D/BluetoothGatt: setCharacteristicNotification() - uuid: 0000fff5-0000-1000-8000-00805f9b34fb enable: true

I'm getting the same 133 status but as you can see at "2022-08-26 20:28:08.245", the Blessed library immediately tries to reconnect (I'm not doing this). Though I'm not fully sure, I think that the good line of Blessed is:

https://github.com/weliem/blessed-android/blob/master/blessed/src/main/java/com/welie/blessed/BluetoothPeripheralManager.java#L117

The associated comment is very interesting and explains why a connect needs to follow a first connect.

Could you consider doing something similar?

[pwespi]

https://github.com/weliem/blessed-android/blob/master/blessed/src/main/java/com/welie/blessed/BluetoothPeripheralManager.java#L117

This line in blessed is from the BluetoothPeripheralManager class, which is described as This class represent a peripheral running on the local phone, so I don't think it's relevent when you're connecting with you phone (as the central device) to a peripheral device.

However, the blessed library seems to have some retry logic. See https://github.com/weliem/blessed-android/blob/6f2c5d367294825d2f1586b55aa4a2c00c04c210/blessed/src/main/java/com/welie/blessed/BluetoothCentralManager.java#L232-L259 Basically it just retries if a connection fails.

I'm a bit hesitant to implement a retry logic in the plugin, because I think the desired behavior will be different for every app. So I'd suggest that you implement some retry logic directly in the app. This also allows you to show some kind of indication that the connection is retried.

[gregoiregentil]

Thank you for the reply. Sorry for the misleading web pointer.

I think that I can't do this in the app because it's too late. I get the disconnect event 3 seconds later and then if I try to reconnect, I'm getting the same problem with an 80% probability. I don't get the failure immediately in my application.

I still believe that it's linked to your comment in the homepage readme file about Android and failed connection.

I understand that you are hesitant to implement it until more people have experienced the issue. Without affecting other people, an option would be to add an option "nbretry" in the connect API with a default to zero. That would leave the logic identical to the current situation by default.

Alternatively to all of this, could you point and explain in your plugin code where the blessed logic could be duplicated? I will patch myself if necessary though I'm not a Kotlin expert (hence it's difficult to read someone else code in a new language).

[danielknobe]

I have the same issue here. I have a Pi 3 with Bullseye and Bluetooth configured in peripheral mode. The behavior is the same as described by @gregoiregentil . With other tools everything works fine.

[gregoiregentil]

I have improved my peripheral code and the problem is not here any more. Closing. Sorry for @danielknobe

[peitschie]

@gregoiregentil out of interest, are you able to share any specifics about the improvements you made? I've seen a similar problem in the past, but never had the time to root cause it much further...

[gregoiregentil]

I have my own implementation of ble and gatt server on the peripheral device (I'm not using any library or framework) and there were multiple blugs in the advertising procedure. Difficult to give some advice. If you can, use a proven BLE library/framework on your peripheral device.