Applico is Tapping the Connected Keg

While Applico is a services company, we are constantly evolving and expanding our reach beyond current trends in platform development. Our most recent project is Pour, a connected keg prototype. written entirely by our interns James Liu and Philip Xu, with help from myself and leadership from Matt Powers, Matt Kofman, and Arun Venkatesan.

Pour itself is a keg companion app designed to monitor beer consumption. Pour yourself a drink from our connected keg while you’re logging in to Pour, and you can see the beer filling up on your screen while you’re filling your cup from the keg.

Pour also has a personal stats screen show your most recent pour, how many pours you’ve made over the last 24 hours, your current rank on the company leaderboard and your total number of pours.

We also implemented a stats page using the Shinobi Charts library to display keg and carbon dioxide levels to the user inside of the app.

Pour was designed to utilize the latest and greatest in iOS, Cloud and Analog sensor technologies. The ultimate goal was not only to advance our familiarity with the latest connected tech, but also to open-source the entire project (server code and iOS companion app) for others to use. We saw that other connected keg solutions were incomplete or didn’t have proper documentation, and we wanted to step in and provide working server and app code out-of-the-box. The project also allowed us to continue to work with the Raspberry Pi computer, and improve upon our previous iBeacon project, Kevin Beacon.

Alongside a handful of hardware components, the Pour system uses a variety of different programming languages and technologies. We used Objective-C for the iOS app, Python and C for the hardware driver code on the Raspberry Pi, and JavaScript for a Node.js backend rolled completely from scratch. This app also wouldn’t be possible without various cloud services, such as Heroku for hosting our backend, mongoDB for providing a non-relational document data store, and Keen.io for data analytics.

Our original user flow was as follows:

The Raspberry Pi would broadcast a UUID signal for the iBeacon. If the device was in range of the Bluetooth signal, the app would alert the user that a keg had been found. The app would then authenticate with Twitter, using the user’s account credentials to create a user session to track consumption.

If the user wished to pour a drink, they would press a button in the app that would send their information over the local network to the Raspberry Pi. The server code on the Pi would receive this user information, record the temperature and humidity inside of the kegerator, and then run code to track the user’s pour. When the user had finished pouring a drink, the Pi would send the combined user and pour information to a Heroku server running our custom Node.js code. The information would then be sent to two data stores: first to mongoDB as a persistant store, and then to Keen.io for analysis. The app would track a user’s previous pours and a leaderboard of top consumers from that particular keg.

Sound confusing? You bet it was! This was our original system architecture diagram:

We realized this setup had too many moving parts. In the future, we plan on having Heroku control the user sessions to keep communication between each individual component to a minimum, and it will adhere to standard Model View Controller programming guidelines. The consumer app would start a user session, and the Pi would add additional information to the already existing user session and close it following a successful pour. Heroku could create a queue of users waiting to use the system and display the order on a web status panel located near the keg.

Our new system architecture will look like this:

Integrating all of these technologies seamlessly into a complete app was not easy, and we faced quite a few challenges along the way. Configuring the driver code for the liquid flowmeter was probably the hardest part. The hardware components required low-level C libraries to facilitate the GPIO connection between the component and the Pi, so we had C binaries for the flowmeter and the temperature and humidity sensors.

The Pi server code was written in Python, so we used the subprocess module to create new processes for each C driver binary and capture the output from each hardware component. This was also our first time working on a project where an iOS app and a Python server had to communicate with a Node.js backend and other cloud services. Our interns had no experience with Node.js or Python prior to this project, and everything was written in a learn-as-we-went fashion.

When we demoed the prototype in front of the entire company, we were able to get direct feedback on the app and test with a larger pool of devices than we had been using previously. We ultimately found additional test cases, such as what happens when several devices try to connect to the Raspberry Pi at once, or how our leaderboard screen would handle tens of users’ stats at a time. The demo was a learning experience on how important rigorous testing is to the development process.

We hope to continue working on Pour internally as an intern project. We have not finalized the future iterations of the project, but we have drafted up three additional phases, which are outlined below. We would like perform formal user tests on the entire system and identify our clients’ needs before finalizing a complete roadmap. This post and the source code provided mark the end of Phase One.

In Phase Two, we hope to continue to debug the app while adding additional features, such as a new user tutorial, age verification, and email alerts warning of low beer and carbon dioxide levels. We also hope to harden the materials on the Raspberry Pi by protecting the device and loose cables. An administrative web portal and Android version of the app are also planned.

Phase Three entails the installation of a perfect pour mechanism for a hands-free pour. After authenticating with the app, the Raspberry Pi would use a sensor to detect if a cup is under the tap, and a mechanical pour device would dispense exactly ten ounces, or any other administrator-defined amount. A sobriety test would also be implemented, forcing the user to answer a math question or draw a straight line to obtain an additional beverage if more than four drinks were previously poured in the past hour.

Phase Four is the platform stage. We hope to have stabilized the system enough to use our connected keg at tech meetups, bars and breweries, putting a new twist on the keg experience.

Overall, we are very happy with the progress our interns have made on Pour over these past few weeks. This was a great project for our interns to learn hands-on iOS and server-side technology experience. At Applico, we encourage our developers to learn new technologies while continuing to harden their existing skills. Pour is a perfect example of combining different technologies into a single project, and forcing developers to think outside of the box to integrate them correctly and successfully. We are excited to release the code at this point, and look forward to iterating on this project continually over the next few months.

You can take a look at the project in its current state here.

Please note that this is the initial commit of code by our interns after a few weeks of hard work. Applico iOS developers are currently in the process of cleaning up the code, and a more stable version of the Pour system will be released in the near future.

Happy hacking!

Interested in applying to Applico? Check out our job openings here!

Filed under: Applico in the Press, Product Engineering | Topics: connected revolution, connected tech, engineering, iBeacon, raspberry pi