Building a battery-powered wireless sensor using Bluetooth Low-Energy (BLE) and Apple HomeKit (Part 1)

In this series, we'll look at building a simple wireless temperature and humidity sensor using inexpensive components and Bluetooth Low Energy (BLE) for communication. We'll read off the sensor values using the Home app from an iOS device.

Motivation

This project originally started when I got a new humidifier at home and wanted an easy way to tell when the humidity levels were too low. After searching in vain for an inexpensive HomeKit-compatible sensor, I decided to see if I could build one myself from cheap components.

I wanted my sensor to:

• Have a low cost to build
• Have low power consumption, be capable of running from a few AA batteries for ~1 year (or at least a few months)
• Transmit sensor values that could be easily viewed from my smartphone

After some brief research, I chose Bluetooth Low Energy (BLE) and Apple HomeKit as the 2 basic implementation technologies for this project.

Why HomeKit?

HomeKit is a relatively new (2014) framework developed by Apple to enable advanced, centralized home-automation control with tight integration inside the iOS ecosystem. HomeKit is making it easy for ordinary, non-technical people to set up elaborate home automation schemes, with an intuitive control interface (the iOS Home app), preset device state collections called "scenes", and voice control (via Siri).

Some people might be surprised to learn that home automation has actually been around for decades, and there have been comprehensive wireless control systems since the mid-1970s. There is an entire market of controllers, switches and "smart" (dumb by today's standards) devices that existed long before HomeKit or even the first iPhone.

So why does it seem that only now are we starting to hear about the smart home revolution? I think it's for the same reason that it wasn't until the mid-1980s that we didn't hear about the personal computer revolution. Like it has with many technologies before, Apple is bringing smart home device technology out of the realm of engineers, academics, and basement-dwelling geeks and into the hands of ordinary non-technical folk. Apple has a knack for making complex technical systems accessible through simple, intuitive interfaces. With this combination of user-friendliness and tight Apple ecosystem integration (e.g. "Siri, turn on the light"), I think HomeKit is poised to bring home automation into the mainstream at greater proportions than ever before.

Considering all that, HomeKit is a technology that I was eager to start playing with and learning about.

Why Bluetooth Low Energy?

Bluetooth Low Energy (BLE) is an open wireless data transmission standard that was introduced by Nokia in the late 2000s, offering near-range communication at low throughput rates (~0.3Mbit/s), with very low power requirements (in the 0.01 - 0.5W range).

Since the introduction of the BLE standard, the market has seen a flood of new BLE-compatible devices. The inclusion of BLE in smartphones, notably the iPhone (since the 4S model), has encouraged wireless peripheral manufacturers to utilize BLE, and this in turn has induced further proliferation of BLE-capable hub devices. A report by ABI Research forecasts growth of Bluetooth Low Energy device production by 34% between 2016 and 2021, with BLE devices comprising 27% of total Bluetooth shipments by 2021.

BLE's power characteristics make it an excellent candidate technology for data transmission in this project. Although there are other technologies we could have used here instead, for example ZigBee or ANT, I was most interested to get to know the mechanics of BLE because of its prevalence in the marketplace and its expected growth in the years to come.

Solutions

HomeKit is a closed, proprietary protocol developed solely by Apple. Its specifications are only available to Apple MFi program members. I'm not an MFi program member and don't have access to those specifications, so we won't go into much detail here about the HomeKit protocol.

HomeKit fundamentally operates over 2 network protocols:

1. IP (over a wired or wireless LAN)
2. Bluetooth Low Energy (BLE)

The de-facto standard software implementation of HomeKit Accessory Protocol (HAP) is the closed-source OberonHAP software developed by Oberon. Although I haven't worked with it myself, according to Oberon it is the best implementation available, performing a few times faster and consuming less memory than any alternative implementation.

Luckily, for hobbyists like myself, there are a number of reasonably high-quality open-source HAP implementations. I've listed some of them below:

Of those projects, the IP-based implementations are the most mature, by far.

Network topologies

Next, I needed to decide how the sensor values would be read using a smartphone. I considered a few network topologies (arrangements of the devices in a network):

Option 1: Arduino-based dumb sensor + wifi-connected bridge

This option made sense because I already had an Arduino Uno, and I knew that Arduino-compatible BLE transceivers could be had for relatively cheap.

Evaluating Option 1

One of the first things I did was to estimate the sensor's power consumption in this arrangement. Even in a low-power configuration, an Arduino Uno draws about 35mA at idle. With 3 × 2500mAh batteries, this would only yield us ~1 week of battery life, without even considering that current would also be drawn by the BLE module and sensor. This is far from satisfying our requirement of running on batteries for at least a few months, so I was back to the drawing board.

I began to look into Arduino Nano and even using a bare ATmega328 in an attempt to reduce power consumption. It was at this point that I discovered the Nordic Semiconductor nRF52832 SoC with an integrated BLE transceiver, with an operating current draw of about 50μA — 3 orders of magnitude smaller than the Uno! This was a major breakthrough, since the nRF5 was capable of replacing the Arduino + BLE module combination, in a smaller package, with lower power consumption, and at a low cost. [In the next blog post, I'll discuss the nRF5 in more detail]. So I moved on to the next option, based on the nRF5.

Option 2: nRF-based smart sensor

With the next solution, I attempted to simplify the system as much as possible. Having eliminated the need for a separate microcontroller (the Arduino), I wondered if I could also remove the need for a separate HomeKit BLE-to-WiFi bridge.

Evaluating Option 2

The major issue blocking this route turned out to be an issue of software, i.e. the absence of a mature open-source implementation of HAP over BLE. As shown in the table above, I only found a single BLE HAP server: aanon4/HomeKit. Unfortunately, at the time of writing, it is immature, poorly documented, unmaintained, and written in C. For a hobbyist like myself, debugging issues with C code running on the nRF5 would be a significant challenge and time commitment. Therefore, this option was a no-go.

It's worth noting, though, that this is not a fundamental flaw in this topology. If this were a real product, OberonHAP could probably be used to implement HAP over BLE quite easily.

Option 3: nRF-based dumb sensor + wifi-connected bridge

The final option was a combination of Option 1 and Option 2; I simply added the HAP WiFi bridge from Option 1 back into the topology of Option 2.

Evaluating Option 3

With this option, I was able to maintain the improved sensor power consumption characteristics from Option 2, while overcoming the HAP server software roadblock. This option seemed to finally be a path to a viable solution. Success!

Conclusion and Next Steps

Having chosen a workable high-level design and network topology, the next steps were to:

• Implement BLE sensor value broadcasting on the nRF5
• Implement a BLE ⟷ HAP-over-IP sensor bridge

In the next post, I'll discuss the hardware used in this project, and we'll get into the BLE sensor broadcasting implementation.

See what happens next in Part 2!