Google Introduces New Open Format And Developer Tools For Working With BLE Beacons

Google today introduced a number of new products around Bluetooth Low Energy (BLE) beacons in an effort to challenge Apple’s iBeacon ecosystem.

These new products include a new open beacon format, tools and APIs for building apps and services on top of beacons, and a new developer-centric service for managing and monitoring large beacon deployments.

It’s no secret that Google has long been interested in Bluetooth beacons. About a year ago, we first heard about Google’s Nearby project, for example, which is also launching as an API today. While Nearby also uses other signals (WiFi, audio, etc.), BLE beacons are clearly at the center of Google’s efforts.

The first of Google’s new beacon products — and the cornerstone of its other initiatives — is the Eddystone format (named after an English lighthouse, in case you were wondering). This new format, which the company is releasing under the Apache 2.0 open source license on Github today, is meant to give developers a more robust and extensible way for working with beacons, as Google product manager Matthew Kulick told me earlier this week.

kontakt.io beaconGoogle has already worked with beacon hardware vendors like Bluvision, Estimote, Kontakt.io, Radius Networks and Signal360 to build the Eddystone format into their devices. The new format is completely platform agnostic (as long as the device supports BLE, it will support Eddystone) and any existing beacon can be made Eddystone-compatible with a firmware update.

On the API side, Google is launching two new APIs today for developers who want to use beacons for their apps. The Nearby API for Android and iOS now makes it easier for apps to find and communicate with devices and beacons that are — well — nearby. That may be an art exhibit or a bus stop (Google already worked with the transport authorities in Portland, OR to implement this).

The Proximity Beacon API then takes this a step further and helps developers associate a location and related data with beacons. That data is stored on Google’s servers.

Also new is Google’s new tool for beacon fleet management. “We want to make it easier to move from piloting your beacon-assisted apps to getting to scale,” Kulick said. When you use a lot of beacons in a stadium, for example, things quickly get challenging. Just getting access to the status of each beacon can be hard, Kulick noted. This new service sits on top of Google’s Eddystone telemetry framework and developers can then take this data and build their own services and dashboards on top of the data they get from this. For now, though, Google won’t offer it’s own dashboard. The company tells me it has no plans to charge for this service.

Google’s own products, of course, will also make use of this new technology. Google Maps users in Portland have been able to get beacon-based transit notifications since earlier this year and soon, Google Now will also be able to use this service to bring up contextual information, so when you are in a restaurant, you will be able to see the menu in Google Now, for example (though you should really, really put that phone down when you are in a restaurant…).