Category: Eddystone-EID

Google Beacon Platform Shutting Down

Google stopped serving Android Nearby Notifications late in 2018 but kept the Nearby API working for use within apps. Google has now deprecated the Nearby API that allows you to associate beacon ids with arbitrary content such as a link or multimedia data. It will be shut down on April 1, 2021.

No, it’s not an April fool joke but instead another useful thing killed by Google. Apart from Search, Cloud, Gmail and perhaps Android it’s risky to base your business on anything provided by Google. Unless it’s an offering through which Google itself depends for income then you can’t depend on it sticking around. Instead, businesses should look to create their own APIs.

This shows the easy route isn’t always the best route. Think about your project dependencies. It is likely the platform you depend on will exist for the lifetime of your project? How is the platform funded? How is the company that provides the platform funded?

Read about Trigger Data and Beacon Servers

Read about The Advantages of Generic Beacons

Eddystone-TLM

Eddystone-TLM is a data format defined by Google, using standard Bluetooth LE advertising, that can be detected on all receiving Bluetooth LE devices such as Android and iOS devices, desktops, laptops, Bluetooth gateways and single board computers such as the Raspberry Pi.

‘TLM’ signifies that it is providing telemetry of a device:

The battery voltage is in millivolts and defaults to zero if not supported by the device.

The temperature is in degrees Celsius using signed 8.8 fixed-point notation and defaults to -128°C if not supported by the device. For devices such as temperature sensor beacons, the TLM temperature is the System on a Chip (SoC) die temperature, not the temperature sensor for which you will need to decode a different advertising frame.

ADV_CNT is the number of advertisement frames sent since the device started and SEC_CNT is the time since device power up. These can be used to infer time and duration.

There’s no device identification in the advertising to uniquely tie the telemetry to a device so Google recommends:

TLM should be interleaved with an identifying (advertising) frame such as Eddystone-UID or Eddystone-EID

However, the additional advertising could equally be iBeacon. All Bluetooth LE receiving devices also receive a Bluetooth MAC address that is visible on all devices apart from iOS. For many sensing scenarios, an additional identifying advertising frame isn’t required.

View Eddystone Beacons

Is The Physical Web Dead?

Important: This web page is provided for historical purposes.

On 25 October 2018, Google announced they are discontinuing Nearby Notifications on Android. This mechanism should no longer be used.

Read about using Beacons for Marketing

There has been speculation that the Physical Web, as championed by Google, is dead.

Here’s what we know:

  • In October 2017, Google removed Eddystone URL from Chrome on iOS and Android.  Eddystone URL in Chrome on iOS wasn’t being used much and Eddystone detection had been moved to (and is still in the) the Android OS.
  • In November 2017, Google Nearby Beacon Functionality Was Severely Cut by Google. This is different to Eddystone-URL and relies on Eddystone-UID beacons being registered at Google. The result was that the Beacon Tools app only works with Eddsytone GATT beacons (not iBeacons).
  • There has been no activity in the Physical Web GitHub account for about a year. Google is no longer working on improving Eddystone. This is unfortunate because Bluetooth 5 presents lots of new opportunities that require evolution of the Eddystone standard.
  • In 2017, Scott Jenson, the person who brought the Physical Web to Google and became the Product Manager of the Physical Web team, moved to the Chrome UX team and since more recently moved to the Android UX team.
  • Very recently, Scott said “If there was still a Physical Web team, it would be fun to create these more semantic layers on top of the URL.” So, we now know there’s no Physical Web team and there probably hasn’t been since Scott moved teams.
  • The Physical Web Twitter account says “This account is no longer active”.
  • Despite Google moving away from active development of the Physical Web, they are still fixing problems. There was issue with the Physical Web proxy that was recently fixed where “issue triggered in the presence of an invalid URL beacon (ex: a non-HTTPS page) in the proximity of other valid beacons.”. This is reason why some scenarios might not have previously worked (and will now work).

In summary, while new development on Physical Web is dead, the mechanism still works and Google is still applying fixes. Google has removed some functionality that was rarely used and has disbanded the Physical Web team. However, Google is still maintaining the Physical Web proxy and Eddystone notifications still work on Android.

Meanwhile, a group of people led by Agustin Musi from Switzerland is contemplating creating PhysicalWeb2. There’s a Slack channel you can join or you can email them at contactus@phwa.io. There’s also a new site at phwa.io.

Read about using beacons for marketing.

Advanced BlueUp BlueBeacon Sensor in Stock

We now stock the BlueUp BlueBeacon Sensor. This is one of the most capable sensor beacons we know of with up to 8 advertising slots. It detects temperature, humidity and air pressure. It also supports Quuppa and Eddystone GATT Service.

The two AA batteries (included) last 3.5 years with default settings.

Google Nearby Beacon Functionality Severely Cut by Google

Google have quietly cut much of the usefulness of using Nearby with Beacons. The Google Beacon Tools app previously allowed you to register beacons that advertise an id (not URL), even iBeacon, associating the beacon with either a URL or an app so that Android users receive a notification when they come across a beacon.

The Android Google Beacon Tools app that is used to register Nearby beacons has had some updates. Google have removed the capability to register iBeacons and the app now goes into a provisioning state to connect to the beacon being provisioned:

The Android Beacon Tools app can now only connect to and provision Eddystone GATT service Eddystone-UID and Eddystone-EID beacons otherwise it then shows “Eddystone configuration service not supported by this beacon”:

The majority of beacons, not just ours, don’t support Eddystone GATT service. This severely cuts down the types of beacon that can now be registered with the Beacon Tools app (in our case only 7 beacons).

The Nearby programming API, that you can use to register Nearby beacons in your app, still declares it supports iBeacon so it’s still currently possible to register non Eddystone GATT service beacons but not so easily.

This is going to be a problem for organisations who have used Nearby as an alternative to Eddystone-URL. If they have been relying on the Beacon Tools app rather than using their API via their own app, they won’t be able to register more beacons. This puts them into the difficult position of needing to either purchase Eddystone-GATT Service beacons or write an app that uses the API. However, there must have been some reason to restrict Beacon Tools to only Eddystone Standard GATT beacons and this might, one day, also apply to the API.

To be clear, this doesn’t affect Eddystone-URL. Eddystone-URL never, and still doesn’t need, registration at Google.

Together with the recent removal of Eddystone-URL detection from Chrome for iOS, this sees Google distancing Eddystone from iOS and iBeacon from Android OS. Organisations can still write apps that scan for iBeacon or Android and Eddystone on iOS. However, for some unknown reason Google no longer wants to support this in their own apps and tools.

Paper on Using Eddystone Ephemeral-ID (EID)

There’s a recent paper by Debasis Bhattacharya Mario Canul and Saxon Knight of the University of Hawaii on the Impact of the Physical Web and BLE Beacons (pdf). The paper is based on a project that uses Eddystone Ephemeral-ID (EID). The paper is more a backgrounder and description rather than providing new insights. Nevertheless, it provides a useful description of some security issues with beacons that include tracking of beacon locations, forgery and showrooming.