Control Raspberry Pi GPIOs with WebSockets

Remotely control LEDs attached to Raspberry Pi GPIOs using WebSockets and dataplicity wormhole.

Overview

There are four components in this system:

• Breadboard with LEDs attached to GPIO on a Raspberry Pi
• Web application on Raspberry Pi
• Websockets server application on Raspberry Pi
• Internet browser

This example uses both HTTP and WebSockets where:

• HTTP is used to serve a website from your Pi which comprises some static HTML and JavaScript files.
• A WebSocket is then used to transmit LED ON/OFF commands to the server.

Once the static webpage is loaded into the browser, you will see some ON/OFF buttons to control the LEDs. After loading the page, some JavaScript code running in the browser will open a WebSocket connection back to the server application running on the Pi. When you click one of the buttons, an instruction to enable or disable an LED is sent via the WebSocket to the Pi, where it is processed and the LED state is adjusted.

Connect the LEDs to your Raspberry Pi GPIO

We start by assembling our LEDs on a breadboard as shown in schematic below:

Note that in this example we have chosen to connect our LEDs to pins 16 and 18 on the Raspberry Pi.

You can verify that LEDs are working by running the python script below:

#!/usr/bin/python
import RPi.GPIO as GPIO
import time
#Set GPIO pins as outputs
GPIO.setmode(GPIO.BOARD)
GPIO.setup(16, GPIO.OUT)
GPIO.setup(18, GPIO.OUT)
#Switch GPIO pins ON
GPIO.output(16, True)
GPIO.output(18, True)
#Wait 5 seconds
time.sleep(5)
#Switch GPIO pins OFF
GPIO.output(16, False)
GPIO.output(18, False)
#Reset GPIO pins to their default state
GPIO.cleanup()

Get a Remote Shell

To get remote access to your Raspberry Pi please visit www.dataplicity.com(free sign up) and follow the installation instructions to get remote terminal access to your Pi.

When done, locate your device in your dataplicity account and click “Enable wormhole”. You’ll then need the wormhole address which can be found just above the remote shell (see below).

Run the project.

Step 1 : Click the link below to download all the code necessary for this project.

PROJECT CODE

Step 2 : Run the server.

If you don’t have tornado framework installed for python please type in the command below.

sudo pip install tornado

Open the “ws-webio” directory in terminal and run the command below.

sudo python server.py

When done you should see a printout informing you that Tornado server has started.

In your browser type in:

https://<your_unique_number>.dataplicity.io

example:

https://1234567a.dataplicity.io

If the webpage loads correctly you should see it in your browser and get additional printouts in your terminal.

Click the buttons on the page to switch ON/OFF the LEDs !

Taking a closer look

Now that you’ve got the project set up and running if you would like to know a bit more on how it works “behind the scenes” please read further.

Inside the web browser

On page load:

1. HTML and JavaScript files are delivered through the HTTP connection.

2. The browser renders HTML, then JavaScript.

3. The running JavaScript creates a WebSocket connection.

After all the files have loaded, the browser component looks like this.

Note there are two communication channels with the Raspberry Pi — one for the static files and one for the long-running WebSocket command channel.

Inside the application server (Tornado)

In this example, the web application server is running inside a Python web framework called “Tornado” (see http://www.tornadoweb.org/en/stable/). All of the files are prepared in the “ws-webio” folder, with “server.py” hosting the receiving end of the WebSocket.

The diagram below illustrates what is happening inside “ws-webio” folder when the “server.py” application is running, and how each piece of code interacts with each other.

“server.py” comprises:

• An HTTP Server (part of the Tornado framework). This server listens for client connections and forwards them to the core application.
• A Tornado application. This sits inside the HTTP Server and maps given routes to “handlers” for further processing.
• Application settings which tell the application where to find resources, such as the static files we intend to present to the web browser.
• Handlers. This is where the magic happens: when your browser sends a request or an event, handlers are where these requests or events will be processed. In this application, the handlers are responsible for both returning the static files to the web browser upon request, and also for operating the receiving end of the WebSocket and controlling the local GPIOs.