WebSockets, Raspis, And GPIO


A while back, [Blaise] tried his hand at getting the WebSocket protocol working with PIC microcontrollers, WiFi adapters, and a few pots, knobs, and switches. It was an excellent project for its time, but now [Blaise] has a Raspberry Pi, and the associated GPIO pins and Ethernet connection. He decided it was time to upgrade his build to the Pi, this time with a project he calls PiIO.

The basic idea of [Blaise]’s project requires a Pi, a server, and a computer running a browser for the end user. On the Pi side of the build, [Blaise] connected a Microchip MCP3008 eight input, 10-bit ADC via the SPI bus. The Pi takes the ADC sensor values from pots, buttons, or any other analog source and sends them to a server with the WebSocket protocol.

The server hosts a web site written with Django, Autobahn, and Python to communicate with the Pi and host the web page for the data received from the Pi. There’s support for multiple Pis in [Blaise]’s build, making complicated projects we can’t even conceive very possible.

[Blaise] put up an awesome demo video of PiIO up; you can check that out after the break.


6 thoughts on “WebSockets, Raspis, And GPIO

      1. He wont. They never do.

        Pedantry ACTIVATE!!!

        also…there is no such thing as a ‘http stack’. It is an application layer only protocol that significantly relies on TCP though ICMP and others, but can be implemented differently. Thus why it is such a layered approach.

        See http://tools.ietf.org/html/rfc2616 for more details than you will ever ever ever want to know.

        Pedantry man, AWAY!!!

    1. This is true. In fact I did a project that hackaday hosted a while back that’s almost as you describe.

      Using the RPI allowed me to use Python and gave me access to the most up-to-date WebSocket libraries.

      It also allowed me to easily generalize the project. Allowing you to re-use the project for a variety of purposes without the need to write any code.

      Not to mention all the other advantages you get from using a device running a linux kernel, such as threading, and scheduling.

      If your intention is only to control one device for a single purpose in a more permanent setting a microcontroller solution is more ideal.

      The server can run on the RPI, but It’s not designed to. I designed this project to allow you to use any number of RPIs to provide scalability, thus it didn’t make any sense to put the server on the RPI.

  1. Very well done, the idea of moving the configuration off the rpi makes it much less annoying when the SD dies, which sadly happens too often when power is lost while running.

    There is ofcause still some network setup, but if the network supports DHCP and config is saved with mac address, it should be plug’n’play from a “factory” sd card.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.