There are some posts on Twitter and articles talking about how Eddystone appearing in iOS Chrome’s Omnibox might transform proximity notification scenarios. So what is this and what does it look like?
This came about due to the Physical Web/Chrome teams experimenting with new ways to show Eddystone notifications:
At the moment, notifications appear at the end of the ‘Today’ view. They get a bit lost because you have to swipe down get the notifications, swipe left and then scroll to the bottom:
BeaconZone Eddystone notification at the bottom
Noone is going to see this unless they know it’s there and are trying very very hard. Even though Eddystone detection is designed to be ‘pull’ rather than ‘push’, it’s a bit too difficult to find local Physical Web beacons.
With Google’s experimental Omnibox implementation, beacons come up when you go to do a Chrome search. At the moment, to try it out you have to enable an experimental flag by visiting chrome://flags:
After you do this, local physical web beacons appear when you start a search:
It’s far more likely people will see this rather than the Chrome widget at the bottom of the notifications Today panel.
It’s unknown whether this will find it’s way into future versions of Chrome without having to set the flag or whether it might appear on Android. Android has more visible Eddystone detection as it’s built in Android itself (Play Services to be more specific) and appears near the top of the notifications panel.
UPDATE: As of October 2017, Google removed Eddystone detection from Chrome on iOS and Android. Only Android can provide notifications.
Most beacon platforms are fairly limited in that they are designed around retail marketing scenarios. If you are creating a non-retail marketing solution you might want to look into Google’s little publicised Proximity Beacon API. It allows you to register beacons and have arbitrary data, called attachments, associated with them. What’s more, it supports the registration of iBeacon as well as Eddystone beacons and you can use it free of charge.
The usual usecase is setup via Google’s console followed by update from apps detecting beacons. Android and iOS example are available.
It’s not always apps that are used to detect beacons. For example, you might have a single board computer such as the Raspberry Pi or Bluetooth-WiFi gateway detecting beacons and a web front end managing and monitoring the beacons. Google also provides example scripts that show how other entities can be used to register, list and filter beacons. Alternatively, other entities might even call these scripts.
The storing of arbitrary data allows the proximity Beacon API to be used for scenarios beyond retail marketing such as sensing with sensor beacons and real time locating (RTLS).
We have the DIYMall range of Beacon relay modules in stock. These modules work the opposite way around to iBeacon and Eddystone beacons. Instead of a beacon typically causing something to happen on a smartphone, the smartphone (app) connects to the beacon that causes a relay to switch on or off. This can be used to turn anything electrical, on and off, for IoT type applications. There are modules with 1, 4 and 8 relays.
8 Relay Beacon Module – the beacon part is the blue PCB to the left
The controlling device doesn’t have to be a smartphone and can be any other device, such as Raspberry Pi, that can connect via Bluetooth GATT. The modules come with demo iOS/Android apps and example iOS and Android source code projects. The relay modules are also password protected for added security.
We are seeing more and more customers using beacons in driving-related scenarios. Most are using beacons to trigger when the user gets into or out of a vehicle. For example, there are driversnote and tour iOS apps that track your trips ready for your mileage claim. However, these apps are for personal use and there’s a larger market and opportunity in company/fleet management. For example, mileagecount is currently launching an automated mileage capture system based on beacons.
The key thing here is the use of beacons to trigger something else, mileage capture in this case. It’s automated, unobtrusive and doesn’t necessarily produce app notifications. There’s a very large number of similar usecases in other industries waiting to be explored.
We have had several companies contact us very recently regarding problems with beacon detection on iOS 10. Problems include not detecting beacons when the app is not running and, when the app is running, beacons suddenly not being seen when they are in range. Another reported symptom is beacons not being detected for a very long time. These problems are all with apps that previously ‘just worked’ under iOS 9. The problems are erratic in that everything works ok on some people’s phones.
We have done some tests with our apps and have reproduced the background scenario of a beacon not being detected on a phone running iOS 10.0.1 that is detected, at the same time, by the same app on iOS 9. Strangely, once the power/screen is manually activated on the iOS 10 phone, the beacon gets detected. Updating to the latest 10.1.1 doesn’t fix the problem.
There are related posts on the ‘Beacon Ranging Problem in 10‘ and ‘Beacon Ranging in background on iOS10 is not working‘ on the Apple forums suggesting similar problems.
This is just a public service announcement that if beacon detection isn’t working for you at the moment the problem is not necessarily with your implementation or the product/app you are using. We believe the problem has been reported to Apple and you will need to wait for an iOS update with a fix.
UPDATE: See https://openradar.appspot.com/29509635
UPDATE March 2017: Troubleshooting iBeacon Background Triggering
There’s a new iOS Swift library QuickBLE on GitHub that simpifies connecting to Bluetooth LE devices and reading/writing Bluetooth Service Characteristics.