Google Eddystone™ beacon format
Give your users better location and proximity experiences by providing a strong context signal for their devices in the form of Bluetooth low energy (BLE) beacons with Eddystone™, the open beacon format from Google.
I found out today about a new Bluetooth LE beacon format that google have released called Eddystone.
The Eddystone format, like AltBeacons, is an open beacon format but allows the inclusion of additional data blobs with the beacon that can be updated once the beacons are deployed. A key part of this vision from Google is an integrated cloud based API’s that Google may well hope puts them at the centre of the growing beacon ecosystem.
The Eddystone format includes new data payloads as part of the beacon data
- Eddystone-UID: An opaque unique ID.
- Eddystone-URL: A compressed URL that, once parsed and decompressed, is directly usable by the client.
- Eddystone-TLM: A block of telemetry information containing beacon status and runtime values.
Once you get the new data… what next?
The concept seems to be that once you read the Eddystone-URL you can use this to contact the google hosted cloud based Proximity Beacon API that then stores additional data about the beacon. e.g. Latitude, Longitude, Shop floor etc.
The Proximity Beacon API is a REST API so while I’ve not had a go yet, should be very simple to work with using the REST components in RAD Studio that I covered in my last post about integrating with the Azure Translation Services
The Proximity Beacon API allows you to:
- Register beacons
- Publish attachments to beacons
- Retrieve attachments
- Monitor beacons
Eddystone is available today.
All in all – this new standard seems to be a step forward for the usability of beacons from my initial glance. With the REST components and Bluetooth LE components already in place within RAD Studio I look forward to having a play in the future with the new beacon format.
You can find out more about the new bluetooth beacon open standard at