BeaconAir – Track your Pi

Apple's iBeacon system is a Bluetooth-based location service that you can use to monitor the proximity of your cell phone to an iBeacon device. I decided to try out the iBeacon system with a Raspberry Pi. The result is BeaconAir, a portable Raspberry Pi-based project that reads the "advertising" packets emitted by iBeacon devices, roughly calculates your position, and then turns on lights as you approach. The Pi then calculates brightness based on how close you are.

The idea is that you can walk around your house with your Pi and the lights will follow you. In other words, I am using iBeacons to figure out where my portable Pi is physically located (in a pouch on my hip as I walk around the house), and then I control various devices with the Pi.

The unique aspect of BeaconAir compared with many other extant Pi-based iBeacon projects is that I am not programming the Raspberry Pi to be an iBeacon; in fact, I am doing the opposite: I am using the Pi to read specialized iBeacons, although you could also build your own iBeacons out of Raspberry Pis and then read them via Bluetooth.

This project is based around a portable Raspberry Pi Model B connected with a Bluetooth 4.0 USB dongle and a Wi-Pi Wireless USB dongle (Figure 1).

Figure 1: The completed BeaconAir Portable Pi project.

BLE iBeacons

An iBeacon [1] is a low-powered, low-cost transmitter that can notify nearby devices of its presence and determine a rough approximation of range. A number of manufacturers produce these devices, and most smartphones (and Raspberry Pis) can be made to act as iBeacons. An iBeacon uses Bluetooth Low Energy (BLE), also known as Bluetooth Smart [2]. iBeacons can also be received on Bluetooth 4.0 devices that support dual mode (e.g., the IOGear dongle specified in the "Hardware" box).

iBeacon applications include location-aware advertising, social media check-ins, or notifications sent to your smartphone or Rasp Pi. An iBeacon transmits an advertising packet containing a UDID (Unique Device Identifier) that identifies the manufacturer and then a major and minor number that can be used to identify the specific device. It also sends out an RSSI (Relative Signal Strength Indicator) that can be used to approximate the distance to the iBeacon device.

Almost all the logic behind an iBeacon deployment is through the supporting application on the device (a Raspberry Pi in this case). The only role of the iBeacon (Figure 2) is to advertise its own existence at a physical location. In some cases, you can connect to an individual device through the iBeacon's GATT (General Attribute profile), although some iBeacons have a proprietary interface (e.g., Estimote iBeacons) that prohibit this use.

Figure 2: The iBeacons I used in this article.

I used two types of iBeacons, Estimote [3] and KS Technologies Particles [4]. Both worked adequately with regards to receiving advertising packets, but the Estimote beacons have a proprietary interface that makes it unfriendly to Linux and Raspberry Pis, so I recommend the Particle iBeacons, because you can read and write to the devices from the Raspberry Pi. The Estimote only supports a proprietary SDK on Android and iPhone. Of course, you can always roll your own using a Raspberry Pi.

BeaconAir comprises four major pieces of software: The Bluetooth iBeacon scanner, the Philips Hue interface, the main BeaconAir software, and the RasPiConnect Server software.

Bluetooth iBeacon Scanner

Technically, setting up the iBeacon Bluetooth scanner was the most difficult part of the BeaconAir system. The software available to do this was not very reliable and did not produce the kind of information I was interested in. Figure 3 shows the iBeacons near my lab bench using the BTLExplorer (now BLExplorer) app [5] on my iPhone from KS Technologies.

Figure 3: iBeacons in the area.

Note that I picked up an Estimote beacon, two Particle beacons, and, interestingly enough, an Apple TV located about 40 feet away. I was not aware that the Apple TV was broadcasting an iBeacon packet, but on checking, I discovered it has an undocumented way of setting up the Apple TV from an iPhone. The numbers don't make a lot of sense in the iBeacon advertising packet, but that is a problem for another day.

The big issue with this project was to be able to read iBeacon data reliably from a Bluetooth Dongle. (I'm using an IOGear Bluetooth 4.0 USB Micro Adapter, Model GBU521.) A number of methods on the web were less than satisfactory (e.g., hcidump scans), often hanging the Bluetooth on the Pi and requiring a reboot. Once I started using my software library, I had zero hangups, and the software ran for days.

The BLE protocol is a relatively new type of Bluetooth that has spotty support, but I finally stumbled upon a program using BlueZ (Linux Bluetooth Library) native call. After a lot of modifications, bug fixing, and cutting of code I didn't need, I had an iBeacon scanner that worked every time. I have posted my working version on the SwitchDoc Labs GitHub site [6], so you can download it and test your own setup.

The blescan.py program is easy to test and use, but it requires some setup on the Raspberry Pi. See the "BeaconAir Software" section for information on installing the required software on the Raspberry Pi. Before you can do this, you need to install the latest version of BlueZ [7], the bluetooth stack for the Raspberry Pi (see the "Installing BlueZ" box). Although you could use apt-get to install, the wheezy version is old and has patchy support for iBeacons.

sudo apt-get install libusb-dev
sudo apt-get install libdbus-1-dev
sudo apt-get install libglib2.0-dev --fix-missing
sudo apt-get install libudev-dev
sudo apt-get install libical-dev
sudo apt-get install libreadline-dev
 **
sudo mkdir bluez
cd bluez
sudo wget www.kernel.org/pub/linux/bluetooth/bluez-5.19.tar.gz
sudo gunzip bluez-5.19.tar.gz
sudo tar xvf bluez-5.19.tar
cd bluez-5.19
sudo ./configure --disable-systemd
sudo make
sudo make install
 **
sudo apt-get install python-bluez
 **
sudo shutdown -r now

pi@BeaconAir ~/BeaconAir/ble $ lsusb
 Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp.
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
 Bus 001 Device 004: ID 0a5c:21e8 Broadcom Corp.

sudo lsusb -v -d 0a5c:

pi@BeaconAir ~/BeaconAir/ble $ hciconfig
hci0: Type: BR/EDR Bus: USB
 **BD Address: 00:02:72:CC:DF:D1 ACL MTU: 1021:8 SCO MTU: 64:1
 **UP RUNNING
 **RX bytes:9071808 acl:0 sco:0 events:230151 errors:0
 **TX bytes:1166 acl:0 sco:0 commands:100 errors:0

pi@BeaconAir ~/BeaconAir/ble $ sudo hciconfig hci0 up

Listing 1 shows the output from the program running in SwitchDoc Labs (with a lot of iBeacons sitting around). The content of the output in Listing 1 is described in Table 1. Note that some odd devices in the output are not my Estimote (b9407…) or Particle (8aefb…) iBeacons. The TX Power for the Estimote and Particle devices behave correctly; the odd devices have larger numbers or numbers that vary.

pi@BeaconAir ~/blescanner $ sudo python testblescan.py
ble thread started
----------
cf:68:cc:c7:33:10,b9407f30f5f8466eaff925556b57fe6d,13072,52423,-74,-78
cf:68:cc:c7:33:10,74696d6f74650e160a181033c7cc68cf,46608,13255,-52,-77
da:f4:2e:a0:70:b1,b9407f30f5f8466eaff925556b57fe6d,28849,11936,-74,-79
da:f4:2e:a0:70:b1,74696d6f74650e160a18b170a02ef4da,46769,28832,46,-78
dd:5d:d3:35:09:dd,8aefb0316c32486f825be26fa193487d,1,1,-64,-78
c3:11:48:9b:cf:fa,8aefb0316c32486f825be26fa193487d,0,0,-64,-73
fd:5b:12:7f:02:e4,b9407f30f5f8466eaff925556b57fe6d,740,4735,-74,-79
fd:5b:12:7f:02:e4,74696d6f74650e160a18e4027f125bfd,46820,639,18,-80
dd:5d:d3:35:09:dd,8aefb0316c32486f825be26fa193487d,1,1,-64,-77