In the previous article, we established the motivation for building a garage door opener using the Raspberry Pi along with a handful of other components. More specifically, we outlined the desired features of the opener, which includes the ability to monitor and control the door through a website. In this installment of the series, we’ll focus on the features and how they can be implemented in the Raspberry Pi. We’ll use a state machine to keep track of the garage door.
The state machine below, described using a classic “stick and bubble” notation, provides a very simple approach to describing the states of the door. Basically, the door is either open, closed or somewhere between.
With a push of a button on the remote device, the door goes from the “closed” state to the “between” state. When a detector on the door sees that the door is open, the state machine transition to the “open” state.
The state machine is perhaps too simple, because we want to account for several other controlling factors, such as the reception of commands from the website.
The second state machine below is more robust. It allows for manual operation of the garage door (e.g.; you push the wall-mounted garage door opener button) as well as remote operation through the website. It also accounts for logging of various errors that may arise; such as the implementation of a close command that fails to indicate that the door is closed after, say, 30 seconds. Finally, it allows for a starting state (initial) where the Pi program enters the state machine.
You may want to go through this state diagram and see if all possible garage door scenarios are covered.
For example, let’s say the garage door is in the “door closed” state; that is, the door is completely closed and inactive. Suddenly, a “toggle command” arrives via a command over the website, driving the state machine into the “toggle open” state. In this state, the Pi will close a relay for a half second and then open it again. This simulates the pressing of a button on your wall-mounted garage door switch. (In fact, this is how we wire up the Pi to the garage door — we simply wire the poles of a relay in parallel with your normal wall-mounted garage door opener switch.) Upon the completion of the relay toggle, the state machine automatically takes the “ok” path to the “opening” state. In this state, the Pi waits for one of two things to happen: either the “door open” detector indicates that the door is fully open, or a timer expires, indicating that the door did not open after a period of time that we deem sufficient to actually open the door. If all is working correctly, the “door open” indicator will activate before the timeout, and the state machine will then transition into the “door open” state. If, however, the timer expires first, then something has prevented the door from achieving the desired opened state. So we briefly visit the “open log error” state, where the error condition is noted in the log, and then transition to the “manual transition” state, where the Pi waits for either the “door open” or “door closed” indicators to provide the current garage door status. This could happen if, for example, the door starts to open but, by accident, someone hits the remote control device and inadvertently causes the door to pause. In any case, the Pi cannot make a decision on what to do, so it simply waits for someone to either open or close the door.
Note that this state machine may not cover all situations. We may, during the course of this project, decide to make changes to fix problems we find during test or during field trials. Well, that’s okay, because state machines are very simple to work with, and it’s fairly painless to make changes along the way. The most important concept is that we remain disciplined in our approach, and never allow ambiguity within any state. In other words, each state should define exactly – and exhaustively – what is happening with the garage door.
In the next installment of this series, we’ll take a look at how the Pi reads commands from the web and communicates – via the Observable programming pattern – the commands to the state machine. In subsequent installments, we’ll construct a set of test scenarios we can use to convince ourselves that the state machine is going through its paces correctly. We’ll also create a “virtual” garage door so that we can test out the state machine in a virtual world, rather than running everything on a real garage door and possibly burning out its driver motor.
Note that it is pure coincidence that the above state diagram sort of represents a frog. Or perhaps it represents a rather chubby fellow looking directly at you and smiling. It’s interesting, but over the years, I’ve drawn perhaps hundreds of state diagrams, and it’s just plain weird how often they end up looking like an abstract drawing. One of the more interesting diagrams I drew looked like a mad praying mantis holding a baseball bat. I’ve also drawn something that looked strikingly similar to the head of a cootie. (http://en.wikipedia.org/wiki/The_Game_of_Cootie)