Kotlin-BLE-Library
Kotlin-BLE-Library copied to clipboard
ClientBleGattCharacteristic.read() never returns when device is out of range
In some situation, with the bluetooth device put in a disconnection pocket, we can have the suspend function ClientBleGattCharacteristic.read()
never returning.
In my point of view, the expected behaviour would be to have a DeviceDisconnectedException when the method is called while device is disconnected, and to have a GattOperationException when the connection is lost during the read.
To bypass the issue, I wrote this code with a 15 seconds timeout:
try {
val result = withTimeoutOrNull(READ_WRITE_TIMEOUT) { characteristic.read() }
if (result == null) {
logger.error(CHARACTERISTIC_READ_TIMED_OUT)
} else {
logger.info(CHARACTERISTIC_READ, result)
}
result
} catch (gattOperationException: GattOperationException) {
logger.error(GATT_EXCEPTION_DURING_READ, gattOperationException.status)
null
} catch (_: MissingPropertyException) {
logger.error(MISSING_PROPERTY_DURING_READ)
null
} catch (_: DeviceDisconnectedException) {
logger.error(DISCONNECTED_DURING_READ)
null
}
The bug is easy to reproduce on 1.0.15. I did not meet it on 1.0.9.
Im having this same issue, my read() is not returning. Im getting into some state where all my reads hang themselves and never return. Im Using 1.0.14.
I am having this issue as well. I spent almost week to in troubleshooting everything and varified it is bug
I was encountering this issue but was able to resolve it by performing all calls in the same coroutine scope. As soon as the code tries to communicate with the BLE device on a different scope, all calls seem to stop.
val characteristic: ClientBleGattCharacteristic = service.findCharacteristic(UUID.fromString("MYSERVICEID"))
val c = characteristic.read()
Log.d("READTAG", "Read data $c")
scope.launch {
val c2 = characteristic.read() // REACHES HERE
Log.d("READTAG", "Read data $c2") // DOES NOT REACH HERE
}
val c3 = characteristic.read() // REACHES HERE
Log.d("READTAG", "Read data $c3") // DOES NOT REACH HERE
When is this going to be addressed? This issue renders the library unusable in many cases.
Hi, I'm working on a new version of the library with updated API. It won't be backwards compatible with the current one, but it should be easier to read and understand. I hope to have an alpha release in June or beginning of July, but I'm still busy with another project.