Get Ready for Web Bluetooth

June 14, 2017 0 Comments

Get Ready for Web Bluetooth



What if you could dim your lights right from your browser, just by pairing with your nearest Bluetooth-enabled Hue or Lumen light bulb? Wouldn’t you be just that much more productive? What about connecting to your LED Smart Rope to manage a workout even while offline, right from your browser?

With the new Web Bluetooth API now available in Chrome Browsers 56+ and Opera 44+, as well as more recent Android browsers, the world of connected devices just got a little closer to realizing the promise of the Physical Web: “Walk up and use anything”.

What’s Web Bluetooth?

Web Bluetooth is a new API provided to allow interacting with devices from the web. Open a browser, pair with a nearby bluetooth device, and manage it remotely. You don’t need to be online to connect to a local device. Just ensure that your computer has bluetooth enabled:

Bluetooth itself has been around since 1994 when it was invented by Ericsson as a ‘wireless alternative to cables.’ It’s essentially a standard way for devices to wirelessly interact with each other over a short range. Interestingly, it was named after the Viking Harald Bluetooth who was instrumental in uniting feuding Danish tribes; Bluetooth was seen as a way to unite disparate communications protocols, eventually allowing mobile devices to communicate with computers.

There have been several versions of the Bluetooth protocol, and the one of particular interest to us is “Bluetooth Smart” or “Bluetooth Low-Energy” (BLE). BLE was initially proposed by Nokia as an alternative to standard Bluetooth in 2001. It was intended to consume less power, but retain the core Bluetooth technology. As “smart devices” needing this type of low-energy technology began to be introduced to the market in the early 2000s, this new protocol was merged with the Bluetooth Core by 2010, and was introduced into smart phones with the iPhone 4S in 2011. (source)

Google has been instrumental in promoting the consumption of signals sent by BLE devices as a new web technology which debuted in 2015 on Chrome-enabled devices:

A subset of the Web Bluetooth API is available in Chrome 56 for Chrome OS, Chrome for Android M, and Mac. This means you should be able to request and connect to nearby Bluetooth devices, read/write Bluetooth characteristics, receive GATT Notifications, know when a Bluetooth device gets disconnected, and even read and write to Bluetooth descriptors.

In Chrome 56, released in January 2017, the Web Bluetooth API was fully enabled in the browser after a two-year trial. It specifically uses the GATT protocol, a hierarchical data structure of Generic ATTributes that is exposed to connected BLE devices so that services, characteristics and their descriptors can be discovered and then used – in our case, on the web.

A GATT Service might be, for example, a Battery Service with specification type org.bluetooth.service.battery_service. This Service in turn exposes the characteristics Battery Level: org.bluetooth.characteristic.battery_level which returns a percentage of battery life: org.bluetooth.unit.percentage. Many services and characteristics are listed here; you can even submit your own idea here of a characteristic that is missing that you’d like to add. On the web, you can leverage these characteristics to both read and write to your connected devices via bluetooth.

Windows user? Web Bluetooth is now also available on Chrome with the latest version of Windows 10, using a polyfill created by Uri Shaked.

A small but enthusiastic community has been pushing forward to build on top of this API, creating lots of fun projects. François Beaufort, very active in this space, keeps this page updated with the latest releases. While Chrome has been pushing forward with integrating Web Bluetooth, we can hope that other browsers will follow suit. In the meantime, however, there are a few options for developers on which to fall back which I discuss below.

Beacons, again

Are you tired of me ranting about beacons? Well, sorry to say here we are again. I like beacons, but it does actually seems a little strange to be pairing (see what I did there) the little beacons that you can scatter around an indoor location to notify you about cool nearby things, with an article on Web Bluetooth. After all, most of the time, when we’re in a web browser, we’re on a laptop, and not wandering around searching for things in a greenhouse or a museum. But beacons offer a great use case for Web Bluetooth.

