BLE device automatically disconnecting

[chris-goodchild]

Prerequisites

• I checked the documentation and FAQ without finding a solution
• I checked to make sure that this issue has not already been filed
• I'm sure that question is related to the library itself and not Bluetooth Low Energy or Classic in general. If that so, please post your question on StackOverflow.
• I'm running the latest version

Question

Hi, I'm not certain this is a bug but I'm also unable to reproduce this issue using another client, so here goes.

On iOS, I'm seeing the BLE device disconnect very quickly after pairing. The sequence of events is as follows:

1. Initialize BLE
2. Scan for devices
3. Select the device
4. Connect and stop scan
5. Detect all services and characteristics for the device
6. Write characteristic to obtain a list of available WiFi SSIDs
7. Write characteristic to send WiFi credentials
8. Disconnect the device

Unless I trigger the first write immediately the device disconnects. It seems to disconnect unless there's an operation almost immediately which seems odd. The docs don't suggest there's a need to keep the connection open by any means, so am I missing something? When we test the BLE device using another client performing the same steps it works fine, no disconnects. It's only when I use this library it drops out. I've seen other issues related to Android but nothing for iOS.

[madej10]

@chris-goodchild thank you for reporting the issue, we're adding it to the pipeline. We'll let you know if we're seeing the same.

[chris-goodchild]

Thanks so much @madej10 - just to add some additional findings:

• The connectToDevice method succeeds and returns the device state.
• The device is then automatically disconnected and the handler for onDeviceDisconnected is invoked with a null error argument and, again, the device state as before. I am not manually disconnecting the device anywhere.
• Often, when I check my bluetooth settings I can see that the device is still connected to my iPhone despite the library reporting it as disconnected.
• Attempts to reconnect seem to work but then the device disconnects immediately again.

More often than not, as I am setting up a monitor after discovering services and characteristics, I'm also seeing an error Characteristic [UUID] not found. I have double-checked my service and characteristic UUIDs are present and correct, so I assume this error is a result of the device disconnecting?

[madej10]

Thanks @FlorinPopaPersonal we're preparing a release, after which we'll look into this issue on both platforms.

[madej10]

Hi all, we've started seeing the issue and are looking for a way to fix it. Thanks for your patience and for bringing it to our attention.

[madej10]

hi all, this is our top priority - hopefully we can at least get you an update today. Thank you all for your patience

[intent-kacper-cyranowski]

Hello everyone,
I was investigating this issue and I have to admit that I'm having trouble reproducing this error. In the case of iOS, I once managed to reach a situation where an error occurred when connecting to the device, but that was when I started trying to force its occurrence by repeatedly resetting the BLE instance and performing operations on it during the resets 😕.
I also checked it on Android and standard flow also causes no problems.
I tried to reproduce this problem according to the scenario suggested in the first post:

• searched for the device
• connected with the device
• discovered services
  then I tried the following scenario 3 times:
• wait 5 or 10 seconds
• save the data for the characteristics
• read the characteristics (checking whether the data is saved correctly)
  Related code, which can be checked using the example app, can be found here:
  https://github.com/dotintent/react-native-ble-plx/blob/fix/1197_device_automatically_disconnecting/example/src/screens/MainStack/DisconnectBeforeWrite/DisconnectBeforeWrite.tsx

Despite waiting between each step, nothing breaks and everything works as intended. So I have few questions:
Do you have any additional suggestions on what I should do to reproduce this problem?
How (and whether) do you use BLE instance destroy function in your applications?
How long do your apps stay active?
How often are requests sent to the device (how long is the interval between subsequent requests)?
Do we assume that the user turns off (moves to background) the application after connecting?

[amit13091992]

Facing same issue on Android and iOS as well. Can anyone update on fixing this issue?

[madej10]

@a396901990 @amit13091992 could you please reply to the questions posted by @intent-kacper-cyranowski in the previous comment to help us narrow it down:

Despite waiting between each step, nothing breaks and everything works as intended. So I have few questions:
Do you have any additional suggestions on what I should do to reproduce this problem?
How (and whether) do you use BLE instance destroy function in your applications?
How long do your apps stay active?
How often are requests sent to the device (how long is the interval between subsequent requests)?
Do we assume that the user turns off (moves to background) the application after connecting?

[intent-kacper-cyranowski]

Hi @eliaslecomte
Thanks for your time and logs.
I tried to reproduce it with rapid writes, but with no luck. Could you create separate issue with minimal repro, as issue seems to be different from what @joanmarcs faces.

