BleGattException CHARACTERISTIC_READ: Device disconnects but BluetoothGatt is not closed properly #63
Assignees
Labels
bug
Bug that is caused by the library
Comments
|
Some additional infos: I am using a Nexus 5X with Android 6.0.1 |
|
Hello there, The thing is to change the and the whole implementation of RxBleGattCallback would be: |
|
I am not sure if I applied your changes correctly, but it seams that BluetoothGatt is still not closed Actually I am starting to belive that this isn't an issue with RxAndroidBle but with Android itself. I originally assumed that closing BluetoothGatt would clear the cache that holds the mapping between characteristic UUIDs and handles. I did some more tests and noticed that the following scenario still causes CHARACTERISTIC_READ errors despite closing BluetoothGatt:
I did some research and found this issue: Android does not discover services if device supports Service Changed. It seams that Android assumes that handles won't change, even if the peripheral includes the "service changed" characteristic. This also explains why the issue is solved by disabling and re-enabling bluetooth on the Android device. For me personally this isn't a big issue because all I wanted to do was to experiment with BLE and to control some LEDs with it. I just have to make sure that the handles don't change while I am using it, or I have to restart bluetooth on my Android device. But if you want to look further into the issue of changing handles, I put the code that uses BlueZ to create the peripheral and the code for the app on Github a few days ago. |
|
Thanks for sharing the code - I will try to recreate the issue locally.
This situation prevent's closing the The second thing is to allow using |
|
Hi @DariuszAniszewski -- I'm seeing the same output in my project. It seems like the disconnect callbacks are being fired before the connection actually closes. Is this a correct assessment? Any possibility for a bugfix? |
|
@lavenj @WIStudent Sorry for such a long wait. I have a possible bugfix for the situation where the |
|
I moved on to a different project so I can't test it at the moment. |
|
@dariuszseweryn thanks for looking at this! We have a reasonable workaround implemented so are OK for now. This library continues to be a huge help. Off-topic but discovered RxBleAdapterStateObservable while digging through the source. So clean and easy! You should throw it in the docs if it's not already in there 😄 |
|
@lavenj can you share more info about the workaround? @WIStudent I am trying to use your Raspberry Pi 3 script to recreate the issue. I have installed a fresh Raspbian on the RPi3 and commented out all interactions with the display from the source code. I have enabled the bluetooth by calling I am not very experienced with linux and Raspberry Pi configuration so maybe you could point me in the right direction. Possible causes I can think off:
|
|
I highly recommend updating Bluez to the latest version (which is currently 5.43) . Some of its BLE features are quite new and might not be impemented in an older version. I used this tutorial to compile and install Bluez from source on a Raspberry Pi. It should only take a few minutes. If you don't want to update, you need to set at least the If you have still issues accessing the dbus interfaces after that, make sure that you have the packages
The first two will install the python 2 and 3 bindings for GObject, the third one will install the python-dbus library. If you downloaded the bluez source directory, you can also try to run the |
|
@WIStudent which connects to the RPi3 and every second it tries to read a characteristic. Then at some point I closed the gatt server script and got a proper closing of the So perhaps some recent fix has unintentionally fixed this issue as well. I was checking with Nexus 5 and Nexus 5X both with Android 6.0.1. Fun fact: I couldn't get any device with Android < 6.0 to connect to the Raspberry Pi 3 - always getting status=133 (GATT_ERROR) when connecting. It would be awesome if you could re-check this issue using the SNAPSHOT release or the newest version if it will be available before. Yet - I still need to add a |
|
I tested it again with the 1.1.0-SNAPSHOT. I used bluez-5.41 again on the Pi to rule out any changes on that side. But Unfortunately I have upgraded my Nexus 5x to Android 7.0 in the meantime so I can't tell if the problem is solved in Android 6. Interestingly the behavior changed in Android 7 again. Reading from and writing to an existing characteristic works as expected. Bluez on the Pi received and sent the following packets (Use The next log shows the attempt to read and write the same characteristic after it was removed: The BleGattExceptions are still thrown but instead of closing the connection automatically it is now kept alive. |
|
I wish I had written tests for |
|
@WIStudent Excuse me for asking again but I have fixed the behaviour to be inline with 1.x.x and it should be working fine now. (I hope... - it at least works as intended for me) |
|
I switched to the 1.2.0-SNAPSHOT and tested it again. Now I see the same behavior as you do. |
|
So it seems that cause of this issue (that is in the topic) is resolved. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I am currently using Bluez 4.51 and its D-Bus API to turn a Raspberry Pi 3 into a BLE peripheral. It provides a single service with a few characteristics to read from and write to.
The app uses the following code to connect to the periheral and to read some characteristics:
As long as nothing unexpected happens, this works as intended. The app searches for the peripheral, connects to it, reads some characteristics and disconnects from it on the pause event.
The issue occurs when the program that provides the service over the D-Bus api on the Pi is terminated. Bluez then removes the service with its characteristics, but does not disconnect any connected central device. As expected, a BleGattException occurs if the app tries to read a characteristic that is no longer there.
As you can see,
RxBleRadioOperationDisconnectis started and finishes. Usingbluetoothctlon the Pi i can see, that the Android device is being disconnected, but Logcat never shows that BluetoothGatt was closed.The BleGattExceptions still occur even after the service and its characteristics are added to the peripheral again.
The reason for that could be that Bluez does not assign the same handles to services and characteristics if they are removed and added again. But because BluetoothGatt was not closed, Android still expects the characteristics to be reachable under the old handles, I guess.
The only way I could get the app running again was to disable and then re-enable bluetooth on the Android device.
The text was updated successfully, but these errors were encountered: