Sams Teach Yourself Arduino Programming in 24 Hours (2015)

---

In the previous hour, you saw how to use the Ethernet Shield to communicate on an Ethernet network from your Arduino device. That opens a whole new world of ways for you to communicate with your Arduino projects. This hour expands on that by showing how to provide sensor data to remote clients by using the Arduino as a web server and also how to control your Arduino from a remote client.

The Web Protocol

Thanks to the World Wide Web, the Hypertext Transfer Protocol (HTTP) has become the most popular method of transferring data on networks. Web browser client software comes standard on just about every workstation, tablet, and smartphone device. You can leverage that popularity with your Arduino programs by incorporating web technology to interface with your sketches.

Before you can do that, though, you need to know a little bit about how HTTP works. This first section walks through the basics of an HTTP session, and shows how to transfer data using HTTP servers and clients.

HTTP Sessions

HTTP uses a client/server model for transferring data. One device acts as the server, listening for requests from clients. Each client establishes a connection to the server and makes a request for data, usually a data file formatted using the Hypertext Markup Language (HTML). If the request is successful, the server sends the requested data back to the client and closes the connection. Figure 22.1 demonstrates this process.

FIGURE 22.1 A typical HTTP session.

HTTP specifies how the client and server communicate with each other. The current standard for HTTP is version 1.1, and is defined by the World Wide Web Consortium (W3C). It specifies the exact format for each request and response message. The client makes a specially-formatted HTTP request to ask for the data, and the server responds with an HTTP response, along with the requested data.

The HTTP Request

The HTTP specifications define the client’s request to the server. Because HTTP is a text-oriented protocol, the client HTTP request consists of all text, separated into three parts:

A request line

Request header lines (optional)

An empty line terminated by a carriage return-line feed combination

The combination of the request line and header lines tell the server just what data the client wants to retrieve, along with some information about the client. Let’s take a closer look at those parts.

The Request Line

The request line identifies the object the client is requesting from the server. It consists of three parts:

A method token

A Universal Resource Indicator (URI) identifying the requested data

The protocol version

The method token defines the method action performed on the specified URI. Table 22.1 lists the valid method tokens currently supported in HTTP 1.1.

TABLE 22.1 HTTP Method Tokens

The GET and POST methods allow the client to send data to the server within the request. The GET method embeds the data with the URI itself, while the POST method sends the data as separate messages within the HTTP session.

The URI defines the path and filename of the data file you want to retrieve. The path is relative to the root folder of the web server.

The protocol version defines the HTTP version that the client is using.

A complete HTTP request looks something like this:

GET /index.html HTTP/1.1

This is the text the client sends to the web server to request the file index.html from the root folder of the web server.

Request Headers

After the request line, the client can optionally send one or more request headers. The request headers allow the client to send additional information about the request, about the connection, or even about the client itself (such as identifying the browser being used). The request header uses the following format:

header: value;

Each request header appears on a separate line and is terminated with a semicolon. The end of the request header list is indicated by an empty line with a carriage return and linefeed combination.

If your web client chooses to include request headers, a complete HTTP request would look something like this:

GET /index.html HTTP/1.1
User-Agent: Microsoft IE/10.0
Connection: Close

This request asks to retrieve the index.html file from the web server. It identifies the client web browser as the Internet Explorer package and tells the server to close the HTTP session connection after returning the response.

The HTTP Response

When the web server receives a request from a web client, it must formulate a response to return. The response consists of three parts:

The status line

One or more response header lines (optional)

An empty line terminated by a carriage return-line feed combination

If the request is successful, the requested data follows immediately after the HTTP response. Just like the HTTP request, the HTTP response is a plain-text message. Let’s take a look at the different parts of the response.

The Status Line

The status line returns the status of the request to tell the client how the server handled it. The status consists of three parts:

version status-code description

The version returns the HTTP version the server is using (usually HTTP/1.1). The status code and description indicate the status of the request. The status code is a three-digit code that indicates the status of the client’s request. This allows the client to quickly identify success or failure of the request. If the request failed, the response code indicates a detailed reason why the request failed. There are five categories of HTTP status codes:

1xx: Informational messages

2xx: Success messages

3xx: Redirection messages

4xx: Client-side errors

5xx: Server-side errors

Table 22.2 shows the full list of response status codes available in HTTP 1.1.

TABLE 22.2 HTTP Response Status Codes

The status-code numbers are always the same, but the text description may change depending on the server. Some servers provide more detail for failed requests.

The Response Header Lines

The response header lines allow the server to send additional information to the client besides the standard response code. The HTTP 1.1 version provides for lots of different response headers that you can use. Similar to request headers, response headers use the following format:

header: value;

Each response header is on a separate line and terminated with a semicolon. The end of the response header list is indicated by an empty line with a carriage return and linefeed combination.

A standard HTTP response would look something like this:

HTTP/1.1 200 OK
Host: myhost.com
Connection: Close

If any data is returned as part of the response, it should follow the closing carriage return and linefeed line of the header.

Now that you’ve seen how HTTP works, let’s take a look at using it in an Arduino sketch to communicate with client workstations.

Reading Sensor Data from a Web Server

Currently, there isn’t a standard Arduino library available for running a web server from your Arduino. Instead, you need to do a little coding to emulate the web server to remote clients. However, that’s not as hard as you might think, thanks to the simplicity of HTTP and the HTML web page markup language.

This section walks through building a web server that returns the output from a temperature sensor using the Arduino Ethernet library to serve your sensor data on the network.

Building the Circuit

For the circuit, you need to connect a temperature sensor to your Arduino to provide the temperature information. In Hour 18, “Using Sensors,” we worked with the TMP36 analog temperature sensor. The sensor provides an analog output signal that indicates the temperature. You just need to connect that output to an analog interface on the Arduino to process the data. Because the Ethernet Shield provides all the interface pins from the Arduino, you can plug your circuit directly into the Ethernet Shield interface header pins just as you would the regular Arduino interface header pins.