Google Introduces New Open Format And Developer Tools For Working With BLE Beacons.
The search giant on Tuesday introduced a new format called Eddystone that lets electronic beacons provide more specific locations and other information within applications, the company said in a blog post.
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.Google on Tuesday announced Eddystone, an open-source beacon platform that may provide competition for Apple’s iBeacon standard used by some businesses and attractions, including Apple Stores. They’ve long been at the heart of the heady promises (or threats) we’ve heard about the Internet of Things: A subway can tell when the next train is coming! Register now for the 8th annual MobileBeat, July 13-14, where the best and brightest will be exploring the latest strategies and tactics in the mobile space.
Like iBeacon, Eddystone — an evolution of Google’s failed UriBeacon — will communicate with devices via Bluetooth Low Energy (BLE) to pop up information on compatible devices when they’re within close range. They’re little transmitters (usually battery powered) that send out information about a specific point of interest, and that info is then passively picked up by a smartphone or tablet in range of the transmitter. Eddystone, at its heart, is primarily a set of formats—agreed-upon standards for data transmission meant to simplify the cacophony of bits that beacons broadcast. Eddystone however is completely platform-agnostic, and Google has published Github resources as well two APIs for both iOS and Android, Nearby and Proximity Beacon. A beacon-equipped bus stop could send out transit times, stores could send promotions to the customers currently in the store, or a museum could send people information about the exhibit they’re standing in front of.
Using a low-energy Bluetooth signal, the software makes an iPhone’s proximity to certain items easier to track with the help of $10 signaling device beacons mounted on shelves and ceilings, each no bigger than a hockey puck. 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). To date, the widest implementation of these beacons has been Apple’s iBeacon tech, but now Google is entering the fray in a more serious way with an open standard it’s calling Eddystone (after the lighthouse, you see). 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. Google said it currently doesn’t plan to charge for Eddystone, and has already collaborated with Bluvision, Estimote, Kontakt.io, Radius Networks, and Signal360 to build the technology into their beacons.
Being an open source project, they wouldn’t want to name it “Google Beacon.” It fits in well enough with the other non-obviously-branded open source Google projects like Android, Chromium, or Dart. Also, the company wants to integrate the system in its Google Now service, which gives users contextual information around them before they need to search for it. 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. It differentiates itself from iBeacon by working with both Android and iOS, but it also seems to be more technically capable too: it can send URLs that can work with any app or just a web browser, for example, and make it easier for the company that’s deploying them to manage their fleet of gadgets.
Eddystone supports multiple frame types, allows versioning to make introducing new functionality easier, and works with any platform that can communicate with BLE beacons (including Android and iOS). They described Eddystone as a “robust, extensible” beacon standard. “We have been working with many of the ecosystem partners to figure out the actual use cases, and we realized that existing solutions only partially address what is being asked for. That vertically integrated scenario starts to fall apart when beacon-equipped physical locations want to court a wide range of developers, while protecting the privacy of users. Now retailers and the managers of other public venues can simply publish specifications for the data their beacons broadcast—and developers can build all kinds of apps they never envisioned. The need for this struck me when I thought back to South By Southwest Interactive, which experimented with beacons tied to the tech conference’s official app.
Last year, Buzzfeed discovered that 500 beacons had been installed in New York City phone booths, which turned out to have been installed to send deals related to the Tribeca film festival but nonetheless were a disconcerting discovery. For now at least, the company isn’t talking about using beacons to send contextually relevant ads to your mobile device. “Eddystone is an open, BLE beacon format so that manufacturers and developers alike can access, comment, and contribute to it,” a Google spokesperson told VentureBeat. “We don’t have any plans to monetize this. It’s called iBeacon!” Apple’s two-year-old iBeacon standard has a number of problems though, the main one being that it’s a proprietary standard that only works with iDevices. It’s meant for widespread adoption and establishing common ground for people to build upon.” While beacons are meant to be discoverable by any nearby Bluetooth device via a public signal, Eddystone features Ephemeral Identifiers (EIDs) that change frequently and allow only authorized clients to decode them (technical specs to be published “soon”).
It would have been far more interesting if SXSW had unleashed its community’s creativity—if it had a way to announce specs for its beacons and welcome in third-party developers. When you’re hoping to recruit companies to use this to advertise to their customers, immediately missing 50-80 percent of the possible customer base is a tough sell.
That’s why we’re trying to offer tools and services here at multiple layers of the stack.” Those layers include application programming interfaces (see our API explainer), which allow app developers to associate a beacon with a physical location (the Proximity Beacon API) and extract data from nearby beacons, like a bus stop or an art exhibit (the Nearby API). In contrast, Apple is so protective of iBeacon that when one company, Radius Networks, got iBeacon support up and running on Android, Apple contacted them and had the product shut down. Google isn’t creating dashboards or other management services for beacon deployments, Kulick said—which is good news for the growing number of startups that offer them. Instead, the tech giant is hoping that Eddystone formats will help those companies simplify the task of setting up and maintaining large beacon installations in public spaces like malls, stadiums, and museums.
Bluetooth beacons are one-way communications, so usually the goal is sending a notification that, when tapped on, will launch a more capable form of displaying or transferring data. “Because Eddystone is comprised of these different frame types, you’ll see different beacon vendors using Eddystone for slightly different purposes,” the Eddystone team told us. Universally Unique Identifier (UUID)—A UUID is a 128-bit value that separately identifies every specific beacon in the world, which an app can listen for and perform certain actions for. Google has partnered with beacon manufacturers including Bluvision, Estimote, and Kontakt.io, who are planning to support Eddystone. (Disclosure: Kontakt.io recently participated in Wearable World Labs, a startup accelerator run by ReadWrite’s parent company, Wearable World. The Starbucks app could be programed to listen for these specific beacons that Starbucks owns, knowing which store (and sometime where in the store) the user is at from the beacon ID in order to then do something—send coupons, connect to Wi-Fi, or whatever else you can think of (and have user permission for). It’s likely Apple will be reflexively hostile to a Google-backed initiative, so we may see Apple and Gimbal line up against Google and its Eddystone partners.
Google’s example is showing you menu items when you’re inside a restaurant, so given the fact that Google Now is embracing third-party apps, it’s easy to see how developers could one day leverage this integration. Eddystone’s frame formats allow beacon manufacturers to support multiple mobile platforms and application scenarios with a single piece of hardware. Businesses will be able to secure and manage their beacon fleet so they can validate their beacon-assisted apps and deploy beacons at scale (Google is hoping for not just transit stations, but bigger hardware installations like stadiums).
Even the company’s Physical Web project will be using Eddystone beacons to broadcast URLs that help people interact with their surroundings. “The best ideas won’t come from just one company,” Google has declared. Beacons often run on battery power, meaning the batteries need to be changed, so the telemetry frame type would send diagnostic data and remaining battery power to your friendly neighborhood IT person. If you’re going to make a beacon standard, you’re going to actually need manufacturers on board, and Google already has a several companies signed up to use Eddystone.
As for the big difference between Eddystone and the other beacon technologies, Wallace said, “The difference with Google… there’s some technical differences. There are the URL components, app support, and telemetry support.” Wallace told us that developers and companies won’t need a bunch of different boxes to support Apple and Google’s competing beacon standards. While Google is developing the beacon format, it is leaving things like beacon hardware, management software, and other solutions up partner companies like Radius Networks. The messages would quietly show up in your notification panel and could be swiped away if you weren’t interested (Apple’s beacon notifications in iOS are similarly passive, showing up in the lower-left corner of your lock screen when you’re within range of a beacon). On the client side, Eddystone support will be rolled into Google’s Nearby API which, along with picking up Eddystone’s Bluetooth LE signals, will implement the packet parsing, frame formats, and all the necessary reception “glue” to make the system work.
It seems that Google is again following the Android/Google Play Services model, where the platform is open source, but for the best experience you also need some proprietary bits from Google.