This issue impacts both web-bluetooth and chrome.bluetooth / chrome.bluetoothLowEnergy APIs.

We should maybe review the model for creating bluetooth devices. If I'm right, we can also end-up having devices that are both LE and classic, hence 2 objects would represent same instance.

Also we might want to retrieve connected BLE devices using [CBCentralManager retrieveConnectedPeripheralsWithServices:nil] (https://developer.apple.com/library/ios/documentation/CoreBluetooth/Reference/CBCentralManager_Class/index.html#//apple_ref/occ/instm/CBCentralManager/retrieveConnectedPeripheralsWithServices:)

Error is thronw in bluetooth_classic_device_mac.mm, line 78 :

void BluetoothClassicDeviceMac::CreateGattConnectionImpl() {
  // Classic devices do not support GATT connection.
  DidFailToConnectGatt(ERROR_UNSUPPORTED_DEVICE);
}

jlebel@ can you have a look at this issue?

[mac triage]

Hi François,

  our mice and keyboards are not dual mode, they are BLE only.

They can switch between BLE and Unifying protocol (Logitech proprietary - HID vendor) back-and-forth, but they don't support BR/EDR profiles.

The issue here is that [IOBluetoothDevice pairedDevices] also reports BLE devices, if they are paired with the system.

Oops Julien, I meant to add this comment to https://bugs.chromium.org/p/chromium/issues/detail?id=630586.

I'll delete Comment #6 to keep this thread clean. Sorry for that.

Thanks François, no pb!

Just a drive-by,
"// Classic devices do not support GATT connection.
  DidFailToConnectGatt(ERROR_UNSUPPORTED_DEVICE);"

This is incorrect. The BT spec allows GATT over BR/EDR.

Indeed, comment in code is incorrect.

See also my comment #3 : https://bugs.chromium.org/p/chromium/issues/detail?id=630581#c3

Hi guys (François / Jérôme),

  In order to fix this issue, I guess we have 2 choices here..

  First one (probably the easiest), is to modify BluetoothAdapterMac::AddPairedDevices() so that it doesn't create a BluetoothClassicDevice when IOBluetoothDevice instance represent a BLE device. We also have in same method to use CoreBluetooth's [CBCentralManager retrieveConnectedPeripheralsWithServices:nil].

  Second one requires a design change that will work with dual-mode devices, but IMO there are few on the market. We can retrieve paired devices (BLE and classic) using [IOBluetoothDevice pairedDevices]. We would need to also use CoreBluetooth API for BLE devices (see comment #2). The good thing of using IOBluetoothDevice is addressString property (https://developer.apple.com/library/mac/documentation/IOBluetooth/Reference/IOBluetoothDevice_reference/#//apple_ref/occ/instp/IOBluetoothDevice/addressString) ; see also https://webbluetoothcg.github.io/web-bluetooth/#bluetooth-device-identifiers

I'm stuck also with same issue when using chrome.bluetooth.getDevices() + chrome.bluetoothLowEnergy.connect(address). It ends-up using same code, that will return a classic device, and will fail to connect (obviously!).

Fixing this issue for web-bluetooth would also fix chrome APIs. Also we would avoid returning 2 devices : when scanning for devices you get a LE device with a different address..

I can provide a CL implementing solution #1 in Comment 14.

Also FWIW we don't support chrome.bluetoothLowEnergy on any platforms other than Chrome OS. It started working on mac because of the work Web Bluetooth has been doing but Web Bluetooth has a different set of requirements than the chrome.bluetoothLowEnergy API and therefore chances are the API will be (or probably is already) broken on mac.

Hi Giovanni!

That's a good news, in sense that you're very close to have it working!

There is probably an issue in documentation, cause it states that the API works ' only on OS X, Windows and Chrome OS'. 

I remember indeed that it way stated 'only Chrome OS' some time ago. You might want to ask @keybuk or @armansito.

Indeed. It was added by accident a while ago. I submitted a patch to correct it. http://crrev.com/2237833003

Oh OK... thanks for correcting the doc.

Now I think we're close to have both APIs work by fixing this issue.

I don't think we intend to officially support it. If people want to interact with Low Energy Devices outside of Chrome OS they can use the Web Bluetooth API.

This is still a very valuable API: in combination with chrome.usb (waiting for web-usb) and other chrome.serial + chrome.hid, it provides a good API for interacting with BLE devices.

At Logitech we have tools that use those APIs, just missing support for BLE. Those tools require Mac or Windows.

Even if it is not officially supported, that'd be great if it worked on Mac.

Anyway, I'm pretty sure going forward, web-bluetooth issues will also fix chrome.bluetoothLowEnergy cause this bug is duplicated.

Thanks!

Guys, I uploaded this CL :
https://codereview.chromium.org/2242833002/

It is far from perfect nor tested, but to get the idea..

Cheers

Feel free to submit another one @jlebel! Don't want to steal you ownership.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ff8c749c2d358b34184d156fb0939a14e264438f

commit ff8c749c2d358b34184d156fb0939a14e264438f
Author: jlebel <jlebel@chromium.org>
Date: Mon Nov 07 07:18:30 2016

bluetooth: mac: add connected LE devices to chooser

On a mac, when showing list of available low energy devices, low energy devices which are connected are not shown.

To get the list of devices, -[CBCentralManager scanForPeripheralsWithServices:options:] is used. This method reports only advertising devices.

For devices that are connected but doesn't advertise, -[CBCentralManager retrieveConnectedPeripheralsWithServices:] needs to be called when starting a discovery session.

BUG=630581

Review-Url: https://codereview.chromium.org/2339253002
Cr-Commit-Position: refs/heads/master@{#430229}

[modify] https://crrev.com/ff8c749c2d358b34184d156fb0939a14e264438f/device/bluetooth/bluetooth_adapter.cc
[modify] https://crrev.com/ff8c749c2d358b34184d156fb0939a14e264438f/device/bluetooth/bluetooth_adapter.h
[modify] https://crrev.com/ff8c749c2d358b34184d156fb0939a14e264438f/device/bluetooth/bluetooth_adapter_mac.h
[modify] https://crrev.com/ff8c749c2d358b34184d156fb0939a14e264438f/device/bluetooth/bluetooth_adapter_mac.mm
[modify] https://crrev.com/ff8c749c2d358b34184d156fb0939a14e264438f/device/bluetooth/bluetooth_adapter_unittest.cc
[modify] https://crrev.com/ff8c749c2d358b34184d156fb0939a14e264438f/device/bluetooth/bluetooth_low_energy_device_mac.mm
[modify] https://crrev.com/ff8c749c2d358b34184d156fb0939a14e264438f/device/bluetooth/test/bluetooth_test.h
[modify] https://crrev.com/ff8c749c2d358b34184d156fb0939a14e264438f/device/bluetooth/test/bluetooth_test_mac.h
[modify] https://crrev.com/ff8c749c2d358b34184d156fb0939a14e264438f/device/bluetooth/test/bluetooth_test_mac.mm
[modify] https://crrev.com/ff8c749c2d358b34184d156fb0939a14e264438f/device/bluetooth/test/mock_bluetooth_cbperipheral_mac.mm
[modify] https://crrev.com/ff8c749c2d358b34184d156fb0939a14e264438f/device/bluetooth/test/mock_bluetooth_central_manager_mac.h
[modify] https://crrev.com/ff8c749c2d358b34184d156fb0939a14e264438f/device/bluetooth/test/mock_bluetooth_central_manager_mac.mm

This patch creates BluetoothAdapter::RetrieveGattConnectedDevicesWithDiscoveryFilter((). This method has to be used in BluetoothDeviceChooserController::GetDevice().

jlebel: I was enabling this for web bluetooth but bumped into some weird behavior:

If we pass in:

CBUUID* heartRateServiceUUID = [CBUUID UUIDWithString:@"180D"];

as the UUID we can successfully find the device. But if we pass in:

CBUUID* heartRateServiceUUID = [CBUUID UUIDWithString:@"0000180D-0000-1000-8000-00805F9B34FB"];

then we can't find the device.

This means that:

    NSString* uuidString =
        base::SysUTF8ToNSString(uuid->canonical_value().c_str());
    cbUUIDs = @[ [CBUUID UUIDWithString:uuidString] ];

Won't be able to find the device because it uses the expanded form. Is this an Apple bug or am I missing something obvious here?

Deleted: HeartRateMonitor 2.zip 1.9 MB

HeartRateMonitor 2.zip 1.9 MB Download

See startScan in HeartRateMonitorAppDelegate.mm in the project attached in #27

ortuno@, according to https://codereview.chromium.org/2513323002/#msg4, you may want to be the owner of this bug as we still need to implement RetrieveGattConnectedDevicesWithDiscoveryFilter on android. Right?

per #27 we also have to fix the current implementation on macOS.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot