Bluetooth Low Energy (BLE) beacons have been around for some time now, and ever since their launch at WWDC 2013, there has been much hype in the media about their tremendous potential for location-based marketing or “hyper-local” notifications: they basically enable targeted advertisements or informative notifications based on the precise location of a smartphone user, for example inside a mall or shop or inside a museum or exhibition venue respectively. In this respect, they offer a geofencing functionality similar to the one offered by GPS, albeit more precise and also available indoors. If you are interested in learning more about the potential of beacons for location-aware applications and how they differ from GPS-based geofencing, you can check out this link.
The problem
BLE beacons are very simple devices, aptly named to reflect their function: in their minimalistic form, they periodically transmit packets containing the beacon’s ID and the power used to transmit them. The application on the receiving device, typically a smartphone, estimates the distance from the specific beacon by taking into account the free space attenuation of the signal and then executes some logic based on this proximity information (e.g. fetch promotions of the products on sale in the shop the user just passed by).
This is exactly where the limitations of this kind of use cases begin: the user must always have bluetooth enabled, while one or more previously downloaded applications are quietly lurking in the background, leeching battery and clogging RAM, until the time finally comes that the user walks into the vicinity of a beacon. Then, he or she must get notice of the notification, reach for the smartphone, unlock it and finally interact with whatever popped up on the screen. Even assuming that filters are in place that effectively block potentially annoying content and only deliver desired information, the total experience, at least in my personal view, is still sub-optimal.
And how about people who usually don’t carry smartphones around? Before you hastily exclaim that there isn’t anyone like that, I kindly remind you of two age groups: children and the elderly.
Using beacons the other way round
The complications mentioned above could be averted, if one would use beacons in a sort of opposite way: instead of the beacons being the stationary component, they could be the mobile component of a location-aware system. In fact, mobility suits beacons rather well, since due to their simplicity they typically come in very small size. Estimote, a beacon manufacturer, has recognized this and offers the “Estimote stickers”: very small, flexible and sticky beacons, which come with a price tag of only 10$ apiece. So, can we do anything interesting in the context of a smart home with them?
Well, since we had quite many of them lying around, we thought that we ought to at least give it a try. And that’s what we came up with:
- Scenario 1: You are a worrying parent at work, who would like to know whether their precious child returned safely from school and what time they left for school in the morning.
- Scenario 2: You are a worrying child, who would like to know whether their precious elderly parent returned safely or unexpectedly left home.
- Scenario 3: You are a burglar very keen on removing valuable assets from a home you just broke into. The residents are reluctant to part with said assets and would like to be notified of your actions.
- Bonus scenario: You are a lazy smart home inhabitant, who likes to be personally greeted as soon as they come back home, while the music is turned on to play their favorite playlist and the lights switch to their favorite hue of turquoise. Also, for some reason, you despise having bluetooth enabled on your smartphone.
Implementation
As foreshadowed above, we used an Estimote sticker as a presence token, to be carried by the person (e.g. on a key chain or inside a school bag) whose presence we are interested in, or to be attached to a valuable item. We used a Raspberry Pi 3 as the stationery “presence sensor”, i.e. as the hardware platform running the application to receive the signals, infer presence and relay this information. This was a natural choice, since Raspberry Pi 3 comes already equipped with a Bluetooth 4.0 module and a WiFi module, although installing and enabling the necessary bluetooth drivers on Raspbian OS was anything but straightforward.
Our initial intention was to host an instance of openHAB, our home automation software platform, directly on the Raspberry Pi, and use the openHAB bluetooth binding to detect the presence of beacons or other bluetooth mobile devices. We soon discovered, however, that the bluetooth binding was simply broken for GNU/Linux operating systems and the necessary bluetooth Java libraries (e.g. Bluecove) upon which it relied, needed to be compiled from source on the Raspberry and rebundled as a .jar. After spending some fun, quality time trying to use Maven to compile a source code unsupported since long ago, we finally gave up on this plan. It turned out that we were not alone: lots of other people on different fora had a similar experience. Most interestingly, one of these people, based on other references of his own, composed a Python script which used Python bluetooth libraries to detect presence and then publish it to openHAB using the MQTT protocol or REST. I would take tinkering with Python code over Java libraries’ compilation madness anytime, so I got started on adapting and extending the code to suit our setup and use cases.
The system
The end-to-end system, in a simplified block diagram, looks like this:
The logic to reliably infer presence based on the detected bluetooth signals (e.g. by taking account the fluctuations of the received power in time) is implemented in the Python application running on the Raspberry Pi 3. If there is a change in the state of presence for any of the tracked devices (beacons, smartphones), the application communicates this information to 3 different channels:
- IFTTT: Our Python program submits an HTTP request which contains a JSON object with the ID and presence state of the tracked bluetooth device, making use of the REST API which is conveniently supported by the Maker channel on IFTTT (see also our blog bost here). Based on a set of predefined rules, IFTTT then triggers an action by making use of one of the literally hundreds of supported channels. This means that, if desired, we could for example directly control devices in our smart home or update an excel sheet with this presence detection event. For the time being, we were just interested in pushing a notification to an Android smartphone, which optionally relays this notification to our Android smartwatch. So, in case we found ourselves in the position of the parent in Scenario 1 described above, and our son, imaginatively named “Schoolboy7”, would arrive from school, we would be notified like this:
![IFTTT_smartwatch_notification]()
- openHAB: Although, as stated above, one can do basic automation using the IFTTT platform and the plethora of channels it supports, it would still be desirable to integrate this “bluetooth presence detector” with our openHAB automation platform, which is responsible for running the entire smart home. There are multiple benefits coming from this integration: firstly, since many automation rules may depend on whether a specific person or any person in general are currently present at home, it is a good idea to keep the home automation platform updated by this “bluetooth sensor”. Secondly, one can take advantage of the other sensors already in place (e.g. front door contact sensor) or the WLAN connection status of the tracked person’s mobile device, if one exists, and thus more reliably disambiguate the actual state of presence of said person. Fortunately, openHAB allows the state of openHAB items to be set directly over a REST API. Hence, after creating the appropriate Switch items corresponding to the tracked bluetooth devices and writing the openHAB rules on how to update the Switch items corresponding to people’s presence (taking account all relevant factors like WiFi connection, bluetooth detection, front door contact sensor), we programmed the Python application to send HTTP requests directly setting the state of the Switch which corresponds to the bluetooth device that moved into or out of the vicinity of the detector. Other rules can use the state of the presence items and perform certain actions over the openHAB protocol bindings (e.g. turn on/off lights, music, etc).
- Swisscom IoT cloud: Some time ago we showed how one can use the IoT application layer protocol MQTT in order to upload all sorts of sensor data to a cloud application. Apart from a dashboard which allows one to keep track of what’s happening at home from all around the world, there are multiple other functionalities (e.g. alarm features, persistence of data) that could be leveraged. The Python application currently supports MQTT connections, but we defer end-to-end implementation of this channel to some point in the future.
Conclusion
Bluetooth beacons provide an easy and cheap way to implement “location-aware” applications, especially in the context of smart home automation, without having to rely on the use of smartphones. Among other possible opportunities offered, this means on the one hand that even people without smartphones, like children or the elderly, can take advantage of these applications, and on the other that people who do have smartphones can enjoy them with a longer battery life better responsivity.