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 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
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 email@example.com. There’s also a new site at phwa.io.
Read about using beacons for marketing.
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 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.
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.
Google has just open sourced firmware that implements Eddystone on Nordic nRF SoC beacons. Their aim is to get wider distribution of Eddystone beacons and also encourage other devices, for example vending machines and remote control toys, beyond just beacons. This open source release is intended for manufacturers rather than end users. However, hobbyists might also use the software to re-program currently available Nordic-based beacons.
By providing reference software, it should make it easier for manufacturers to support Eddystone. Also, as this implements the Eddystone Configuration GATT Service, beacons using this software will also be configurable via the Web Bluetooth Configuration Page. The standard GATT Service also allows common configuration apps to be used such as the Nordic nRF Connect app rather than having to rely on specific manufacturer configuration apps.
So far, take up of the Eddystone Configuration GATT Service by manufacturers has been slow. Only one of our manufacturers, Sensoro, supports the Eddystone Configuration GATT Service and when you use this mode iBeacon and all Sensoro-specific features get turned off. This is the problem for manufacturers. Not many people want Eddystone-only beacons so manufacturing them is currently a low volume specialist edge case for manufacturers. Also, while Google is trying to standardise firmware and configuration, the higher profile beacon providers probably think it’s in their interest to continue with proprietary features that lock users into using those particular features and their particular platforms.
UPDATE: We now stock a version of the i7 that supports the Eddystone GATT Service.
Sensoro have very recently changed the way they enable Standard Eddystone. First, an explanation of Standard Eddystone. This is when a beacon supports Google’s Eddystone Configuration GATT Service. Our previous comments, from the time this service was announced, provide more background information. Instead of Standard Eddystone, most beacons, including Sensoro beacons, have their own custom Bluetooth GATT service that can still support Eddystone (URL, TLM and EID).
The Sensoro configuration app used to have an option to convert the beacon to Standard Eddystone. This was a one way process that caused the beacon to no longer able to be managed by the Sensoro configuration app, disabled iBeacon support and Sensoro’s cloud features. Unfortunately, some of our customers didn’t realise they could use Eddystone with the Sensoro GATT service, saw ‘Switch to Eddystone’ and did the change with a loss of many features. We fed this back to Sensoro and they have listened. They have removed the switch in the configuration app. It’s now performed with a separate app and you can also now switch back to the Sensoro GATT service. The Android version of the Switcher app had a few critical bugs that we have also now resolved with Sensoro.
More details on switching are available in the Sensoro Technical area available to BeaconZone customers.
People often ask us what’s best for their project: iBeacon or the Physical Web? While there are pros and cons for both options, sometimes the most important one is whether the user is likely to have Internet connectivity.
The Physical Web relies on the phone’s Internet connection to first talk to the Google proxy to get icon, title and description information about the Physical web URL and then later fetch the URL in the phone’s web browser. If there’s no Internet connection there will be no notification. This is, in fact, one of the problems people often come across when they are first testing the Physical Web and ask why they get no notification. In real use, there are several situations that can cause no or poor Internet connectivity. These include being indoors or an International visitor roaming. Both these are common in visitor space scenarios.
We have worked on several visitor space-type scenarios and have found that they are better served with an app and the use of iBeacon or Eddystone-UID. The app can arrange to have the beacon to data mappings and the data itself pre-loaded either as part of the app install or previously synchronised, manually or automatically, when the app was installed or when there was connectivity. This provides for a system that can trigger notifications and show data when there’s no Internet connectivity.
Google’s evolution of the Phsical Web over time and emphasis on latest features in documentation is still confusing new users. Eddystone-URL and Google’s server based Nearby are two separate things.
For Eddystone-URL you set the URL in the beacon (usually also needs a URL shortener and must have SSL for the final URL) and that’s it. As mentioned in our description of Nearby, beacons advertising Eddystone-URL can’t be and don’t need to be configured at Google. You don’t need to use the Google Beacon Tools App. Nearby in the Android OS (in Google Play Services) will see the URL if the user hasn’t disabled Nearby. Chrome on iOS will fire notifications.
For Google’s server based Nearby services, you register Eddystone-UID, Eddystone-EID or iBeacon at Google at associate it with a URL or app. We have a walkthrough.
Most implementations can use Eddystone-URL and don’t need beacons to be registered at Google. Your beacons will still be shown via notifications created by Android OS. On iOS they will need to be detected via the use of Chrome.