Should `requestDevice` allow choosing more than 1 device? about web-bluetooth HOT 20 OPEN

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.

from web-bluetooth.

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

from web-bluetooth.

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(...)
}

from web-bluetooth.

(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.

from web-bluetooth.

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:

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

from web-bluetooth.

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.

from web-bluetooth.

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.

from web-bluetooth.

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">.

from web-bluetooth.

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).

from web-bluetooth.

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

from web-bluetooth.

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

from web-bluetooth.

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).

from web-bluetooth.

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.

from web-bluetooth.

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

from web-bluetooth.

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. :-/

from web-bluetooth.

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

from web-bluetooth.

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

from web-bluetooth.

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?

from web-bluetooth.

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.

from web-bluetooth.

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?

from web-bluetooth.