A Tour of Web Capabilities

Web Bluetooth API

Maximiliano Firtman

Maximiliano Firtman

Independent Consultant
A Tour of Web Capabilities

Check out a free preview of the full A Tour of Web Capabilities course

The "Web Bluetooth API" Lesson is part of the full, A Tour of Web Capabilities course featured in this preview video. Here's what you'd learn in this lesson:

Max introduces the Web Bluetooth API, which provides low-level communication support with connected Bluetooth devices. The API can be difficult to use because instructions must be sent to devices in binary. Developers can find documentation with individual vendors or through third-party libraries built on top of the low-level APIs.


Transcript from the "Web Bluetooth API" Lesson

>> Now we're going to talk about external hardware and devices. I know what you're thinking, well, we have been already dealing with external hardware and devices, and yeah, that's true, but we have been dealing with, let's say, standard interfaces, standard protocols. But also, we have a way to be even more low level, such as connecting to Bluetooth.

Web Bluetooth is one of the APIs that, the first API actually that will let us communicate with a lot of hardware out there. Safari and Firefox are not implementing the API. It feels like they will never do that. I mean, no one knows, but there was a big discussion.

And I was part of the discussion, by the way, on social media with the Apple teams and the Chrome teams, I was in the middle, actually. And Apple said that they're not going to implement this because they feel it's a big security risk, and blah, blah, blah, blah.

The Chrome's team says that that's not the case, that is just imagination, blah, blah, blah. Anyway, we have Web Bluetooth only on Chromium-based browsers. And not even on all of them, Brave, for example, took that part off of Chromium. So if you're using Brave, you won't have Web Bluetooth.

Well, Web Bluetooth will, of course, let you communicate with Bluetooth devices. But not every Bluetooth devices, only BLE, that's Bluetooth Low Energy. It's kind of the modern Bluetooth world. I'm not sure if you remember Bluetooth devices 10 years ago, 15 years ago. I'm not sure if you remember that you have a handshaking, where you have to handshake one device with the other one with code.

Well, that was not Bluetooth Low Energy. And that Bluetooth can have more distance, low energy is only ten meters. But anyway, most of the modern small devices are Bluetooth Low Energy. I mean, my Apple Watch is low energy. So you can scan for devices. You can scan the services available on those devices.

And here comes the part where it will get really tricky. Web Bluetooth, Bluetooth in general, not just Web Bluetooth, Bluetooth, its complicated, the protocol is really complicated. So each device can expose services. The service has an ID. There are some IDs that are kind of standard, such as, I have a service of battery level.

So you can ask me about my battery, how is my battery? So that's a standard. Another standard service can be, for example, headphones. Another one, heart measurements for a heart sensor. So there are a couple. But for the rest, it's like any hardware manufacturer can create its own ID.

So what's the ID that you need to use to communicate with one particular Bluetooth device? You need to find a manual, you need to find a tool that will let you scan that device, or there are tools that will help you inspect a communication, like a proxy, sniffing into the Bluetooth communication to see what's going on.

And there are a lot of people in the community that are already doing that with a lot of well-known devices. For example, let me show you, there is a BB-8 drone, have you seen that one, by Sphero? And if you say BB-8 drone, for example, Web Bluetooth, Web Bluetooth, or even not Web Bluetooth, NPM.

You will find projects that already did the dirty job of analyzing the messages that you have to send to one particular thing. And then you can take it from there, okay? Yeah, of course, you need the hardware, but it's difficult to understand, and you will see an example now that I have here with me how complicated it can become.

Okay, so I'm not saying don't use Web Bluetooth, I'm saying that it's hard world, okay? It's not so simple as other web APIs, because Bluetooth is complicated, and it's not just services. So we have devices, each device is exposing services, it can expose more than one service. Then you can connect to those services, so there is a connection process known as GATT.

So you connect to the services, and the complexity doesn't end there. Each service can send and receive data through something known as a characteristic. So each service has different characteristics. Each characteristic, we have also a different ID. So then you connect to a service on a device, and then you can write data or read data to and from a characteristic that you also need to know the ID beforehand.

Some devices can expose the list of services, so I have this, this, and that. Some devices will have hidden services. So if you don't know the ID, you can't connect to it. It gets complicated. It's interesting but complicated. It's a very low-level API. So if you wanna connect to this little guy here through Web Bluetooth, you can.

But it's much better to use the gamepad API, even the WebHID API, okay? By the way, you cannot connect to some services. There are some services on the web that are restricted, for example, FTP, or for example, there is FTP over Bluetooth exists to send and receive files, and audio.

So you cannot connect to a Bluetooth speaker, microphone, or headphone, you cannot. I mean, the user can connect that to the OS, and then the website can use that as an external speaker or microphone, but you cannot talk low level to that service. So we need to also manipulate in JavaScript binary data.

So we need to understand how to create Uint arrays in JavaScript, how to manipulate bits and create that kind of data, if you like that. And we need to understand the devices communication protocol, as I mentioned before. This is how it looks like. So first, we request access to a device, so this is this part.

For example, I can request devices without no filter. If I do that, I will see a list of all the Bluetooth devices around me. Okay, or you can say, well, I really wanted a device with that name, or I want a device that is exposing this service. Instead of showing me all the Bluetooth devices out there, I can just see all the ones with the heart rate service, only those.

By the way, you cannot get the list as a developer, you don't get the list. So I'm saying request device with a filter, the user will see a UI, a dialog, the user will pick the device. For security reasons or for privacy reasons, your web app cannot scan the Bluetooth around you.

Makes sense? So we cannot receive the list by default, by default, at least. We request the device and then the user will pick one. When we have this device, we create a server that is a connection to that device, and we get the service with the ID. The ID can be a string or it can be a big number, a large number.

Then when we get the service, we get the characteristic of that service, and then we can receive data with a characteristicvaluechanged event, or we can write data to the characteristic, okay? It gets complicated.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now