Beacon Demonstrator App

beaconzoneI recently wrote about how many articles on iBeacons and Eddystone obscure or confuse what beacons actually are due to over emphasis of the (retail) business benefits or description of proprietary server side CMS features. I also mentioned I had written some articles explaining the basic concepts.

Following on from this I have created some simple Android and iOS apps for BeaconZone that demonstrate beacon triggering. The apps work with any iBeacons and allow you to set up triggering within the app itself rather than via a web-based CMS. The triggering settings can be shared, via a common ‘group name’ across phones and even across iOS and Android. If fact, it’s easier to set up on Android as you can detect any beacons but on iOS you can only detect predeclared ones. Hence, it’s easier to set up on Android and sync the trigger data with iOS. Both iOS and Android apps also trigger on beacons when the app isn’t running.

It has been a while since I last developed for iOS. As it happens, getting back into iOS development prompted an existing client to ask me to write an iPhone app for them. So it seems I am back into iOS development for a little while. I have been writing predominantly in Swift which I am enjoying but the change in syntax over time has broken many online code samples. I haven’t ever come across a language that breaks the old syntax over time. It’s very strange because languages are usually forward compatible in that old code never breaks but just becomes deprecated. The iOS app review process is still as onerous as ever and is particularly troublesome for iBeacon development. It took four times as long to get the Beacon Demonstrator app reviewed as it did to write it. However code signing, uploading and sharing beta versions is much easier than it used to be in the early days. Regarding newer iOS features, someone was having a bad day (or a joke) when they added auto layout to iOS, especially the Xcode tooling which is unintuitive and frustrating until you know the quirks. Apple should have taken some time to look at Android Studio.

The beacon ecosystem is maturing what with companies such as Estimote getting substantial funding and Nokia funding Sensoro. However, beacons are still only mainly being used in retail and visitor spaces. I believe they can do a lot more. The link between Bluetooth Beacons, IoT and sensors provides some opportunities and is an area I will be exploring further.

New Articles on iBeacon and Eddystone Bluetooth Beacons

beaconzoneThere are many articles on iBeacons and Eddystone that obscure or confuse what beacons actually are due to over emphasis of the business benefits or description of proprietary server side CMS features.

I have recently written several new articles for The articles explain what beacons are, ways they can be used and pragmatic tips how to set them up based on past experience…

What are Beacons?
Ways to Use Beacons
iOS and Android Apps
Choosing UUID, Major, Minor and Eddystone-UID For Beacons
Choosing an Advertising Interval
Choosing the Transmitted Power
Determining Location Using Bluetooth Beacons

Also take a look at my recent article on this site on Bluetooth Beacons, iBeacons, Eddystone and IoT. You can also follow @TheBeaconZone on Twitter for the latest news on iBeacon and Eddystone.

Bluetooth Beacons, iBeacons, Eddystone and IoT

bluetoothWhat have Bluetooth Beacons, iBeacons and Eddystone to do with the Internet of Things (IoT)? What’s the role of smartphones and apps in IoT?

The IoT is the networking of physical objects such that they can be sensed or controlled remotely. The Enabling the Internet of Things article is a great primer. Ignoring for a moment the complex issues of data management, analytics, security and privacy, IoT has a connectivity problem.

The physical ‘things’ need to connect. However, they are often cost constrained and/or energy (battery) constrained and/or resource (cpu/memory) constrained so many can’t have their own WiFi. As a paper from the University of Michigan says, ‘The Internet of Things Has a Gateway Problem‘. Most current IoT solutions either implement expensive WiFi or have a separate router. The main problem with the separate router approach is that this will become impractical when a large number of things, for example in the home, become part of the IoT. You won’t want a router for each service.

Some people say Bluetooth Beacons, iBeacons and Eddystone are part of the IoT but I’d argue they strictly aren’t as current implementations don’t talk over an Internet protocol (IPv6) – yet. There’s a draft specification for IPv6 over Bluetooth LE  and the Nordic nRF51 SoC used in many iBeacons, has an SDK for IPv6 over Bluetooth® Smart.

Even with IPv6 over Bluetooth LE there’s a router problem. Something needs to forward on the IPv6 data. In Nordic’s implementation a Raspberry Pi is used as a Bluetooth Smart router. However, the good thing is only one router, per location, is needed for multiple services. Another future possibility is to use smartphones as the IPv6 router.

Another problem is the capability (cpu, memory) of current SoCs typically isn’t sufficient to run IPv6 over Bluetooth LE and the core functionality of whatever it is doing/monitoring. However, newer SoC such as Nordic’s nRF52 Series might help solve this problem.

