Open Sesame: How we created our own smart doors

Peter Zignego

  • Reading Time  Min Read
  • Publish Date December 17, 2015

We recently installed new glass doors in our Charlotte office. We considered a system that would allow us to unlock the doors with our phones (versus having to use a traditional keypad) but the quote was absurdly expensive. Since we’re a group of tinkerers and programmers with both software and hardware expertise, we decided to tackle the problem ourselves. It would be a great demo for clients visiting the office and ultimately one less password we’d have to remember. We settled on using Bluetooth Low Energy to communicate between the lock controller and the user’s device and got started prototyping.

As we began work on the mobile app that would communicate with the door, we quickly identified two key hurdles we needed to clear:

  1. Reliability: If it doesn’t work every time, people won’t trust it and won’t use it. Nothing makes you feel dumber faster than standing there pulling on a locked door.

  2. Convenience: Going to the keypad and punching in a code only takes a few seconds. There isn’t a ton of existing friction in the process to remove. Our final solution had to achieve an “install and forget it” level of simplicity and ease.

Location, Location, Location

Our initial prototype for this project used geofencing. Geofencing is a technology that places invisible ‘fences’ around areas, called regions, that you create with GPS coordinates. You can kick off events based on a user entering or exiting one of the regions you’ve specified. The prototype mostly worked, but we ran into some issues that made it a less than optimal technology for our use case:

  1. We’re up on the 15th floor of a downtown office building. Altitude calculations using GPS are complex and frequently inaccurate indoors, causing our BLE search to kick off too early or not at all.
  2. The accuracy we need is less than 100 meters, requiring us to use the GPS radio in a user’s device which really drains the battery.

So we decided to try using iBeacons to trigger the proximity door unlock instead. We knew we were dealing with a small area that we controlled; we wouldn’t have to worry about anyone walking off with our beacons, and we could cover the area with a handful of beacons. This solution also worked nicely with our goal of having a minimal impact on battery life because we could use Bluetooth Low Energy and iBeacons for positioning information instead of battery intensive GPS.

Laying out the Beacons

It took us some time to get the beacon placement and details zeroed in. Ultimately, we landed on the layout below:

This straight line configuration gives us full coverage of the elevator lobby and allows us to prevent people who are just walking by inside of the office from triggering the proximity unlock. The code and the logic behind it is fairly simple: if you’re closer to the elevator lobby beacon (using the CLBeacon property accuracy) than both the office lobby and the back hall beacon, you are considered ‘in the lobby’ and will trigger the proximity unlock. In Swift, it looks like this:

let backHallAccuracy = backHallBeacon?.accuracy
let elevatorLobbyAccuracy = elevatorLobbyBeacon?.accuracy
let frontHallAccuracy = frontHallBeacon?.accuracy

if (elevatorLobbyAccuracy < backHallAccuracy && elevatorLobbyAccuracy < frontHallAccuracy) {

Fine Tuning the Beacons

To get the accuracy values mentioned above, we start ranging the beacons after we enter the beacon region. In our initial tests using the default settings on our Estimote beacons, we found it was taking anywhere from 2 to 10 seconds to get the enteredRegion callback after we stepped off the elevator. This was unacceptable for our use case. We needed to enter the beacon region and start ranging our beacons as soon as we stepped off the elevator. Otherwise, we couldn’t guarantee that the office doors would be open by the time a user reached them. We tried adding additional beacons and adjusting their positioning, but neither of these approaches produced a meaningful change.

Fortunately, the Estimote beacons we’re using have settings that can be tweaked. We reduced the advertising interval down to the minimum value of 100ms. The less time in between advertising packets, the sooner our devices would detect they had entered the region. We also increased the broadcasting power to the maximum value of -4 dBm, giving the signal a better chance of getting through the elevator doors before they opened. While these changes have a negative effect on battery life (Estimote estimates 36 months of battery life with the default values; after our tweaks we saw a battery life estimate of 6 months), they provided us with the additional responsiveness we needed. Users now enter the region, start ranging for the beacons, and complete the unlock handshake with the door before they even step off the elevator.

The Future

This was a fun project that we’re really excited about. In the future, we’re planning to build out administrative capabilities that allow us to use it to manage guest lists and enable smart entry for the many meet-ups, tech talks, and other events we host at the office. If you’re interested in checking out the “smart doors” for yourself, you should swing by. Just be sure to watch your head.


Send Us a Message

Let's Work Together

By filling in the form, you agree to our Privacy Policy, including our cookie use.