Tapster – Part 1: What and Why

Tapster | Mind your Beer!

Hello, my name is Mickey Rogers and I’m a developer at VersionOne. I am writing this multi-part blog to explain Tapster, our new beer monitoring application, built in-house as a Hackweek project, conceived from an empathy mapping training session for our mythical character Bob (the beer drinker). Part 1 will focus on what Tapster is and why we developed it. For efficiency, I’ll use links throughout the text to well-documented concepts and technology sites.Empathy Mapping

At VersionOne, we put a lot of emphasis on continuous learning and knowledge sharing. In that vein, Matthew Almand, one of our UI/UX designers, conducted several empathy mapping sessions at the end of 2015 for the development team. The second of these sessions was focused on the aforementioned Bob who was constantly frustrated with our kegerator (yes, we really do have a double-tap kegerator in each office). He faced problems such as: I don’t know what’s on tap, the keg is empty, and who do I to tell when it’s empty.

You may be thinking, SERIOUSLY, screw Bob and his petty first world problems (FWP). I don’t have a kegerator at work, and if I did, I sure wouldn’t be bitching about it running out of beer every now and then. Well, I agree with you and my first solution was to fire Bob, but that kind of missed the point of empathy mapping. So, we broke up into small teams, took the list of Bob’s issues provided by Matthew, and got to work on empathy mapping and then brainstorming ways to resolve them.

For me, it was difficult at first to empathize with Bob, but after some discussion I was able to relate to some of his problems. At the risk of sounding like him, I had found the keg empty countless times and had it blow as I’m pouring, and I can attest, a quarter cup of beer isn’t very satisfying. About half the time I also didn’t know what was on tap. We were using a manual process of writing what beer was on each tap on a dry-erase board that hung on a wall behind the kegerator. As you can imagine, this was error prone as the person changing the keg may or may not remember to write down the new beer. In addition, there was no way to know when a new beer was installed without walking across the office to look at the board. Okay, so we had identified some legitimate problems that needed to be solved. Then, we did what developers do, think of really creative, and sometimes over engineered, ways to solve those problems. We came up with all sorts of ideas ranging from a simple Slack channel dedicated to sharing information about the kegerator to transforming it into an internet of things (IoT) connected device capable of sharing just about everything you could ever want to know about the beer inside.

Each team took turns describing their solutions and then we repeated the step armed with new ideas from the other teams. The second pass seemed to evolve some of the IoT concepts with more thought given to better measuring techniques and information sharing capabilities. By the end of the second round the best solution was an IoT device that could accurately measure beer flow with a tablet displaying what was on tap and how much beer remained, capable of notifying employees when a keg was low or changed through Slack and email. We ended the session, patted ourselves on the back for all our hard work, poured a beer in honor of Bob, and played a few rounds of pool. What Matthew and I didn’t realize at the time was that a seed had been planted with the perfect opportunity to explore the idea further during Hackweek, which was scheduled for the first week of February 2016.

In early January, I asked Matthew if he’d be interested in working with me on a beer monitoring solution for Hackweek, and of course, he said yes. Informed by many of the ideas cultivated during the empathy mapping session, we began learning about microcontrollers, tablets, communication options between the two, sensors, and software platforms that we could use to implement the features. By mid-January, we had selected the following hardware components and mobile application platform:

Microcontroller: Arduino Uno R3

Communication: Arduino Bluetooth Transceiver (by Kedsum)

Temperature Sensors: OneWire DS18B20 (by Gikfun)

Flow Meters: SwissFlow SF800

Mobile Application Platform: Cordova

We elected not to purchase a tablet at that time since we each had personal tablets to use for development. This also allowed us to further explore the capabilities of Arduino and Cordova to plan future features that may have specific hardware or software requirements.

All the hardware was delivered within a couple days except for the flow meters, which shipped from the Netherlands and would take between ten and fifteen business days to arrive. Having never used an Arduino device or any of the sensors, we used the rest of January to get a basic understanding of the Arduino development environment, establish Bluetooth communication between Arduino and a sample Cordova tablet application, and learn how to wire up the temperature sensors.

The expected delivery date for the flow meters passed so I emailed SwissFlow to find out when they would be delivered and received some bad news. SwissFlow contacted the carrier, PostNL, and they could not find the shipment status in their system. They assured SwissFlow that the shipment would still arrive by the fifteenth business day, February 3^rd, but that was the middle of Hackweek. SwissFlow offered to send the order again without charge, but that would push the delivery date out another three weeks.

Thankfully, Matthew found one Arduino-compatible flow meter at a local electronics store so I rushed there at lunch to pick up. It wouldn’t be near as accurate as the one from SwissFlow, but it would allow us to proceed with development. Later that afternoon, SwissFlow contacted me to let me know that they had reached out to one of their U.S. partners who was willing to ship us the sensors at no additional cost, which would arrive in a couple days. A couple days later the original order arrived so I let SwissFlow know, but they said that the shipment from their U.S. partner had already shipped and insisted that I keep the second order free of charge for the trouble.

Hackweek