I would also ask everyone else that needs help with similar issue, yet unrelated to iOS, to create separate issue and provide relevant information

[MahmoudNafiseh]

@intent-kacper-cyranowski I had this issue recently, and found out its due to setting the timeout property in the connectToDevice option.

What fixed it:

	bleManager
	.connectToDevice(deviceId, {
		autoConnect: false,
		requestMTU: 96,
		timeout: Platform.OS === 'android' ? undefined : 45000,
	})

Setting the timeout to a 45000 made my device disconnect after 45 seconds, even though I was reading/writing data.

I was on a Samsung Galaxy FE S21. Maybe this is the issue and could possibly help?

[intent-kacper-cyranowski]

Hi @MahmoudNafiseh
Thank you for sharing your observation. We are aware of the issue you have mentioned, the fix will be released in the next version. Yet the issue you have mentioned is android specific and the original issue in this thread specifies that the problem was found on iOS.

[enriquezc]

Any update on when the next release will be? We're seeing the issue @MahmoudNafiseh found on Android and would love some resolution

[ApplicationNinja]

I can confirm this same issue, using PLX version 3.2.1, Google Pixel 9 connected to an ESP32 device, occurs exactly at 30 seconds.

[AdriBee]

Experiencing the same issue here. I am not using an ESP32, but another MCU (Dialog/Renesas one). The connection drops after about 10 seconds, then it reconnects, and it drops it again continuously. It is only happening on Android for me, iOS is working fine.

I recently upgraded the app to RN 0.74 and went from ble-plx 2.0 to 3.2.1. This library was working fine with the same code on Android, but now it is not.

[codewizardVN]

Experiencing the same issue here. I am not using an ESP32, but another MCU (Dialog/Renesas one). The connection drops after about 10 seconds, then it reconnects, and it drops it again continuously. It is only happening on Android for me, iOS is working fine.

I recently upgraded the app to RN 0.74 and went from ble-plx 2.0 to 3.2.1. This library was working fine with the same code on Android, but now it is not.

I am having the same problem as you. Did you find a solution?

[chris-goodchild]

I am still experiencing this issue on iOS, regardless of OS version. I have tried implementing reconnect logic and even destroying/recreating the manager but to no avail. We have a large project so trying to figure out what, if any, compatibility issues there may be has been a lengthy and ultimately fruitless pursuit.

My observations are still the following:

1. Create BLE manager
2. Start scan
3. Connect to device
4. Discover services and characteristic
5. Setup monitor
6. Write characteristic

Following step 6, it may allow writing several times or the first write will fail and a "Device Disconnected" BLE error is surfaced. Checking isDeviceConnected usually returns true but then subsequent write attempts also fail. It's baffling. I wondered if the manager's internal state was somehow getting messed up (why would isDeviceConnected return true if I just got a Device Disconnected error?) so I attempted to put a workaround in where, in the event of a disconnect error, I destroy the current manager and create a new one, but this doesn't work reliably.

On Android these issues are far less apparent, which seems at odds with others' reports of similar issues.

[AdriBee]

Hello @chris-goodchild @codewizardVN ! The problem I had was only with Android. On iOS, I did not experience the problem, so there could be two separate issues. I am unaware of the iOS one, but here is the fix for the Android.

Okay, here is a quick fix that you can do. This is fixed on the upcoming update on this library, but as a work around for the ones who need it now, here is what I did to fix it.

The main problem is on the BLE PLX library, and it needs to be fixed on this file:
node_modules/react-native-ble-plx/android/src/main/java/com/bleplx/adapter/BleModule.java

Change this:

•  connect = connect.timeout(timeout, TimeUnit.MILLISECONDS);
  

For this:

•  connect = connect.timeout(
  

•    Observable.timer(timeout, TimeUnit.MILLISECONDS),
  

•    item -> Observable.never()
  

•  );
  

Now, here is the problem. Changing this once, will work, but this change is not permanent, as when you install your node reqs again, this change will get overrided. To overcome this and make is easier, I used https://www.npmjs.com/package/patch-package. This package basically will create .patch files that will automatically override your installation every time you run a yarn install or whatever you use to install all your reqs.

The code I am providing here is already fixed on the upcoming update of the BLE PLX. I would recommend searching across the commit history on this library to see if there is any fix for the iOS app side, and if there is, you can apply a similar process to fix that witht he patch-package as well.

Hope this helps!