As a Solutions Architect for AWS I get to work with customers of all sizes, helping them bring interesting new products to market or improve existing ones. Amazon too has a strong “maker” culture and encourages employees to innovate and show the power of the AWS Cloud. By early 2014 our San Francisco office was expanding rapidly but we still lacked the cornerstone of any self-respecting tech office—a kegerator. Given these factors we couldn’t have just ANY kegerator—the business objective being zero-downtime beer delivery. It had to connect to AWS and showcase the power of Internet of Things (IoT). The idea was simple, we’d attach a Raspberry Pi to a kegerator. A flow meter detects when a pour is occurring, posts the data to AWS Kinesis and displays the data on a web page—easy enough for a group of motivated Solutions Architects, and we had a working unit in just a few days. What follows is a cookbook to assemble your own version of what we call “Simple Beer Service” with some key learning and advances we made along the way. The end result has much more capability than the initial idea, as I’ll discuss in this post. We’ve posted the code, list of parts and materials and even the CAD file for 3D printing the case as open source (see link at bottom). All-in, the project costs were under $1,200 to build, and about $12/month to run in your own AWS account. Hopefully you’ll be inspired to tap into your own creativity and extend this project.
To make the project build process easier, let’s break it down into ‘layers’. I’ll describe each one and discuss how to assemble.
Key learning #1: Don’t buy the cheapest kegerator you can find. We’ve now built a few of these and have found that the Kegco units work quite well. The one we use is a basic single faucet model and runs about $550 plus shipping.
Specifics are listed in the Build of Materials (BOM) worksheet along with the rest of the project assets at the end of this post.
For this project we used the Raspberry Pi 1 model B+ for local compute, which is a credit card-sized single-board computer, developed in the UK by the Raspberry Pi Foundation. It leverages an ARM processor, SD card for storage and exposes several dozen pins that can communicate digitally (via +V or ground) by attaching sensors (to collect data) or actuators (to act in the physical world). It also sports an Ethernet port and four USB ports. The combination of local compute, communications, sensor collection and ability to act, all in a small and cost effective form factor makes Raspberry Pi a popular choice for IoT projects. What tipped it for us was the fact that there is a well-maintained version of Debian Linux called Raspian, which meant that it was easy to get started, and there is a strong foundation, a large community of contributors all supporting a reported five millions units sold. Getting started with Raspberry Pi is quite easy with instructions that can be found here.
One powerful feature of the Pi is the row of GPIO (general purpose input/output) pins along the edge of the board. These pins are a physical interface between the Pi and the outside world. At the simplest level, you can think of them as switches that you can turn on or off (input) or that the Pi can turn on or off (output). Seventeen of the 26 pins are GPIO pins; the others are power or ground pins (we only used the first 26 pins in this project). Key learning #2: The first unit we built in Spring 2014 tied the various electronics together with a small solderless breadboard connected to the Raspberry Pi via a special ribbon cable and each sensor then connected to the breadboard via jump wires. This approach is fine for prototyping a system but we’ve found that over time the wires tend to come loose and cause problems. The second unit we built was for the Developer Lounge at re:Invent 2014, which is the annual AWS user conference in Las Vegas, Nevada. We built this unit in San Francisco and then shipped it to Las Vegas via truck, I was worried that the wires would shake loose in transit. This gave me the excuse to try something that I had wanted to do for a long time – make my own Printed Circuit Board (PCB).
The plan was to replace the breadboard with a custom PCB and instead of jumper wires all the components would be connected by soldered wire connections. The process of making your own PCB at home is very similar to how the big vendors do it, but of course at much smaller scale. The way I did it (learning from YouTube videos) was to first design the circuit on a computer. Once designed you then print it in reverse on a laser printer using clear plastic overhead projector film. The laser toner is then transferred to a PCB blank (basically a sheet of plastic with a coat of copper on one side) by heating the print onto the PCB blank with a household iron. Once the toner is transferred to the PCB blank, the final step is to place it into an “acid bath” for half an hour or so, until all the copper not covered by the laser toner is eaten (etched) away. In my case I used a combination of Muriatic Acid and Hydrogen Peroxide (dangerous stuff – be sure to wear rubber gloves, eyewear and take appropriate precautions). In the course of my PCB manufacturing I ruined an iron and burned a hole in my carpet but successfully made the custom PCB that made it to Las Vegas and back and worked like a charm.
Which brings us to Key learning #3: There’s a much easier solution—the Grove System. Much like Lego, Grove simplifies the building process significantly. The Grove system consists of a base shield and various modules with standardized connectors. The base shield allows for easy connection of any microprocessor input or output from the Grove modules, and every Grove module addresses a single function, such as a simple button, LED or a more complex proximity sensor. Specifically we used the GrovePi+ board that attaches directly to the Raspberry Pi and exposes the PINS as an easy-to-connect cable system.
With the GrovePi+ board attached directly to the Raspberry Pi it was then very easy to connect our array of components via four-wire Grove cables.
Sensors and Actuators used:
With Raspian installed on the Pi this brings us to the GrovePi open source platform from the good people at Dexter Industries. GrovePi is a software framework that can be programmed in Python, C, C#, Go, and NodeJS. The key benefits of the GrovePi framework is that it is aware of the pin designations of the GrovePi+ board and true to the benefits of any software framework, reduced the total amount of code we had to write. We chose to use Python. And, to make it as easy as possible to get started, we’ve created an installer script that will download the pre-requisites and configure the Python code with prompts for key configuration options. In addition, the AWS CLI and AWS Python SDK are installed, making it convenient to communicate with the AWS cloud. Use of limited-scope AWS Identity and Access Management credentials ensure that each unit has only the minimum privileges required. This tees up the next topic, IoT Cloud Architecture.
(Image:The Simple Beer Service Internet of Things reference architecture)
Implementation details for the dashboard portion of the project can be found on the AWS Labs site. This architectural pattern follows the design presented by an AWS Solutions Architect colleague and can be found here. By following a layered architecture approach we were able to iterate rapidly and take advantage of new capabilities by swapping pieces as we went, without changing the overall architecture.
We wanted the overall look of the result to be smart, which meant that the project case needed to look like a finished product. And, of course we had to have switches, buttons and blinking lights. For the first unit we purchased an aluminum project case to house the Raspberry Pi and the associated electronics. It was basically a metal box about 10 inches tall, 10 inches wide and about four inches thick, that we drilled, cut, painted and otherwise forced to fit our need. We then drilled a hole in the side of the kegerator where we passed sensor wires and attached the case to the kegerator with screws (which required more drilling). While it worked, this approach certainly wasn’t going to scale. By the end of 2014 there was a lot of interest from other AWS offices and customers in having their own units, so we needed a new approach and redesigned case. Key learning #4: the case was the hardest part of the project and needed to be specially designed and 3D printed.
The case, of course, needs to be appropriate to the physical environment the IoT device will reside in. In the case of consumer electronics, ergonomics and overall design aesthetics are available via 3D printing (which can be 9.9 L x 7.8 W x 5.9 H in). We didn’t know this, and sent our project files off to an online print service. In short, that was a bad experience. The good news is that the folks at Atypical Products in Redwood City, CA (co-located at TechShop.ws) took up the challenge and created a spectacular design that is open source.
It is amazing how fast this space is evolving. Hardware really is becoming more like software. In just a little more than a year, it has become far easier to go from an IoT idea to something that looks and works great. While certainly not a mass-production-ready product, this project demonstrates what can be done with affordable and currently available technology and services. The use of the AWS Cloud for heavy lifting combined with the decreasing size and cost of IoT devices is a powerful combination. The best part of this project though was the commitment to quality by the team, as demonstrated by many cycles of testing and data generation. ☺
More information and project assets can be found at the AWS Labs github repo
By Todd Varland Solutions Architect - AWS