Quick review: iBeacons, initially proposed as a proprietary protocol by Apple, emit UUIDs, but Google’s Eddystone beacon is more interesting for extensibility as it emits either UUIDs or a valid URL. You thus don’t need a specially designed app installed to consume the signal emitted by an Eddystone beacon – you can just open a web page.

Since the Eddystone protocol allows Eddystone-enabled beacons to emit either a URL or a UUID, it’s a perfect way to push content towards a passerby, via a web-friendly URL. Beacons, in addition, have been welcomed with somewhat open arms into the mobile space by means of the Physical Web, which, quite amazingly, was introduced first for iOS via Chrome. The Physical Web, in fact, can function as a fallback when the default browser on a mobile device doesn’t support Web Bluetooth. Let’s learn a little more about this option.

Web Bluetooth vs the Physical Web

The Physical Web, on which I have spoken and written earlier, is an open standard being built in an attempt to codify the way Eddystone beacons interact with mobile devices. It relies on the use of Physical Web Clients on iOS and Android; right now, you can use the ‘Today Widgets’ on iOS and the ‘Nearby’ Google integration on Android to pick up local beacons.

On an Android phone, select Settings > Google > Nearby to enable this feature. While normally you would use beacons to broadcast Physical Web URLs, you can also broadcast these URLs right from your computer or your mobile phone. There’s even a cool desktop app to make this super easy, right from your Mac! Your users do need to be online to receive Physical Web URLs, and on Android they’ll also need to enable Location services.

On iOS, with Chrome installed, swipe down from the top and add the Chrome widget to the Widget screen. Enable the Physical Web in the Chrome tab, and start listening for beacon signals.

The Physical Web, then, is pretty well integrated into the iOS experience via the Today Widget – although it’s still a bit of a challenge to get it installed and up and running. On Android, the beacon signal is quickly picked up as long as you have Nearby and Location enabled.

But what if your users aren’t quite ready to do all the installations and configurations to interact with your beacon fleet? Swipe here, click there, install the other thing…who has time? Here’s where the value proposition of Web Bluetooth, integrated into web browsers, really shines – imagine if you could simply point your users toward a lovely web site associated with your venue and as a visitor approaches an item of interest, she or he could press a button and interact with a beacon right from a web page. On Android, today, that is possible!

Also, on iOS, there are folks in the Web Bluetooth community who are tired of waiting for Safari and Chrome to catch up, so they have rolled their own Web Bluetooth enabled browser, although it’s yet another paid download for your poor iPhone:

What’s the use case?

Having already beaconized a greenhouse and spoken about putting beacons in museums, it struck me that one thing I haven’t attempted is putting beacons in a large historical site. Luckily, I live in Boston, which is crammed with historical sites! My own town of Wellesley has houses right next door that were part of the Underground Railroad. Sylvia Plath used to live here, as did Katharine Lee Bates. There are several important colleges to explore and cemeteries with tombstones that predate the Revolutionary War (wouldn’t it be great to beaconize a cemetery, and get information on who’s buried here?).

I was inspired to beaconize a larger area after a visit earlier this year to Montreal, which is celebrating its 375th anniversary this year. Their Montreal375 app includes a cool concept of local check-ins; visit an event or location, check in, and get points for prizes. It’s based on GPS location, but I liked the idea of earning credits for performing local actions.

I decided to place beacons on the famous Lexington Battle Road, part of the National Park Service and the place where the first military-to-militia shots of the American Revolution were fired. Every April, you can go there to watch a re-enactment of the Shot Heard Round the World on Patriot’s Day, right before the Boston Marathon. It’s a very interesting place with many preserved homes that witnessed a lot of history. Follow the “battle road” to see how the local militia took pot shots at the British, falling back strategically in what was essentially guerilla warfare against a well-organized colonial army:

I bought beacons, configured them to correspond to web pages, and built a web site nicely themed for the location which you can visit here:

Note, URLs for beacons need to be secure, and Firebase hosting gives you a site behind https so it works really well. Also note, use a URL shortener when saving a URL to a beacon, due to bluetooth limitations.

