New issue
Advanced search Search tips

Issue 718144 link

Starred by 1 user
Status: WontFix
Owner: ----
Closed: May 2017
Cc:
r...@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug-Regression



Sign in to add a comment

Chrome OS Bluetooth low energy getServices or startCharacteristicNotifications fails after a disconnect

Reported by j...@zode64.com, May 3 2017 
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.96 Safari/537.36
Platform: 9334.58.0

Steps to reproduce the problem:
1. Install an app that functions with a bluetooth device. I am using the pocketlab app and pocketlab device.
2. Start the app connect
3. Load the services and start a notification
4. Call disconnect
5. Reconnect to the same device
6. Try load services
7. Try start the same notification

What is the expected behavior?
The services load and I can restart the notification

What went wrong?
Sometimes getServices return an empty array and if it does startNotificationCharacteristic fails with 'Operation failed'.

Did this work before? Yes 56 (I think)

Does this work in other browsers? N/A

Chrome version: 58.0.3029.89  Channel: stable
OS Version: 58.0.3029.89
Flash Version: 

I am not sure where the disconnect behavior has changed according to another bug I was involved with https://bugs.chromium.org/p/chromium/issues/detail?id=550944

For the notifications, it might be using a cached version of the characteristics that fail after a disconnect. It appears that I can sometimes force the services to reload by sending commands (pair, connect, disconnect) through the crosh shell. After this it starts working before failing the next time.

Some code like this might replicate it. 

chrome.bluetooth.getDevice('F8:C2:55:D9:88:95', function(device) {
    chrome.bluetoothLowEnergy.connect(device.address, {persistent:false}, function() {
        chrome.bluetoothLowEnergy.getServices(device.address, function(services) {
            console.dir(services);
            chrome.bluetoothLowEnergy.disconnect(device.address, function() {
                chrome.bluetoothLowEnergy.connect(device.address, {persistent:false}, function() {
                    chrome.bluetoothLowEnergy.getServices(device.address, function(services) {
                        console.dir(services);
                    });
                });
            });
        });
    });
});

Comment 1 by ortuno@chromium.org, May 3 2017

Cc: r...@chromium.org
Components: -Blink>Bluetooth Platform>Apps>API
Status: WontFix (was: Unconfirmed)
Sadly I don't think there are any bugs here. You are just running into some of the API's quirks.

1. GetServices is empty: People keep running into this problem... After you connect to a device we need to discover all its attributes. This doesn't happen immediately and there is no guarantee that by the time you call getServices we will have discovered the device's attributes. I've seen people add a delay between a connection and getService to solve this.

2. Operation Failed error for notifications: This is a side effect of 1. Since we haven't discovered the devices attributes yet we can't start notifications.

If you are the author of the app I would recommend you take a look at the Web Bluetooth API[1] to see if it satisfies your needs. That API is supported across Android, macOS and ChromeOS, with windows support coming in the future. That API is better designed and avoids many of the pitfalls of the Chrome Apps API.

https://developers.google.com/web/updates/2015/07/interact-with-ble-devices-on-the-web

Comment 2 Deleted

Comment 3 by j...@zode64.com, May 4 2017 

I have been testing out the Web Bluetooth API because I am wanting to move onto it myself but it still doesn't quite meet our requirements. For example using the Chrome API the app can indicated which device is closest with the RSSI value before connecting (and pairing isn't necessary) which doesn't seem possible with the device list that is presented by Web Bluetooth. Also all our devices are shipped with the same name and there may be multiple operating in the same room so I don't think the users will be able to tell which is their device in the list. In addition to this the advertising API still seems incomplete so if the users pair with them all they still can't see which is closest (although this isn't really an acceptable solution anyway). 

If you have any suggestions or relevant outstanding issues regarding the Web Bluetooth API please provide.

As for the issues I am seeing the Chrome API

1. Although I have seen this issue before in previous versions of Chrome OS and have a mechanism in place to recover from it when it happens it is now happening much more frequently. I have tried adding a delay but then if it does pass it moves on to the Operation Failed notifications error. 

2. The Operation Failed error will show up even when the services are reported as being discovered and there has been an unreasonable delay and will do so fairly consistently after a disconnect.

This led me to believe that the system disconnect behavior might have changed and/or there is a problem with caching the characteristics.

Comment 4 by j...@zode64.com, May 8 2017 

Created a separate issue for startNotificationCharacteristic https://bugs.chromium.org/p/chromium/issues/detail?id=719581
►

Sign in to add a comment