iBeacon, Eddystone, Bluetooth, IoT sensor beacons, apps, platforms
The short answer is no, iBeacons cannot directly send users to a website. iBeacons do not have the capability to push content or URLs to devices automatically. Instead, they rely on compatible apps to detect their presence and take appropriate actions which can include sending the user to a web site.
There used to be a mechanism in Android that used the Eddystone-URL advertising format but this has since been discontinued by Google.
In the early days of Bluetooth beacons, many businesses were excited about the prospect of sending unsolicited messages directly to people’s phones as they walked by. This was once possible through the Google Nearby service, a feature that allowed notifications to be sent to users without the need for an app. However, in 2018, Google shut down the Nearby service, effectively ending unsolicited beacon messaging. Since then, the way we interact with Bluetooth beacons has evolved significantly.
Today, if you want to notify users through a beacon, you need an app. This app must be capable of detecting nearby beacons and presenting relevant information to the user. For businesses and developers, this means you have a few options. You could modify an existing app to detect beacons, create a new app from scratch, or use a third-party app specifically designed for this purpose such as CliqTags.
CliqTags offers two versatile app, CliqTags Nearby and CliqTags Spotter, that help businesses use the power of Bluetooth beacons:
CliqTags Nearby: Simple, Seamless, and Independent
CliqTags Nearby is an app that uses the Eddystone-URL advertising format to detect beacons and display site information directly to users. Unlike Google’s old Nearby implementation, CliqTags Nearby fetches information directly from the site, making it a seamless and independent experience. Users can click the button to visit the site directly, without relying on any external services, not even CliqTags. The app is available for free on both Google Play and the Apple App Store, and it can be private-branded and customised to meet specific business needs.
CliqTags Spotter: Advanced Functionality with iBeacon Technology
CliqTags Spotter takes things a step further by using iBeacon technology. When an iBeacon is detected, the app communicates with the CliqTags server to translate the iBeacon ID into a corresponding website. One of the standout features of CliqTags Spotter is its ability to reconfigure beacon IDs over time, allowing different content to be associated with the same beacon. This flexibility extends to geofencing, providing a level of control that businesses can manage via the CliqTags server. Due to its complexity and customisability, CliqTags Spotter isn’t available in app stores. Instead, it’s offered as a private-branded solution tailored to the specific needs of businesses.
iBeacon, a standard developed by Apple, was introduced in 2013 as part of the iOS 7. It’s based on Bluetooth Low Energy (BLE), a power-efficient variant of Bluetooth technology. The strength of iBeacon lies in its background support on iOS devices, which allows for easier detection of beacons.
Google introduced Eddystone in 2015. This protocol for beacons was developed to embrace a broader range of uses. Eddystone offers multiple frame types to cater to various data needs like URLs, unique identifiers and sensor data. One most distinctive feature of Eddystone was the Eddystone-URL, where the beacons could send out a web address. However, this has been limited by the discontinuation of Google Nearby in Android.
Despite the differences in their design and features, both iBeacon and Eddystone share common ground in their use of standard Bluetooth advertising. They send different data in the same standard Bluetooth advertising packets. This shared aspect of technology ensures that they can both communicate effectively to both iOS and Android.
While Eddystone’s versatile frame types and open protocol initially made it appealing, it has seen a decline since the discontinuation of Nearby in Android. Currently, most new systems requiring smartphone applications to detect a beacon opt for iBeacon.
However, when it comes to locating and detection using gateways rather than smartphones, iBeacon vs Eddystone becomes less relevant and the beacons’ Bluetooth MAC addresses are usually used. The advertising packets can instead be used for sensor data, for example, temperature and humidity.
View iBeacon Beacons
View Eddystone Beacons
View Sensor Beacons
Bluetooth beacons are tiny devices that transmit small amounts of data over short distances using Bluetooth Low Energy (BLE) technology. They can operate with different protocols, like iBeacon (developed by Apple), Eddystone (developed by Google), and various sensor beacon protocols.
Despite the fact that it might seem these beacons can advertising multiple protocols simultaneously, it’s not quite the case. What they actually do is advertise these protocols one after the other in a very rapid sequence. This is due to the way Bluetooth works; it’s not technically possible to transmit multiple signals at the exact same moment. Instead, the beacon switches between the different protocols very quickly, which to a casual observer, or a smartphone, might seem simultaneous.
This rapid succession is made possible by BLE’s advertising mechanism. Beacons, in their idle state, continuously broadcast their identity, and potentially other information, in what’s called ‘advertising packets’. When they’re configured to use multiple protocols, they broadcast an iBeacon packet, then an Eddystone packet, then a sensor beacon packet, and so on in a cycle. This is repeated at a very high frequency, many times per second.
However, while this flexibility is advantageous in certain scenarios where various beacon protocols are required, it’s not always necessary and drains the beacon’s battery more quickly. This is because each advertising event consumes energy, and broadcasting in multiple protocols effectively multiplies the number of these events.
Many beacons are set up to advertise multiple protocols by default. If you don’t need this functionality, you can optimise battery life by disabling unnecessary protocols. This is done using a manufacturer-provided app. The exact process can vary between manufacturers and beacon models, but it generally involves connecting to the beacon, accessing its settings and then deselecting the protocols you don’t need.
While multiple-protocol advertising can be useful in certain situations, it’s often more battery efficient to only use the specific protocols you actually need for your application.
There are lots of brands of iBeacon and Eddystone beacon. Each brand has its own management app. We have often been asked,
“Is it possible to have just one app to manage different brands of beacon?”
While it’s technically possible, there’s no incentive for anyone to create such an app. Creating just one app to manage one beacon brand, across iOS and Android is significant effort in itself.
Google identified this problem and created the Eddystone Configuration GATT Service. The idea is that if manufacturers used just this, apps and beacons would be inter-operable. However, people want to configure iBeacon as well as Eddystone. Manufacturers also want to allow users to configure and read sensor data. Also, using Eddystone Configuration GATT Service software in all future beacons does nothing to help manage the large number of beacons that are already out there.
As of writing this, in 7 years since Eddystone Configuration GATT Service was published, no apps have been published that work with the Eddystone Configuration GATT Service. However, the Nordic nRF Connect app does understand some of the Bluetooth Characteristics to better read these kinds of beacons. There hasn’t been a rush for manufacturers to use Eddystone Standard GATT.
Back to the question. It looks like there will be a separate app per manufacturer for the foreseeable future.
Eddystone-URL is a format for Bluetooth Low Energy (BLE) beacon advertisements. It is an open format developed by Google and designed to be transmitted by beacons to nearby devices, such as smartphones and tablets. The format allows beacons to broadcast a URL which can be used to direct users to a specific web page.
In other words, Eddystone-URL is a way for ‘things’ with attached beacons to communicate with nearby devices and provide them with a link to a webpage. This can be used for a variety of purposes, such as providing location-based information, coupons, or other types of content to users. It can be used in a wide range of applications, including retail, transportation and tourism.
Eddystone-URL works by broadcasting a URL in a Bluetooth advertisement packet. When a device with a compatible BLE receiver, such as a smartphone, comes within range of the beacon, it can receive the advertisement packet and decode the URL. The user can then open the URL in a browser on the device.
An app is needed on iOS and Android such as Beaconstac NearBee, the Physical Web Association app or your own custom app. If you create your own app, consider using iBeacon instead of Eddystone URL advertisements for easier processing on iOS (also works on Android). The iBeacon ids can be mapped to URLs in the app. This is often better because the mapping can be changed, for example on a server, rather than having to physically access the beacon to change the URL.
Need to decode a Bluetooth advertising packet? reelyActive have an online web form that decodes wireless advertising packets:
It’s also open source so you can use the code in your own projects.
As previously mentioned, we perform signal strength and stability tests across beacons. The data feeds into our consultancy work. Here are some high level observations.
The following graph shows the standard deviation of the RSSI @ 1m, for some of our beacons, measured over a 60 second time period:
Smaller bars are better and represent beacons
whose RSSI varied the least over time.
We found that beacons belonged to one or two groups. Firstly those with very stable RSSI and secondly those with an RSSI that had a standard deviation between about 4 and 6 dBm.
Signal stability is more important when you are using the RSSI to infer distance, either directly from the RSSI itself or indirectly via, for example, the iOS immediate, near and far indicators. RSSI varying without a change of distance might cause more spurious triggering. However, you should keep in mind that environmental factors can often cause variation much larger than the 4 to 6 dBm found in this test. Moving obstacles, for example people, will cause significant variation in RSSI.
Bluetooth LE advertising moves pseudo-randomly between radio channels. The channels use different radio frequencies that, in turn, results in fading of the signal at different distances. We experienced and mitigated similar behaviour in our LocationEngine™. Different radio frequencies experience different constructive and destructive interference at different physical locations. Beacons that move more between channels can cause more rapidly varying received signal strength (RSSI).
There’s new research by Department Computer Science, Universidad Técnica de Machala, Ecuador on Design and Practical Evaluation of a Family of Lightweight Protocols for Heterogeneous Sensing through BLE Beacons in IoT Telemetry Applications.
The researchers explain how standard beacon advertising works and documents the existing iBeacon and Eddystone protocols.
New protocols, LP4S-6 (for resource-constraint beacons), LP4S-X (for more powerful beacons) and LP4S-J (for beacons able to run complex firmware) are proposed that can be used to allow IoT telemetry systems to discover new nodes and to describe and auto-register the sensors and actuators connected to a beacon.
The paper describes the resultant JSON, shows how a new protocol can be added to an Eddystone beacon and proves how the new latency and power consumption remain low.
Note that updating the firmware of a beacon is non-trivial because it requires the implementation of what’s already on the beacon without access to the original source code.
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?