The 4D Systems’ IoD-09TH is a fantastic device, and we love it. Our code is also suited to most ESP-based WiFi chips.

BUILD TIME: 40 minutes (including Part 1)
DIFFICULTY RATING: Intermediate

We kicked off this project in Issue 9, but we wanted to do more, so this month we’ve extended functionality with a web server and relay output. We’ve also added data logging functionality, and adjustable temperature thresholds from the web server.

SO WHAT’S NEW?

WEB SERVER: An interactive web server that shows the current temperature and humidity. It has controls to raise or lower the upper and lower temperature thresholds and it can also trigger a relay to call for help in an emergency.

DATA LOGGING: Temperature and humidity data are logged in the cloud using ThingSpeak.

TWITTER ALERTS: Over-temperature and under-temperature alerts are sent via Twitter.

RELAY TRIGGERING: A relay can be triggered on detection of excessive temperature.

NTP TIME SYNC: Date and time synchronised to an NTP server.

All this is achieved using the same breakout PCB published in Part 1 (Issue 9), and all of the electronics are mounted on our 4D Systems IoD09 breakout module, excluding the source of our 5V power.

THE BUILD

The build is fairly straight forward. For the PCB design, please refer to part 1 in Issue 9.

HOW IT WORKS

We’re bringing together a few different technologies here into one project. We’ll go through them briefly before demonstrating how they come together in the main sketch.

LIBRARIES FOR THESE PROJECTS

This project uses a number of libraries, which can be downloaded:

THINGSPEAK: https://github.com/mathworks/thingspeak-arduino

TIMELIB: https://github.com/PaulStoffregen/Time

ESP8266: https://github.com/esp8266/Arduino

GFX4DIO9: https://github.com/4dsystems/GFX4DIoD9

Using these libraries makes all sorts of updates and functionality very simple. We’ll take a look at each of the utilities we’ve integrated, but they’re all quite simple so feel free to have a play with the code yourself, to further extend and expand functionality.

WEB SERVER

Every five seconds the DHT11 sensor is read to get the latest temperature and humidity data. ThingSpeak will accept data updates no less than 15 seconds apart, therefore each 15 seconds we record the latest temperature or humidity data. While there is a facility to write multiple values to ThingSpeak in one operation, for some odd reason this is not supported when using an ESP8266 for WiFi. Due to this we alternate between recording temperature and humidity.

Every five seconds or so, the web server itself updates its displayed values without interaction from our sketch. This is done automatically in-browser, using simple refresh meta tags. You can connect to the web server by typing the IP address displayed on the IoD’s screen. This is one major advantage of having a display on the unit, as the IP address may change from time to time.

We use the ESP8266Web server.h library to construct a web server on our local network. Building and updating a web server requires a little unusual code in setup().

server.on("/", handle_root);
server.on("/fetch", fetch);
server.on("/update", updateValues);

As you can see, we’re calling three different functions that read and write to the web server.

handle_root(): as the name implies this function sends data from the main or root page to the user's browser.

fetch(): sends date/time, temperature and humidity data to the server.

updateValues(): called when the root page controls (e.g., temperature threshold) is changed.

DATA LOGGING WITH THINGSPEAK

This is a free service that allows you to record up to 8 sets of values on their servers every 15 seconds. The data stored there can be displayed in several graphical formats. You are allowed 3,000,000 messages per year, which should be enough for anyone, at least for this type of purpose.

To use ThingSpeak, you need to create an account. This will create a channel (there are well over 400,000 active channels) to record your data and generate a pair of keys: “Write API key” and “Read API key”, which are used to read/write your data. Using ThingSpeak with any Arduino compatible board is relatively straight forward, as there’s a library to do so, which simplifies things tremendously! To write a value to ThingSpeak, we use:

ThingSpeak.writeField(myChannelNumber, 1, dat[2], myWriteAPIKey);

Of course we have created the variables “myChannelNumber” and “myWriteAPIKey” so we don’t have to repeat them every time, while “dat[2]” is the temperature read from the DHT sensor.

