Closed ghost closed 7 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.
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 .
This needs to be addressed, will try to get this into the next sprint.
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.
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.
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.
@DaniloCodecoCarvalho Thanks for reporting the notification/disconnect problem. Is this happening on iOS and/or Android?
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.
Removed label priority-1. If problems persist, just comment on this issue.
@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
@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
@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.
@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.
@ssbrewco Thanks!
@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
Closing this issue (no pun intended, haha). Let me know if to reopen.
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."