Whether now or in the future, smartphones can be used to pass on either the data itself communicated via BLE or data wrapped via the IPv6 protocol. Smartphones are the enabling technology. Apps are also ideally placed to provide a UI to control and view local or remote IoT devices.

So what can the Bluetooth beacons do? Up to now, most uses have been in the retail and visitor spaces with an emphasis on location. However, IoT is more about sensing and control. What can beacons sense? Current beacons can sense acceleration, temperature and humidity. A conversation with Terence Eden on Twitter made me realise that current beacons already offer a bit more. Some of them have on-off switches, turning broadcasting on/off, that can be directly wired into other sensors such as door/open close sensors, other security sensors or other on/off circuits.

iBeacon Evolution

beaconzoneBeacons have improved over the last year to solve some problems related to rollout, provide more opportunities via use of extra sensors and also to support Google’s Eddystone.

After you have developed apps and have a beacon rollout, the first problem you are likely to experience is battery life. Manufacturers have responded in several ways. One of the main problems is knowing the battery needs changing. AnkhMaway beacons with the latest firmware now publish the battery level in the advertising data to allow apps to determine battery levels without connecting. Manufacturer’s such as Wellcore are relieving the battery life problem through brute force with beacons that have more batteries. Meanwhile, other manufacturers such as Sky have included time based on/off to save power during the time of day when the beacon isn’t likely to be used.

Beacons are also starting to get more sensors. The AnkhMaway iB003N includes an extra advertising channel that sends real-time accellerometer data. The Sky 201 has precision temperature, humidity and accelerometer sensors.

Form factors are also improving. There are several waterproof and water resistant beacons for use outside or in more extreme environments. The smaller beacons are getting even smaller, down to 2.6mm thick, so that they can be worn or attached less conspicuously.

More beacons now support Eddystone as well as iBeacon. The iB001M and iB003N have a custom channel that supports Eddystone or any other data you wish to advertise and this works at the same time as the iBeacon broadcast.

As I mentioned in a previous post, today’s beacon-based solutions mainly revolve around service-based solutions where you have to use a particular type of beacon with a particular backend. These solutions also tend to be tightly focussed around retail and generally obscure (marketers would say ‘simplify’) the way these solutions actually work.

However, it doesn’t have to be this way. There are many more uses for beacons and opportunities that become apparent when technical information and the beacons themselves become more readily available. My company’s new site provides information on what beacons are, how they can be used and explains the interrelationship with apps. You can also purchase OEM beacons for shipping to the UK and Europe.

We have also developed a beacon demonstrator app for iOS and Android that allows you to experiment with beacon triggering without using particular vendor’s beacons nor signing up to a backend service.

Challenge to iBeacon Monetisation for System Integrators

beaconcontrolI have a particular interest in Bluetooth beacons because I have worked on a few projects that have used iBeacons. For the uninitiated, Bluetooth LE allows beacon unique ids (and sometimes extra information) to be seen by smartphones without having to pair devices as was the case with previous versions of Bluetooth. It also uses lower power.

The id in the advertising data can be formatted as either an Apple iBeacon id or Google’s Eddystone-UID. Google also has the facility to broadcast a URL that can be launched via Chrome and Opera web browsers or an app. However, most of the effort at the moment is involved with apps that do things when they see the ids. This obviously needs a server side to map ids to things to show or do.

Many companies have sprung up to integrate all of this and most are currently trying to monetise by charging a monthly fee for a generic server side and selling custom or re-branded beacons under their own name. Google partly threatened the server side monetisation model when they announced Eddystone’s free cloud beacon backend that can equally be used for iBeacons. However, as I previously mentioned, it’s a headless backend and you still need to create some type of web UI.

All this has just changed. BeaconControl has released, a free open source UI and backend for managing beacons that will put pressure on beacon solution integrators.


I believe these companies will now need to specialise in order to survive. This specialisation might take many forms. One might be to concentrate on unique facilities that only their combined more-customised beacons and platform can provide, for example, beacon battery health. Alternatively, they might produce more specialised backends suitable for specific usecases such as museums or retail where the user experience and in-app actions might be better if they were more oriented towards those domains. A third opportunity is specialising in management. As evidenced by Brooklyn Museum, the setup and location of beacons, creation/entering of data, ongoing monitoring and support of venues can be large tasks that are sometimes under estimated.

UPDATE: Also see BeaconZone for more information on beacons.

Location Services On

skyhookSkyhook has a recent article and infographic based on a Research Now survey into consumer attitudes into keeping location services on. 50% of users are concerned about privacy, 23% don’t see the value of location data and 19% think that location services drains their battery.