The content is stored in Firebase on the backend, and each locale’s web route corresponds to the name of a beacon: The North Bridge, beacon 1, sends the user to where you can “check in” to your locale. Kendo UI Charts make the “Progress” page look great:

The site includes an Admin tool as well to configure the site’s beacon fleet. Using Web Bluetooth, you can pair with a beacon and set, or reset, the URL it will emit:

A note about security: you’ll have noticed that the URLs in my demo have no protection and could be accessed by anyone who knows the address, without using a beacon. Obviously in a production scenario, you’ll want to redirect users who come to your internal URLs ‘illegally’. Also you may want to secure your beacons with a password to make sure other people don’t connect to them and reconfigure them. You can do that by setting a password on the Espruino chip.

Architecting the site

To build this web presence and configure the fleet of beacons, I relied on the great work of Uri Shaked and Wassim Chegham, both members of the Angular community with fantastic examples of building on the concept of “Angular Everywhere” – not just on the web, but on the Internet of Things. Uri has progressively built up his project, ngBeacon, until it’s production-ready. These are beacons that he builds by hand and configures by loading them with Espruino, a chip with an embedded JavaScript engine perfectly suited for tinkering beacons and bluetooth – so these beacons run JavaScript!

To configure your beacon fleet, Uri has also built a ready-made admin site that I forked for my website and simplified to configure my fleet of beacons with a name and a URL. Uri’s ‘super-beacons’, of course, do much more than simply emit Eddystone data; they can also emit iBeacon UUIDs and can function as temperature and humidity sensors as well. I particularly appreciate the switch that allows you to switch off the beacon to conserve the little coin battery – better than my original Estimote beacons which have to be dismantled to change the battery.

today, the first ng-beacon was created! #AngularOfThings
— Uri Shaked (@UriShaked) January 15, 2017

To build web sites that interact with Web Bluetooth, we all turned to our favorite method of crafting sites, the Angular CLI. In addition, I used Angular Fire to connect my Angular app with Firebase for an easy-to-use database. I included the new Kendo UI Angular charts as well, as I mentioned above, but I needed one more magical tool to connect my beacons to my web presence.

That tool is Wassim Chegham’s Angular-Bluetooth module. This library allows the Angular developer to interface cleanly with connected devices, reading and writing to sensors. Thus my service to connect to a beacon with one button click looks like this:

import { Injectable } from "@angular/core"; import { BluetoothCore } from "@manekinekko/angular-web-bluetooth"; @Injectable() export class BeaconService { constructor(public ble: BluetoothCore) {} getDevice() { // call this method to get the connected device return this.ble.getDevice$(); } } 

Then, once I connect to a device, I can start reading its emitted values. For my use case, I simply need to get the device name and navigate to its corresponding route.

getDeviceStatus() { this._beaconService.getDevice().subscribe( (device) => { if(device) { //get the name console.log( this.router.navigate(['/locale',]); this.device = device; } else { // device not connected or disconnected this.device = null; } } ); } 

Using these few lines of code, with your fleet of beacons and an appropriate browser (let’s face it, you’re going to need Android for now), you can walk up to “Parker’s Revenge” on the Lexington battle road historical site, find a beacon, scan for it from the affiliated web site, connect to the beacon and then to the appropriate web content, and check in. No more special downloadable apps, searching for ways to enable the Physical Web…just enable bluetooth and visit a web site. The barrier to entry between your users and your content just got a little lower.

Think how much firepower you just added to your web site!

You can use any type of Eddystone beacon, configured to emit the URL of your choice, and get your web pages to pair with it via Web Bluetooth. We can hope that better browser implementation will gradually make its appearance. What are you building with your beacons? Let me know in the comments!

I’m grateful for the help of Uri Shaked in the preparation of this article, and for his beautiful ng-beacon project with all the accompanying software. Because of his superlative soldering skills, I’m ashamed to pick up that iron again 😍. Thank you as well to Wassim Chegham for the really helpful Angular-Bluetooth library.

Tag cloud