Yesterday Google announced ‘Eddystone’, a new open Bluetooth beacon format which works on Android and iOS. I’ve been doing a bit of reading about it to understand the technology and its potential, and I put together a briefing note about it for my colleagues. I’m a believer in maximising returns on my content, so it seems like a good opportunity to republish that briefing note here.
This is a very rapid and shallow look into beacons, and I’ve no doubt made some omissions or inaccuracies, so apologies in advance for that. If you think I’ve made any huge oversights or errors, please feel free to let me know in the comments.
In a Nutshell
Eddystone is, as mentioned, an open Bluetooth beacon standard. It works on Android and iOS. It does all that some current formats – namely iBeacon and Physical Web – do, plus more. It comes with associated APIs and libraries that make it very extensible and powerful.
Although this is a Google-led initiative, they very much want this to be seen as an open standard. So the branding is just Eddystone, without mention of Google. Fun fact: It’s named after the UK’s Eddystone Lighthouse.
Anything based around immediate location. Google have recently run a project around live transport information in Portland, and are talking about pushing hyperlocal information into Google Now. Think about beacons in shopping centres, museums, art galleries, markets… anywhere you need passive information about the things immediately around you.
Comparing Format Standards
- iBeacon is an Apple-only standard which transmits a single Unique Identifier (UID). Apps can use this to trigger an action.
- Physical Web Google-led open initiative which transmits a single URL. Apps can present this to the user or look up related information from metadata.
- Eddystone Google-led open initiative which combines features of both, plus more. Has a UID, a URL, plus Ephemeral Identifier (EID) and Telemetry (TLM) data – details on these below.
Here’s a quick comparison:
|Physical Web||URL||Android, iOS|
|Eddystone||UID, URL, EID, TLM||Android, iOS|
NB: Physical Web will continue as an initiative, but using Eddystone’s URL as a foundation instead of its own UriBeacon format.
As mentioned above, in addition to the UID and URL there are two payload features unique to Eddystone:
- Ephemeral ID is an ID which changes frequently and is only available to an authorised app, not broadcast generally. It’s intended for short-term use; the use cases mentioned are for finding luggage when travelling, or finding lost keys.
- Telemetry is data about the beacon or attached sensors: e.g. battery life, temperature, humidity.
Along with Eddystone, Google announced a handful of new / extended APIs:
- Proximity Beacon associates beacons with data in the cloud, allowing for very rich information, including latitude and longitude co-ordinates, and an association with the Places API (similar to Facebook BLE Beacons).
- Place Picker is an extension of Places, showing beacons / places in your immediate vicinity.
- Nearby uses a combination of Bluetooth, WiFi and ultrasound to make it really easy for devices to find, and communicate with, each other.
Although Eddystone requires these Google APIs to be useful at the moment, the fact that it’s an open standard means that anyone will be able to make open alternatives in the future.
iOS devices require an extra library to work with Eddystone.
The Bigger Picture
Eddystone is part of Google’s push further into the ‘Internet of Things’. These also include:
- Brillo, a lightweight version of Android for low-powered devices;
- Weave, a secure home devices protocol for device-to-device or device-to-cloud communication; and
- Thread, an alternative to Bluetooth for direct communication (not a Google project, but they are a member of this consortium).
Unlike iBeacons, which must be approved by Apple, anyone can make an Eddystone-compatible beacon. Current beacon manufacturers include Estimote, Kontakt and Radius Networks.