Thought’s on Google’s Bluetooth LE Eddystone and Cloud APIs

bluetoothGoogle announced their Eddystone open Bluetooth LE beacon protocol today and corresponding APIs to allow Eddystone (and Apple iBeacon) information to be stored in Google’s cloud to which arbitrary information (text, images etc) can be attached. Google have also introduced a Monitor Beacons API so that the health of beacons can be monitored. What does this mean for the cross platform (iOS and Android) developer?

The Beacon Hardware: First of all, existing iBeacon hardware won’t automatically work with (transmit data for) Eddystone. Bluvision, Estimote,, Radius Networks and Signal360 have already updated their beacons but these companies represent a small part of the beacon hardware market. As a small sample, the Bluetooth LE apps I have created for clients don’t use these beacons. Maybe other manufacturers will upgrade their beacons in time? Without Eddystone, Android (4.3+) can already sense iBeacons and infer distance so it might seem there’s no urgency to use Eddystone. However, from experience, I know the extra features provided by Eddystone, such as monitoring battery life, are really needed and are not gimmick – this itself might encourage demand for Eddystone. By the way, upgrading beacons will enable them for both iBeacon AND Eddystone, such they alternately transmit in each format, so it’s not a case of supporting one or the other (or having two separate beacons for each protocol).

The Cloud API: This is interesting as it’s free way of associating content with a beacon, irrespective of whether you are using Eddystone or not. Obviously, if you only store iBeacons then you won’t get the extra benefits of the health monitoring. Note that it’s only an API and not a web interface. You will still need to create your own web interface for your customers that, in turn, uses the Google cloud API to register beacons and map your business objects into the ‘arbitrary’ content to attach to a beacon. From there, it’s only a small extra step to also provide a device JSON API yourself. I am not sure yet why people might choose to use Google’s API other than to later participate in the upcoming changes to the Google Places API to make beacons globally visible – something that will probably benefit Google more than the information provider who in many (but not all) cases will usually want to keep the content in their own app(s).

Update: My assumption that upgrading beacons will enable them for both iBeacon AND Eddystone, such they alternately transmit in each format was wrong. The Estimote blog explains that while this is technically possible and “makes a ton of sense”, it isn’t legally possible if hardware vendors wish to remain officially iBeacon compatible as Apple “don’t allow other frames”. I now expect this to seriously limit the takeup of Eddystone as many companies still work on an iOS first basis. Solution providers will have to select iBeacon OR Eddystone. For cross platform solutions, using iBeacons will give better iOS background detection while using Eddystone will give access to beacon health information and future integration into Google Places.

Nov 2015 Update: Multimode beacons that sequentially send iBeacon and Eddystone are coming available.

Dec 2015 Update: The AnkhMaway iB001M also sends iBeacon and Eddystone at the same time.