IoT Web Server

This article is part of a series with the name IoT Remote Power Switch – Project Part 2.

After having written two posts it turns out that this topic will touch more aspects of technology, architecture, design and programming than I was aware of. It seems I can’t achieve my initial goal of writing maximum five articles. Well, one of the reasons for starting this exercise was exactly to find out how much is really involved.
Nevertheless, I’ll go on and document my work with technical articles in hopefully sensible junks. You, as a reader, can skip articles or abandon the series at any time anyways. This relieves my conscience since I certainly don’t want to bore you.

The IoT Web Server

The web server is the central part of the IoT project. It communicates with the web browser and the embedded computer. Without it, the browser can still be used to visit other pages, and the embedded computer may still switch the heater on or off, following programmed rules (day-time, for example), but the whole interactive aspect would disappear.


Again it’s best if I write down what the web server should be capable of, before thinking of anything else. Looking at the overview diagram once more, I see that (below the blue web server box) it states

  1. Provides a web page for the mobile phone
  2. Communicates with the embedded computer

Since I’ve created the web page (front-end) already (see previous post), I know that the web server shall support ordinary pages, meaning HTML5 and CSS3.

Item 2 in the above list is yet a bit fuzzy. How would the two computers (the embedded computer and the web server) communicate with each other? To this question I have got a definitive answer: through a REST API using JSON formatted messages.
In short, a REST API supports stateless request/response transactions. The resources on the server are identified by the URI (for example /rps/status) and acted upon using standard HTTP verbs (such as UPDATE /rps/status).

There are, as always, other possibilities how the two computers can exchange messages. But since this article is about the IoT, the HTTP protocol combined with a REST API and JSON makes most sense. Instead of JSON, plain text, binary, HTML or XML message formats could be used. However, JSON is simple, small in overhead and does the job well.

Does the web server require a database? On a first glance it could seem that it doesn’t. The way I’ve defined the front-end, a click on the ON or OFF buttons could go to the web server, which in turn would issue a request to the embedded computer. It would then wait for its response and return the status to the browser.
However, a REST interface doesn’t work that way. It works the other way around. It’s the embedded computer that talks to the server and expects a response from it. For this reason, the server needs to store the user request issued through the browser, and only when the embedded computer polls the desired status (ON/OFF), the web server will forward the user request to the embedded computer. The latter will in turn process this request and return its new status (heater ON or OFF) to the server.

Since a REST API implies that the server logic is stateless, the server does require a database. It stores the latest user request, as well as the latest status update by the embedded computer. Naturally, it won’t store the latest updates only, but all of them in history. This information can then for example be used to calculate the energy consumption of the heater over the past day, week, month or year.

Computed feature list:

  • Support ordinary HTML5 and CSS3 pages
  • Open for the implementation of a REST API
  • Provide connectors to databases

Selecting a Web Server

Browsing the web, I realize that dozens of web service frameworks in all sorts of programming languages exist. Most of the frameworks aren’t five years old. Ups. Which one is best suited for my IoT Remote Power Switch solution? I came to the conclusion that the answer is … many!

The field is vast, ranging from PHP frameworks over Ruby (on rails), Java application containers, Python frameworks to JavaScript interpreters. It’s essentially a matter of taste which one to choose. Or, if less freedom exists, a matter of the current knowledge and experience.
In my case, I would feel most comfortable with a Java based web server like the Apache Tomcat. Nevertheless, I decided to go for an inconvenient solution: Node.js.
Node.js bases on Google’s JavaScript Engine V8 used inside Chrome. It interprets JavaScript programs and runs on all major operating systems. Along with it come some tools. The only mandatory one is npm, the Node.js Package Manager. Others, like nvm (Node Version Manager) and Express.js (a web application framework based on Node.js) are optional. I don’t use them for this project (on Express.js I am not sure yet).

Selecting a Database

It turns out to be a similar task as the one above. It is a bit simpler to me however. I won’t go for a youbeedoubee database invented by a few students two years ago, just because it’s super fast. I want it to be of modern design, good quality, well supported, backed by a company, and it shall provide drivers for all established web frameworks (for if I ever decide to exchange Node.js).
MongoDB is my choice. Others would the job do as well, but for whatever reason, for now it’s MongoDB.

Selecting an Operating System

Since I am going to deploy the web server to a Internet Service Provider later, I checked what OS potential provides offer. Currently, there aren’t many providers that allow me to run a Node.js server combined with a MongoDB instance for reasonable money. The one I found and like runs Linux, thus I’ll use Linux too. My current installation is Ubuntu 14.xx LTS.


That leaves me with the installation of the following components for the IoT web server on my Ubuntu development host:

  • npm
  • Node.js
  • MongoDB

That’s the topic of my next post.