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

Project overview

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:

Schematic

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

LEDs on the breadboard connected to GPIO pins.

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).

Wormhole address

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 !

Results

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.

Browser - Closer look

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 - Closer look

"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.