One of the many incredibly awesome things about working at VersionOne is Hackweek. In short, it’s a week-long hack-a-thon where developers, testers, and UI/UX designers get to work on whatever, wherever, and with whomever they want. The only requirement is that we present our hack to the company at the end of the week. We began the week by finalizing our goals for the presentation. Having been through a few Hackweeks, we knew that our ambitions would far exceed our capability and time frame so we prioritized the features as follows:

• Display information about the beer on tap (name, type, and color)
• Display the keg type with an image representing the type
• Display keg volume metrics (total/remaining ounces, remaining percent, and remaining pints/bottles)
• Display flow rate as ounces per second
• Read and display kegerator ambient temperature and left and right keg line temperatures
• Respond to beer flow by modifying keg volume metrics and flow rate
• Send a keg low notification
• Change keg
  • Identify which keg is changing
  • Select new keg size and beer color
  • Enter beer information
  • Send a keg changed notification
  • Record change in history
• Persist beer, keg type and volume metrics, and history data to durable storage
• View tap history
• View change keg walkthrough or training video

We split the work for each feature so that it was aligned with our core competency. Matthew would focus on presentation, user interaction, and calculation logic while I focused on retrieving sensor data on Arduino, data transmission, and message processing on the tablet. We decided to keep the technology stack simple to avoid getting bogged down by learning a new framework and allow us to easily integrate presentation and calculation logic.

I spent the first two days creating a message format between TapBot (Arduino application) and Mobile (Cordova application) over Bluetooth. This included defining a message structure, collecting and validating message data on TapBot, transmission of the message, and data validation on Mobile. I started with a simple Hello message that would send device and application information to Mobile. Once I got that working, I started implementing the Temperature Reading and Thermometer Not Found messages, which I wrapped up at the end of the third day. I also attempted to build a test setup for the temporary flow meter using two juice containers and tubing and caulk that I picked up from the hardware store.

It worked well for a few tests, but it ultimately fell apart when the caulk got wet. During that time, I created a complete disaster of my dining room table, littered with electrical components and a ridiculous number of tools graciously loaned to me by Walker Smith, another developer at VersionOne. Thanks Walker!

 

 

Let’s just say that my family was very patient with me that week and put up with the mess I created.

Meanwhile, Matthew created the Mobile UI to display the beer on tap, keg type, image, and volume metrics, and flow rate. The goal was to provide a view into what was on tap and how much beer remained before arriving at the keg up close. This was aided by a large graphical representation of not only how much beer was in each keg, but also coloring to help the user discern the type of beer without knowing the exact beer style (lager, IPA, etc.).

The morning of the fourth day, I integrated all of Matthew’s work into the Mobile application structure. That afternoon, we met at the office to work out issues from the integration. Matthew continued tweaking the interface and I started researching how to retrieve data from the flow meter with Arduino. I was able to get readings from the flow meter using a sample Arduino sketch, but had to blow air through it because my test setup fell apart. It wasn’t ideal because controlling air pressure was much more difficult than a relatively steady flow of water, but it worked well enough to keep pressing forward. I started to incorporate the sample sketch into TapBot, but I left the rest for the next day so I could get some sleep and be fresh for the presentation. At the same time, Matthew started creating logic to calculate and update the display for keg volume metrics and flow rate.

The next morning we wrapped up our efforts from the previous day. I started working on the Flow State Changed message while Matthew corrected a couple of small UI issues. I got through validating the message on Mobile, but I didn’t have time to finish tying it into the calculation logic. The presentation time drew near, so I held off updating Mobile with the new message changes and started migrating all our equipment to the presentation area. For the presentation, we used a Chrome extension called Vysor to show and interact with the Mobile screen. Matthew introduced the project, explained where the idea came from, and talked about what features we did and did not complete. I gave a brief overview of the technology and challenges we faced and explained some of the pictures we included in the presentation. Overall, it went well and everything worked save one temperature sensor because its ground wire popped out of the breadboard.

 

 

 

 

 

 

 

Conclusion

We were able to achieve the first five goals we set for ourselves with only a couple hours of work remaining for the sixth. Ultimately, we didn’t accomplish all that we had hoped to, but that’s usually the case with Hackweek. Some would call that a failure, but that would be missing the point of Hackweek. It exists to drive innovation, encourage learning, and provide a space in which creativity can flow freely. In that regard, I think we kicked ass!

We learned a lot about the Arduino board and sensors, sketch language, and IDE. I picked up electrical engineering concepts and used a breadboard for the first time. Matthew was introduced to Cordova and I was able to use it again after not having done so for two years. You may be thinking, okay, you learned a lot, but Tapster has nothing to with any VersionOne product, and you’d be correct.

Tapster is about improving our environment, our culture, and the kegerator is an important part of that culture. It’s one of the many things, just like Hackweek, that makes us unique, makes VersionOne a GREAT company to work for. It is our commitment to innovation, shared learning, individual success, and an excellent working environment that fuels our passion to develop great solutions for our customers.

We are proud of what we accomplished and plan to continue this effort on our own time. Our goal is to install a working solution later this year with most of the features we defined for Hackweek. That wraps up this post, but stay tuned for the next installment, Tapster – Part 2: Completing the MVP and Installation.