What is Eddystone?

Eddystone is a Bluetooth advertising protocol (“packet”) designed by Google.

You can learn more about it on developers.google.com/beacons and github.com/google/eddystone.

What’s ahead (aka Table of Contents)

Eddystone & iBeacon comparison

  • While iBeacon is officially supported by iOS devices only, Eddystone was built with both iOS and Android in mind.

  • Eddystone is an open protocol, i.e., its specification is available for everyone.

  • The advertising packet is naturally different from that of iBeacon. In fact, Eddystone is designed to support multiple data packet types, starting with two: Eddystone-UID (and it’s secure Eddystone-EID variant) and Eddystone-URL. We’ll describe them in more detail below.

  • There’s a third type of packet: Eddystone-TLM, as in “telemetry.” This packet is broadcast alongside the Eddystone-UID or Eddystone-URL packets and contains beacon’s “health status” (e.g., battery life). This is mainly intended for fleet management, and because of that, the TLM “service” packet is broadcast less frequently than the “data” packets.

  • On iOS, iBeacon is consumed via iOS Location Services and the Core Location framework. Eddystone can be consumed via the Core Bluetooth framework.

  • On Android, both iBeacon and Eddystone can be consumed via Android Bluetooth API (i.e., the android.bluetooth.le package). Eddystone can also be consumed by Nearby Notifications built into Google Play Services.

Packet types


Eddystone-UID contains an identifier of a beacon. An app installed on the phone can use the identifier to trigger desired action, just like with iBeacon. Whereas the iBeacon identifier is composed of three parts: UUID, major number and minor number, and is 20 bytes long, Eddystone-UID is 16 bytes long and split into two parts:

  • Namespace (10 bytes), similar in purpose to iBeacon’s UUID. In iBeacon, you’d usually assign a unique UUID to all of your beacons to easily filter them out from other people’s beacons. In Eddystone-UID, you can do the same with the namespace.

    Estimote Beacons broadcasting the Eddystone-UID packet have a default namespace set to: EDD1EBEAC04E5DEFA017.

    For a custom namespace, the Eddystone specification recommends taking the first 10 bytes of an SHA-1 hash of your domain name. Here’s an example of how to do that using an interactive Ruby shell:

    # irb
    irb(main):001:0> require 'digest/sha1'
    irb(main):002:0> Digest::SHA1.digest('example.com')[0..9].unpack('H*').first.upcase
    => "0CAAF24AB1A0C33440C0"

    Tip: Estimote iOS SDK provides a convenient method that can perform the above transformation for you: ESTBeaconConnection’s writeEddystoneDomainNamespace.

    Another suggestion is to simply remove the three middle parts of a Version 4 UUID, e.g.: 8B0CA750-E7A7-4E14-BD99-095477CB3E77 becomes 8B0CA750095477CB3E77.

  • Instance (6 bytes), similar in purpose to iBeacon’s major and minor numbers, i.e., to differentiate between your individual beacons. With Estimote Beacons broadcasting Eddystone-UID, instance is represented as a string up to 12 characters long (e.g., 0BDB87539B67).


Eddystone-URL packet contains a single field: URL. The size of the field depends on the length of the URL.

The promise and purpose of the Eddystone-URL packet ties directly into the concept of Physical Web. Whereas with iBeacon or Eddystone-UID there’s a need for an app to take the beacon’s identifier and translate it into certain actions, with Eddystone-URL the data is encoded directly in the beacon’s advertising packet. This means that the user can access content—usually in form of a website—without the developer needing to build a native experience.

Remember that a Physical Web–enabled browser is needed to detect Eddystone-URL packets. Here’s some that we know of:

Note: Google removed Physical Web support from Chrome on iOS, and on Android, they’re transitioning the Physical Web notifications from Chrome to Nearby Notifications. Read their official comment on that matter: Update on Physical Web features in Chrome

Alternatively, you can build your own Physical Web browser, or use Google’s Physical Web scanner app (available on iOS and Android).

The URL could be a regular web page providing relevant information—e.g., a beacon next to a movie poster could broadcast a link to a YouTube trailer. It also could be a dynamic web application, with contextual parameters embedded in the URL—e.g., http://my-restaurant.com/check-in?restaurant_id=6523.


Eddystone-TLM packet is designed to be broadcast by the beacon alongside the “data” packets (i.e., UID and/or URL) for the purposes of fleet management. Nearby Bluetooth-capable devices can read these packets and relay them to a fleet management service—like the Estimote Cloud. This service can then notify the owner of the beacon that, e.g., the battery is running out.

The telemetry packet consists of:

  • battery voltage, which can be used to estimate the battery level of a beacon,
  • beacon temperature,
  • number of packets sent since the beacon was last powered-up or rebooted,
  • beacon uptime, i.e., time since last power-up or reboot.


Eddystone-EID packet is designed for security. The Ephemeral ID is seemingly random and can be resolved by requesting cloud resolver hosted by Google. Resolved EID will return description and attachments assigned to it using Google Beacon Proximity API or Google Developer Console.

EID protects you against two kinds of attacks:

  • Hijacking/Piggybacking - attack where third party application is using your infrastructure to deliver content to the users. Eg. One retailer using beacon network of the other to deliver their own promotions.
  • Spoofing - attack where third party creates a copy of the device used in your infrastructure to place it in different location. Eg. Copy of the beacon originally deployed in a store is placed in a bus.

Eddystone-EID only broadcasts the random identifier, and thus secures you against both spoofing and hijacking.

Configure Estimote Beacons to broadcast Eddystone

Every Estimote Beacon ever shipped supports Eddystone, you only need to perform an over-the-air firmware update and set them to broadcast one of the Eddystone packets. (If you need hardware to try Eddystone out and don’t have any Estimote Beacons yet, you can buy them here.)

  1. Update your beacons’ firmware to version 3.1.1 or later.

  2. Enable Eddystone-UID, Eddystone-URL, and/or Eddystone-TLM packets. Eddystone-EID is only supported by the Location Beacons.

    Keep in mind: Proximity Beacons can only broadcast one type of packet at a time, plus one telemetry packet (Estimote Telemetry or Eddystone-TLM). Location Beacons can broadcast all of the packets at the same time.

    Info: Legacy Proximity Beacons (hardware revision “D”) will automatically broadcast the TLM packet when you switch their broadcasting scheme to UID or URL.

You can use the Estimote iOS app or Estimote Android app to perform both of these actions.