Skyhook recommend developers concentrate on the First Time User Experience (FTUX) to tell users what data is being collected, why and the value in keeping it turned on.

Also don’t forget that on Android, as of Marshmallow, Bluetooth LE beacons (iBeacon and Eddystone) also need coarse location permission and location ON to detect in background. This is actually a functional regression in Android as older previously working apps now fail to detect Bluetooth LE beacons in background on Marshmallow phones without this permission and location ON.

Thought’s on Google’s Bluetooth LE Eddystone and Cloud APIs

bluetoothGoogle announced their Eddystone open Bluetooth LE beacon protocol today and corresponding APIs to allow Eddystone (and Apple iBeacon) information to be stored in Google’s cloud to which arbitrary information (text, images etc) can be attached. Google have also introduced a Monitor Beacons API so that the health of beacons can be monitored. What does this mean for the cross platform (iOS and Android) developer?

The Beacon Hardware: First of all, existing iBeacon hardware won’t automatically work with (transmit data for) Eddystone. Bluvision, Estimote,, Radius Networks and Signal360 have already updated their beacons but these companies represent a small part of the beacon hardware market. As a small sample, the Bluetooth LE apps I have created for clients don’t use these beacons. Maybe other manufacturers will upgrade their beacons in time? Without Eddystone, Android (4.3+) can already sense iBeacons and infer distance so it might seem there’s no urgency to use Eddystone. However, from experience, I know the extra features provided by Eddystone, such as monitoring battery life, are really needed and are not gimmick – this itself might encourage demand for Eddystone. By the way, upgrading beacons will enable them for both iBeacon AND Eddystone, such they alternately transmit in each format, so it’s not a case of supporting one or the other (or having two separate beacons for each protocol).

The Cloud API: This is interesting as it’s free way of associating content with a beacon, irrespective of whether you are using Eddystone or not. Obviously, if you only store iBeacons then you won’t get the extra benefits of the health monitoring. Note that it’s only an API and not a web interface. You will still need to create your own web interface for your customers that, in turn, uses the Google cloud API to register beacons and map your business objects into the ‘arbitrary’ content to attach to a beacon. From there, it’s only a small extra step to also provide a device JSON API yourself. I am not sure yet why people might choose to use Google’s API other than to later participate in the upcoming changes to the Google Places API to make beacons globally visible – something that will probably benefit Google more than the information provider who in many (but not all) cases will usually want to keep the content in their own app(s).

Update: My assumption that upgrading beacons will enable them for both iBeacon AND Eddystone, such they alternately transmit in each format was wrong. The Estimote blog explains that while this is technically possible and “makes a ton of sense”, it isn’t legally possible if hardware vendors wish to remain officially iBeacon compatible as Apple “don’t allow other frames”. I now expect this to seriously limit the takeup of Eddystone as many companies still work on an iOS first basis. Solution providers will have to select iBeacon OR Eddystone. For cross platform solutions, using iBeacons will give better iOS background detection while using Eddystone will give access to beacon health information and future integration into Google Places.

Nov 2015 Update: Multimode beacons that sequentially send iBeacon and Eddystone are coming available.

Dec 2015 Update: The AnkhMaway iB001M also sends iBeacon and Eddystone at the same time.

TI SensorTag

texasinstrumentsUp to now most low power Bluetooth beacons have been fairly limited devices that only transmit simple information that can be used for ‘presence’ based applications. Some can send extra information such as battery life to the phone and some you can remotely cause to beep or flash but most of the innovative ideas have revolved around using them to detect presence and trigger content to be shown, for example, in retail stores or museums.

TI have something interesting with their new CC2650 SensorTag that connects to Android or iOS (as an iBeacon) providing support for up to 10 low-power sensors for ambient light, digital microphone, magnetic sensor, humidity, pressure, accelerometer, gyroscope, magnetometer, object temperature and ambient temperature.




The possibilities suddenly become far more exciting and seemingly endless. For example, in sport you might attach one to your sports equipment (racquet, golf club or whatever) to analyse technique. In health, you might attach one to yourself or someone else (elderly?) to detect movement. In security, they might be attached to high-value items to protect in various (theft, dampness, extreme movement) ways or used as the basis for a home security system.

The CC2650 is available as a tag for $29 or the chip that does the work is available in large quantities, for use in your own hardware designs, for around $6.

Update: Looking closer at the one I have purchased, the $29 tag has a very restricted license that says you can’t use it in a finished product or production solution – presumably mainly because it’s not FCC approved . It’s for evaluation purposes only. That’s a shame as it’s a large step to have to integrate the chip in your own board, even if you base it on their ‘open’ hardware design.