evothings / cordova-ble

Bluetooth Low Energy plugin for Cordova
http://www.evothings.com/
Apache License 2.0
242 stars 103 forks source link

Function close() does not disconnect BLE device on Android #108

Closed ghost closed 7 years ago

ghost commented 8 years ago

It has been reported that close() does not disconnect devices on Android.

Issue report:

"In fact my app should connect a smartphone and a fitness equipment if the rssi between them is less than a determined value and keep connected only if this value doesn't change. The fitness equipment has a dock to allow the perfect distance (and rssi) between smartphone and equipment.

Thus, if user take the smartphone and walk away (change the rssi), the app will receive a batch of data from the fitness equipment and close the BLE connection. I tried to use close() but it didn't work.

However, if user come back and want to reconnect to the same fitness equipment 10 seconds later (a weird case but possible), the app should repeat scan and connection the same way as it did at the first time and this is the point where I can't figure it out. Once I have disconnected, I can't reconnect without call reset() and wait 15 or 20 seconds."

myyellowshoe commented 8 years ago

Experiencing very similar issues. It seems that the connection isn't really being closed or at least not fully. It acts up though, somewhat intermittently. Sometimes i close the connection and can reconnect just fine. Though in others though I'll close the connection and can't reconnect until I restart bluetooth.

sjrcgtek commented 8 years ago

I have seen this same behavior on iOS, too. It appears the device is still connected as it doesn't show up when I scan. Sometimes it will show up again if i wait long enough. Other times, I have to pull the batteries from the BLE device.

On Fri, Jul 15, 2016 at 2:45 PM, Justin notifications@github.com wrote:

Experiencing very similar issues. It seems that the connection isn't really being closed or at least not fully. It acts up though, somewhat intermittently. Sometimes i close the connection and can reconnect just fine. Though in others though I'll close the connection and can't reconnect until I restart bluetooth.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/evothings/cordova-ble/issues/108#issuecomment-233052406, or mute the thread https://github.com/notifications/unsubscribe-auth/ACpRcvRDQZ9W6qWyvB16SyAAw7QR24AJks5qV-NBgaJpZM4JLGP9 .

ghost commented 8 years ago

This needs to be addressed, will try to get this into the next sprint.

ghost commented 8 years ago

Hi everyone, tested close() on a TI SensorTag CC2650, and it works to call close() to disconnect the device. The device goes into scanning mode and I can connect to it again. (It can be noted that the connect callback is not called in this case, the application does not get an disconnect event. But this is by design I assume.)

Can you give me some more details about how to reproduce, type of device used and so on? That would be helpful.

I should point out that there was a rather bad bug in the Android BLE plugin that caused the app to fail when a device disconnected (not when calling close though), for example when turning on the power on the device or turning off Bluetooth on the phone. This bug is fixed and there is a new plugin release 1.4.4.

Thanks, Mikael

Update 1: Retested with CC2650 and managed to reproduce, close() does not disconnect the device. Will investigate further.

Update 2: Hmm, seems it was a bug in my test procedure that made close appear not to work... Now close is working every time. If you can help with further details about the devices you have tested with, that would be great.

ghost commented 8 years ago

There is now a new version of Evothings Viewer for Android (version 1.4.2) on Google Play. This version contains an update BLE plugin that fixes a bug that made a BLE device auto-connect when disconnected (when calling close). Not sure this is the same problem you have experienced, but could be worth trying.

DaniloCodecoCarvalho commented 8 years ago

With more tests and after update the plugin I've noticed another thing. My problem is notification.

I found that connect/disconnect (with close) is working every time but enableNotification doesn't. So I had to use readCharacteristic in a loop every 2 seconds.

If I connect and read using enableNotification and disconnect without disableNotification the reconnect always fail. If I connect and read using enableNotification and disconnect after disableNotification the reconnect sometimes work. If I connect and read using just readCharacteristic in a loop, the reading works every time and connection is faster.

ghost commented 8 years ago

@DaniloCodecoCarvalho Thanks for reporting the notification/disconnect problem. Is this happening on iOS and/or Android?

DaniloCodecoCarvalho commented 8 years ago

I've just tested in Android because I am facing scan problems in IOS yet. The Android device is a Moto G 2nd gen with Android 5.0.1.

I have to admit that I can not confirm the problem in ble plugin. I don't have others ble devices to test, so could be a hardware problem and not a plugin problem.

ghost commented 7 years ago

Removed label priority-1. If problems persist, just comment on this issue.

ghost commented 7 years ago

@DaniloCodecoCarvalho Regarding notifications not working, do you know if the BLE device supports them on the characteristic you want to use? I encountered a similar problem with a device, notifications could not be used, because there were not enough BLE "channels" supported by the device. The official solution was to poll using read.

Also there is now a new release of the BLE plugin, version 2.0.0, see release notes here: https://github.com/evothings/cordova-ble/releases/tag/2.0.0

ssbrewco commented 7 years ago

@mikaelkindborg

I have been testing the evothings.ble.close() on Android & iOS with the latest BLE & viewer apps. Seems to be working, but a few observations FWIW:

-ssbc

ghost commented 7 years ago

@ssbrewco The disconnectedCallback from connectToDevice not being called after close is called is by design. Do you have any ideas regarding this? Should this be changed you think?

Usually I have seen close() to make devices go back to announcement mode at once.

Somewhat related, I have seen that when you e.g. pull the battery on the device, it takes a while before the disconnected callback is called. I believe this is the time it takes for the BLE stack to determine the device as unavailable.

ssbrewco commented 7 years ago

@mikaelkindborg

I think you stated the important thing already: the disconnectCallback is not called after close by design. Knowing the expected behavior is likely sufficient - I don't think there is a compelling reason to change this - so long as the connectionState is updated right away by the close function.

Thanks for clarifying.

ghost commented 7 years ago

@ssbrewco Thanks!

ghost commented 7 years ago

@ssbrewco Updated the documentation comment to be more clear about the behavior of close and the disconnected callback. See this commit: https://github.com/evothings/cordova-ble/commit/0ca2a3bfa18b5a83e929eb89dcbfb55c96843dd5

ghost commented 7 years ago

Closing this issue (no pun intended, haha). Let me know if to reopen.