iBeacon sparks

Hacking an Open Door Policy with iBeacon

All great apps solve a problem. Sometimes clearly defining that problem is difficult. But this one was easy:

We use a fingerprint scanner for keyless entry at our San Francisco office. To say it is a hassle would be an understatement. It rarely works on the first try — whether its because you put your finger just off the edge of the sensor or because the surface may have residue. Attempts often end with a flashing red light and a beep of denial.

So, when we were discussing problems we wanted to solve during our recent Hackathon, a better way to open the front door was an obvious one. An agile user story was immediately born: When an ArcTouch employee approaches the office door, we want the door to automatically unlock.

There were three things we knew without any research that gave us the confidence we could solve this problem:

  • Everyone in our office has either an Android phone or an iPhone
  • With iBeacon technology, you can detect when one thing (a person) is near another (the door)
  • We happen to be pretty darn good at making apps that solve real world problems

Here’s how we solved it:

Find the Right Hardware

Building a connected “Internet of Things” type app requires finding the right hardware to connect to. We did a lot of the planning prior to the start of the hackathon. To start, we needed to find an electric strike (fail-secure) that we could mount in the door frame and trigger the lock to open remotely without any physical human force being applied. We found this 12-volt strike online that could do the trick.

To activate the strike remotely, we found this device called the Spark Core, which can connect to WiFi and drive the the 12-volt strike from 5-volt logic. In practice, the Spark Core is signaled from the user’s mobile device via the cloud — even with only a cellular connection.

Since we wanted the door to automatically unlock without any user intervention, we needed a pair of iBeacon transmitters — one outside the door and one inside. With two transmitters, we could determine the direction and range of an employee, so that the door lock would open when they were approaching from outside the office but wouldn’t continually activate when they were already inside.

The Lox App

The app we wanted to create was simple. It would run in the background without any user interaction and simply sense the presence of the the iBeacon when approaching the door, then send a signal to the Spark Core through the cloud to trigger the strike. A handy notification widget would be shown on screen displaying the status, and allow the user manually trigger the strike if needed. We named the app “Lox” — and naturally, we decided to use a bagel for the icon!


The Hackathon and its Challenges

We started the two-day hackathon on Jan. 5-6 by doing some planning in one of our conference rooms, and it didn’t take long for us to get our hands dirty:

With all of our hardware in hand — and knowing what we needed our app to do — we were confident we could complete this project. But of course, in development you always expect — and try to plan for — the unexpected. Some of the challenges we encountered:

  • Replacing the existing door strike with the electric strike required more manual work than we thought because the electric strike was deeper than the original. Adding further complication: the door frame had an aluminum beam immediately below the existing strike. So, we had to saw/grind out enough room to fit the new strike. It made for some great photos:

hackathon sparks

  • The iBeacon is subject to quite a bit of competing wireless noise, particularly in the short distances we were interested in. We had to tweak the app to trigger the lock when a phone was just close enough outside without also triggering the lock from the inside.
  • We initially set up the app to signal the Spark Core through the cloud. This allows the mobile device to use any connection available (Wi-Fi or cellular). But we realized this created a security problem. Anyone who knows how to signal the Spark Core could open the door via the cellular network. We’re currently working on an update that limits this to Wi-Fi, so you have to be connected to the ArcTouch network to trigger the door.
  • Conserving battery life is a challenge. To trigger the lock without too much delay as the user approaches, we wanted the BLE radios to frequently poll for the iBeacon signal. However, this polling drains the phone battery — even when the phone was nowhere near the office. To address this, we’re working on an update that will use location services to notify the app when the user is in range of the ArcTouch building — and only then will it increase the frequency of the BLE polling.


We still have a few odds and ends to take care of before we roll the app out to our entire office. But like my colleague Ecil with his Apple Watch / HomeKit project, I was lucky enough to have a true “Victory” moment when we presented our project the day after the Hackathon. To demonstrate, I walked down the hall while my colleagues waited just inside the door, and “click”…. then loud applause:

Victory felt great. We solved a real problem in two days. And we proved (again) how iBeacon proximity technology can creatively be used to do some pretty amazing things.

About Nathan Nathan Williams is a software developer at ArcTouch. His focus is on Xamarin for cross-platform app development and like any good engineer, brews his own beer at home.