Asynchronous Drip Coffee - Coffee Interface - Architecture

We're going to begin with the interface to the drip coffee machine itself, where the fun is (no offense to Android app developers and backend people, but mucking around with hardware is what I get a kick out off) !

Before we start doing any implementation, it's always important to first plan out how we're going to implement the interface. The implementation plan will attempt to answer the following questions:

• How will commands be sent from the Android app to the coffee interface to turn the coffee machine on and off?
• How will these commands from the Android app be converted into an actual mechanism to turn the coffee machine on and off?
• What are the safety concerns of our application and how will we attempt to address these concerns?

For each bullet point, it's important to keep cost and effort of implementation in mind. Since this project is for an individual hobbyist, we want to keep the implementation as simple as possible without sacrificing the learning experience. 

The answer to the first question is very simple. We're going to create an Android app that will interface with a server that is running on our local network (inside our house). The server will in turn send a command to the coffee interface device to perform some action on the coffee machine itself.

The answer to the second question is more complex and has multiple hardware and software components, described as follows:

• Wandboard Quad (http://www.wandboard.org): Will interface with the server to receive commands to interact with the coffee machine. An overview of the software running on the Wandboard Quad is as follows:
• YoctoProject image of Linux that has a Python application running using the Twisted framework, which will make it easy to interface with the server.
• A custom device driver that we will write to interface with the lower level board. The device driver will receive commands from the Python application and convert them into data that the lower board can understand using a serial communication protocol called I2C.
• Arudino Micro (https://www.arduino.cc/en/Main/ArduinoBoardMicro): Will receive commands over the I2C bus, parse the commands and interact with the hardware protection circuit to interface with the coffee machine. 
• Hardware protection circuit: The actual circuitry that will make physical contact with the coffee machine and either turn it on or turn it off. This circuitry is crucial because it will ensure that any external stimuli from Arduino Micro board don't cause any hazardous conditions. 

Each component has a different set of challenges that we will address as we work on each component. We'll start from (what I consider) the easiest component - the Linux component - and work our way down to the most challenging and difficult component - the hardware protection circuit!

Asynchronous Drip Coffee - Overview

The first project that I thought of working was born out of the fact that timer-based drip coffee machines don't allow leeway in when you wake up. For example, if I set the coffee machine to start at a certain time, I can't hit the snooze button on my alarm nor can I even dismiss the alarm as my coffee will get cold.  To address this issue,  I sought to implement a system that would allow me to start the drip machine asynchronously. Essentially, the high level description is that I would hit a button on an app running on my phone which would cause a device connected to the coffee machine to turn it on. These is a fun project because it has the following moving parts that need to be addressed in terms of safety and security:

• Device that is connected to the coffee machine responsible for turning it on and off
• Android app (sorry iPhone users)
• Server running at home that interfaces with the Android app and device connected to the coffee machine

Hello Embedded World!

Hello Embedded World ! I am Mohammed Billoo (http://www.linkedin.com/in/mbillpub) and the purpose of this blog is to describe the projects that I'm working on in my spare time. The idea for these projects are usually conceived by an inconvenience that I face around the house or in my personal life and I try to use my knowledge of embedded systems to alleviate the inconvenience. The idea for this blog came about when I realized that although there are a multitude of resources online that can help someone solve a single problem most likely faced by an experienced engineer, there is no resource that allows someone to get their feet wet and understand the type of problems that embedded systems attempts to solve. This blog also serves as a platform for individuals to follow along in replicating the projects that I work on here, to ask questions about certain decisions and problems they run into, and hopefully provide insightful alternatives to the decisions that I make in these projects.

While these projects are fun and exciting, they do involve hardware and interfacing with personal appliances. Therefore, I have to disclaim that you are responsible for taking the utmost safety and care when working on these projects. I am not liable for any injury to yourself or damage to your personal property that any of these projects may cause.

With that said, let's get started!