Should `requestDevice` allow choosing more than 1 device?

[jracle]

While reading device discovery and issue #2, came to my mind the issue where an app wants to communicate with more than 1 device. I'm not talking about connecting to a class of devices, but am thinking of a control panel (say mouse/keyboard configuration in my case) where user will configure devices which expose same vendor-defined service. User would have to select more than 1 device in a popup, which is fine.

[jyasskin]

I definitely think we should support this eventually, just like <input type="file" multiple>.

I'm not sure exactly what shape the API should have.

1. A separate requestMultipleDevices function that accepts multiple selections and returns Promise<sequence<BluetoothDevice>>?
2. Extend RequestDeviceOptions with {multiple:true}?

I lean toward the first, since the second would require any call to requestDevice() to handle a sequence return value. On the other hand, the second is more consistent with <input type="file">.

[marcoscaceres]

I would also tend to lean towards 1. Overloading the return type of requestDevice()'s promise will probably be annoying for devs (as they would need to type check what they got back).

[jracle]

Agree with you @jyasskin and @marcoscaceres, I prefer 1.

[jyasskin]

I'm not likely to get to this soon, but I'll gladly take a pull request adding the requestMultipleDevices function.

[keybuk]

Most controllers don't support making multiple concurrent connection attempts to devices, instead you have to serialize them, waiting until the connection to one device is complete before you attempt the next.

I'm not sure this is an argument for requestMultipleDevices (handle the serialization for you) or against (request them one at a time like you're supposed to).

[jyasskin]

Thanks @keybuk. https://developer.chrome.com/apps/bluetoothLowEnergy#method-connect doesn't mention a need for developers to serialize their connection attempts, so I'm assuming the Chrome API handles the serialization for developers? I think I prefer that, since it's one less thing for web developers to get wrong.

[keybuk]

Actually we have a pretty big bug that we don't handle that case ;-)

[beaufortfrancois]

(gentle ping)

I've been playing with BLE juggling balls from juggglow and requesting several devices at the same time would definitely improve the overall UX.

I guess I could simply call requestDevice again for the second, the third one and so on. But I'm not sure we distinguish the ones that are already "paired/connected" to the website in the chooser UI.

[jyasskin]

Thanks for the use case! I think this is still lower priority than getting the rest of the basic functionality working, but that helps motivate it when we get to spec'ing it. Until then, yeah, you'll need to call requestDevice() multiple times, and unless each ball has a different name, it may be hard to figure out which ball to select next. :-/

[beaufortfrancois]

As you can see below, it's impossible to detect which ball to select next. I see two improvements there we could make from a UX perspective:

• Since current connected BT device is always displayed, we should at least highlight it:

https://example.com wants to pair with:
Jugglow	Connected
Jugglow
Jugglow

• If several devices have the same name, we could also add the device address next to it:

https://example.com wants to pair with:
Jugglow	12:34:56:78:90:12
Jugglow	34:56:78:90:12:34
Jugglow	56:78:90:12:34:56

[beaufortfrancois]

For info, the Permissions API just added navigator.permissions.requestAll().

Instead of overloading navigator.permissions.request(), .requestAll()
is a clearer name and will not confuse the authors with two different
return types.

Source: https://codereview.chromium.org/1426563003

[beaufortfrancois]

Using the Permissions API would make this trivial. See https://lists.w3.org/Archives/Public/public-web-bluetooth/2015Dec/0007.html

permissions.request({ name: 'bluetooth', filters: [{ name: 'Jugglow' }], multiple: true })
.then(result => {
  if (result.state != 'granted') {
    return;
  }
  // Let's try to connect to all devices...
  return Promise.all(result.devices.map(device => connectDevice));
});

function connectDevice(device) {
  return device.connectGATT()
  .then(...)
}

[nputhiyadath]

Is there any updates on this request? I am hoping this feature will be available soon as I want to scan and connect to multiple BLE devices and get notified from them.

[playground]

I'm also looking for that feature to be able to request and connect to multiple devices in one shot. Can it?

[selman-nus]

Hi, any updates? We want to read multiple wearables for sensor fusion purposes. @beaufortfrancois can you help me with any demos? Thank you.

[scheib]

No near term work planned to allow multiple device selection. Though some progress has been made for Scanning https://www.chromestatus.com/feature/5346724402954240 over the last year. There is also persisting bluetooth permissions work underway, which would help reduce the hassle of selecting multiple devices every time.

[immakermatty]

Hello! Any updates? We are working on a project with BLE controlled LED strips. We would love to be able to connect to multiple LED strips at once to control them from a web app. How should I go about it?

[reillyeon]

I have no updates on supporting multiple device selection however Chromium has published an intent to ship for the getDevices() and watchAdvertisements() methods, which will allow your project to reconnect to previously selected devices when the user returns to your app. We hope that this will mitigate the largest pain point when it comes to selecting multiple devices (that you have to do it every single time) as we consider future improvements to the device selection UI itself.

[colintbrown]

Hi! I'm working on an indoor location project involving ultra wideband ("UWB") transceivers ("Ts") - like indoor GPS navigation. Although the initial triangulation of the fixed, 'satellite', Ts (and the eventual triangulation of the moving Ts) is performed by UWB, the initial configuration is performed via Bluetooth. This can involve as many as 200 fixed Ts, although usually far less, so, multiple pairing would be a massive boon: any update on the ETA?

[scheib]

Chromium bluetooth implementation contributions continue, mostly from Google, though this specifically isn't planned 2023. We do notice comments here, thanks for sharing the use case details - that can help as an input to priorities.