There are facilities to read our data but for our purposes, we can view the data online. With our IoD device we’re only looking to push the data somewhere.

We’ll go over ThingSpeak in the code section below, but if you’d like to know more details about ThingSpeak, our Secret Code column will take a more thorough look at this in the next issue (Issue 11).

SENDING A TWEET

In this project we use ThingTweet, which is part of ThingSpeak to send over-temperature tweet alerts if necessary. To use Twitter and ThingTweet you will need to set up an account on Twitter. During the setup process, it will generate a unique API key for you, which is used in the process of tweeting.

Note: Twitter will not send duplicate tweets like “Excessive temperature detected”. It’s normally necessary to ensure it’s unique, so it’s not filtered automatically by Twitter. Otherwise you adding the detected temperature won’t really help, as it will likely be the same for several readings. Adding the local time and date does though, so that’s what we’ll do.

TEMPERATURE THRESHOLD TRIGGERS

We regularly check for over-temperature and under-temperature conditions. If one should occur, we call checkOvertemp(). This function sends an alert tweet and triggers a relay. The relay could light an LED, ring a bell or whatever you like. The threshold itself can be adjusted by the web server, and you can append whatever functionality you’d like to do by adding code to the checkOvertemp function.

THE MAIN SKETCH

We have incorporated all of these functions into one sketch, so it’s easy to take a look through it and see what’s happening. We won’t go through it all, but we’ll explain a few useful lines below.

Like any other Arduino-like sketch we start by defining the libraries we’ll use (you’ll need to download them via the links provided earlier, if you don’t already have them). You’ve no doubt included libraries before, but this sketch is a little unusual in that it “imports” a text file that is actually HTML and JavaScript. This is used by the web server code, and helps you keep that code separate from your sketch.

#include "ThingSpeak.h"
#include <TimeLib.h>
#include <ESP8266WiFi.h>
#include <ESP8266Web server.h>
#include <WiFiClient.h>
#include <WiFiUdp.h>
#include "GFX4dIoD9.h"
#import "index5.h"  // Our HTML webpage contents

We also include the API keys and such as variables, to make handling them easier:

const char * myWriteAPIKey = "mySecretKey";
String API = "mySecretTwitterAPI";

It’s worth noting that the text to be included in a tweet, cannot use the space character. HTML treats a space in a very different manner to English, and this is exaggerated in any type of URL. We therefore use tweet.replace(" ", "%20"); which converts the spaces to ASCII. To handle this in a more comprehensive way, most languages which deal with web technology (that's basically everything now) offer a urlencode type function, to convert any non-compliant characters to URL-compliant versions.

Our main loop is quite straightforward. It gets the date and time each second. So every five seconds, the DHT11 is read and we check for the monitored temperature being in excess or below the minimum of the preset thresholds. We also read the web server every 10 seconds, for possible over or under temperature threshold setting changes. Each 15 seconds, we write either the temperature or the humidity values to ThingSpeak. Take a look through the code available in the resources; you should be able to follow it fairly easily.

Note: During testing we found an odd and very intermittent issue that did not occur when we built the original Arduino UNO based prototype. The issue is that occasionally, the temperature is reported as 64, 128 or 192°C. The preceding and next readings will be normal.

Astute readers may have noticed that these values are powers of two, and may be due to the slight inaccuracies in timing caused by using the internal clock as distinct from a crystal. As these readings are completely spurious, we trap them and simply ignore them. If the site you are monitoring really is 64, 128 or 192°C, you would have been alerted well before getting to this temperature.

WHERE TO FROM HERE?

The sky is the limit with a setup like this. It’s really only limited to your imagination. The breakout board provides useful IO functionality for relay triggering, and so much more.

Of course, there’s no server security, so anyone on your local network can adjust the temperature thresholds. There are several ways to handle this, but we’ll tackle the idea of locking down a server in a future article.

Part One: Temperature Display and Breakout Board