Raspberry Pi / CuPID WebIO by database: Javascript/jQuery, Apache, & Python

The IoT is coming! The IoT is coming! If you’re anything like me, you hate buzzwords like the Internet of Things (IoT). The concept behind this one, however, is simply hard to deny. EVERYTHING should be networked and controllable by a mobile device, even if only on a local network. It’s inarguably the future. Now, while some will argue there is still a place for developing platform specific applications for things like iOS and Android, we ignore all that and go with 100% HTML5. In the age of media queries, we don’t think there is any reason everything shouldn’t be cross-platform compliant and beautiful everywhere.

Coding for the Raspberry Pi was no exception. People are doing all sorts of crazy stuff, from node.js, websockets, calls to C from php, you name it, just to be able to control the Pi from a web interface. A noble undertaking for sure, and one might argue that desperate times call for desperate measures. One of the core problems is that reading and writing from the GPIO requires access to /dev/mem, which can create all sorts of problems. You don’t want www-data (web apps) to have direct access to this stuff. On other platforms (and with other languages), you can wrap up your script in a way that will allow you access to these features without running as full-blown root, but with debian there is simply no way to do this for python scripts. This is sad, in a way, as RPi.GPIO, the most popular, widely used, and easily to implement API for controlling and reading GPIO, must be run as root … which means no web GPIO. On the other hand, the reason that wsgi and other web functions don’t let you run as root is because it’s dangerous. BAD THINGS CAN HAPPEN.

A way around this that solves many many other control issues at the same time is to use an intermediate database to store commands and data. This brings with it all sorts of bonus features like logging (necessary for things like PID), foreign key constraints, restricting which combinations of conditions can exist at one time, group disable/enable, fail-safe conditions, and all sorts of other goodies. It’s moderated access to very important things on our little Pi. So this is what our model looks like:

Full MVC for control of IO on the Raspberry Pi, as used in CuPID Controls

We’ll also discuss a stripped down version of this that you can try very quickly to give yourself an interface to your Pi IO, much like WebIOPi. We show the specific files here, and it’s instrumental to get the hang of how these gears turn together.

CuPID MVC Model for IO Control on the Raspberry Pi


The idea is pretty simple. Use css to make a pretty web page, jQuery to make interactive elements and to send the data by POST, pick it up in Apache/wsgi in Python, and read/write from/to a database (we use sqlite here). Asynchronously, run a Python script in the background that both updates io with set values from the database and also reads back read values into it. Simple, right? It really is. Here’s a screenshot of what you get with a super-simple example, and take a demo here (yes, that’s running on a Pi)>

Simple rawio web page for Raspberry Pi : all jQuery and Apache no node or websockets.
Simple rawio web page for Raspberry Pi : all jQuery and Apache no node or websockets.


We’ll drop some more knowledge in here, but for a quick run-down of the install, check here:

4 thoughts on “Raspberry Pi / CuPID WebIO by database: Javascript/jQuery, Apache, & Python”

  1. Possibly, but you’d need to take some time to nail down your timing as best possible. You’re waiting for three steps:
    – Apache to run wsgi script
    – Wsgi script to run db query
    – Script to operate robot based on db query

    Because the first and third must be different scripts (so that GPIO may be run as root), you’d need to have the third running constantly to register changes to the database entry. This will consume resources and slow down the other two processes, so it would be a balancing act. Depending on what your robot is doing, a 200ms response time may be unacceptable, which is where the challenge lies.

    For this application, I would be tempted to wrap up a call to GPIO in something executable by www-data for direct manipulation. It’s something I’ve been meaning to look at anyway for just such an application. I believe wiringpi may be a route. I’ll post when I have a look at it.


Leave a Reply

Your email address will not be published. Required fields are marked *