Your Mobile Device Lab Needs a Nanny

Not that kind. This one is open source.

Published in

In The Hudl

7 min readOct 11, 2016

Hudl has grown from about 100 employees in two offices to 440+ employees in 17 offices around the world in less than 3 years. A lot of these employees work on mobile apps, and so need mobile devices to develop and test on. There are plenty of good resources out there about how and why you need a fleet of devices for manual testing (unless you’re Facebook), and most describe a system to track which devices are available or in use.

Without some type of checkout system:

Time is wasted trying to locate devices
Corners may be cut when testing
Testing scenarios could be skipped altogether
Individuals start hoarding devices
Teams spend money on devices for themselves to avoid wasting time
Devices sit unused because they are “owned” by a specific team
Unnecessary devices are purchased for the lab
Unable to tell if more devices are needed
No way to know what types of devices are available
Can’t plan for the appropriate mix of new/old devices

This list is an incomplete yet convincing argument for a checkout system, but what isn’t discussed in the articles linked above is the Achilles’ heel they all share. Here’s a quick story about John to help illustrate.

John

John works for a software company. He’s trying to find a device to test/dev on, but the kind he needs isn’t in the lab.

“Hey Jane, have you seen *device*? Or heck, just any *manufacturer* devices? At this point I don’t care if it’s a phone or tablet,” he said, glancing around frustratedly.

“Last I saw Bob had one, but it’s not on his desk anymore,” she replied.

John Slacked Bob, who confirmed he doesn’t have one.

Before John spams his coworkers, he decides to look and see if someone checked it out in the system. To his dismay (but not surprise), the device is listed as available in the lab he just came from. Further research showed that only eight people had actually used the checkout system in the last six months.

The Problem

The checkout system John’s company used to manage their device lab had the problem. This caveat that, if not followed, can bring the whole thing down.

“Participation required.”

100% participation. Without it, the reliability of the checkout system will be lost. If the reliability is lost the trust is lost. If the trust is lost the system is lost. If the system is lost…

Someone might need a device for just a few minutes and not bother to check it out. That device could end up being gone for a lot longer than a few minutes, and the checkout system will slowly lose reliability. If some people aren’t using it, why should anyone? Randomly accurate information makes the dataset useless.

Problem Solving

So how do we build a checkout system that everyone will use? Even the person who only wants a device for “a few minutes”? You could lock up the lab, but that’s inefficient and against our company culture. It also has to be easy and fast, or it will be a pain point.

But that won’t be enough. Just because a system is easy and fast doesn’t mean you have to use it. And even if participation wasn’t an issue, how do you make sure the device is ever returned? It sounds like what we really need to build is a checkout system that works without participation.

What we really need to build is a checkout system works without participation.

Etsy wrote a great article about their RFID tag solution. We decided to go that route as well (with a less customized RFID reader). But again, just because scanning RFID tags is fun, not everyone will do it every time. In order to remove participation from the equation, we added Bluetooth pair requests and Slack messaging and called it DeviceNanny.

DeviceNanny v. 1

DeviceNanny v.1 had three parts. One part front-end, one part device checkout, and one part Nanny. The Nanny was what kept the system reliable.

In addition to RFID scanning, it used Bluetooth pair requests to determine if a device was removed from the lab without being checked out. If it was, the Nanny would ping an entire channel telling of the misdeed. The Nanny also sent Slack messages to users who had a device for too long. I won’t go into a lot of detail on V1 because it didn’t work.

Why Version 1 Failed

In order for Bluetooth scanning to be reliable, devices had to be returned to the lab with power, Bluetooth on, and plugged in so they wouldn’t die. This requires participation which, as we know, leads to failure. Combine this with having to velcro the RFID tags onto each device because of metal interference and problems with Bluetooth pairing, and it quickly became a no-go. RFID checkout worked but with no guarantee of reliability. Luckily in the middle of solving DeviceNanny v1 problems, we came up with a solution.

DeviceNanny v. 2

Devices needed to be plugged in at the lab so they wouldn’t die. To solve this power problem we decided to get USB hubs. If we’re getting USB hubs, why not plug them into our Raspberry Pi and use USB connections to determine if a device is checked in/out?

With USB connections:

Devices are always charged
You have to unplug a device to take it from the lab, so it’s impossible to not use the system
No more relying on any type of user action
100% accurate device lab database

The Build

It quickly became obvious that there aren’t many USB hubs on the market that provide a data connection AND enough power for a bunch of thirsty iPads. An iPad’s power brick supplies 2.1 amps, so this makes sense. If I wanted to plug 10 iPads into a hub it could theoretically pull 21A. That’s a lot of juice, and the hubs that supply that amount of power cost over $1000. If you bought a 16-port hub for $1300, you’d have to spend another $1300 just to include the 17th device. Not very scalable or cost effective. $4000+ for 40 devices is a bit much. (Although it could be argued that if you’re buying 40+ devices it’s not out of the question.) But why bother if there’s a cheaper way!

If you bought a 16-port hub for $1300, you’d have to spend another $1300 just to include the 17th device.

We were able to find 10-port hubs for under $150 that would supply 1.5A per port. During testing we found that a completely dead 12" iPad Pro would only draw about .8A while idly charging, so 1.5A would be plenty. The catch is you have to buy and wire up your own power supply. Not a problem since a PSU only costs around $25 and wire by-the-foot is dirt cheap.

Measuring power consumption with an old computer PSU

For the device lab in our Omaha office we bought four 10-port hubs, a 30A power supply, some wire, and velcroed everything onto a board. Why velcro? First, because we will be changing how we organize our devices in the lab and wanted to be flexible. Second, and more pertinently, because we had a bunch left over from velcroing RFID tags to devices.

Finished 40-port hub and some sunglasses.

DeviceNanny Part 1: Device Checkout/Check-in

Simply take a device. Checkouts are trigged by USB actions using a udev rule. No more relying on someone to scan a card or click a button.
Enter your name or ID number. The system will then send a Slack message confirming you checked out a device. If a name isn’t entered, the device will be registered as missing and a Slack message is sent to a channel.

To return a device just plug it back in to any available spot in the hub. It was purposefully developed in a way that you can return the device to any spot and not confuse the system. Tip: Provide more cords than devices.

To add a new device, just plug it in! A small form will pop up prompting for some device info.

DeviceNanny Part 2: The Nanny

The Nanny’s job is to keep everything organized and accurate.

If a device has been checked out for more than three days, it will send the user a Slack message every 4 hours (8–5 M-F) reminding that person to renew their checkout or return the device.
If a device is missing for three days, it will ping a channel asking for it to be returned.
If a device was returned/taken while the system was off or something went wrong with checkout, it will update the database and fix any incorrect port assignments. You can shut down the Pi and scramble all the devices. It will re-assign everything once it’s turned back on.

DeviceNanny Part 3: The Front-End

Nothing too fancy here, just a table that displays information about each device and who has it if it’s checked out. The one feature of the front-end is the ability to renew checkouts if you need a device for longer than three days.

Results

We’ve been using the DeviceNanny at Hudl for a while now and the feedback has been overwhelmingly positive. Version 3 is in the works and will include improvements to the front end with sorting and search. If you’d like to use DeviceNanny and/or contribute to development, you can find the repo here. https://github.com/hudl/DeviceNanny