List of Figures

Chapter 1. From the Internet of Things to the Web of Things

Figure 1.1. The Internet of Things landscape. The IoT is a network of Things, which are anything that can be connected in some form to the internet. From a box of oranges with an RFID tag, to a smart city, to every Thing in between, all digitally augmented objects make up the Internet of Things.

Figure 1.2. Johnny would like to digitally connect the appliances in all rooms of his hotel. First, guests could have access to a variety of services from controlling their room (lights, air-conditioning, entertainment, and so on), to booking hotel facilities, to ordering food and drinks—all of this on their mobile phones. Second, this system would allow Johnny to coordinate and optimize all aspects of his hotel in a centralized and efficient manner, without having to use a variety of siloed applications and tools.

Figure 1.3. In the Internet of Things, hundreds of incompatible protocols coexist today. This makes the integration of data and services from various devices extremely complex and costly. In the Web of Things, any device can be accessed using standard web protocols. Connecting heterogeneous devices to the web makes the integration across systems and applications much simpler.

Figure 1.4. The Web of Things is concerned with only the highest OSI layer (7), which handles applications, services, and data. Working with such a high level of abstraction makes it possible to connect data and services from many devices regardless of the actual transport protocols they use. In contrast, the Internet of Things doesn’t advocate a single Application-level protocol and usually focuses on the lower layers of the OSI stack.

Figure 1.5. The Web of Things is the ability to use modern web standards on embedded devices. By using all these standards for Internet of Things scenarios, we both enable new types of interactive applications to be built and make sure that devices can be integrated with modern web applications and services with minimal effort.

Figure 1.6. The Web of Things allows developers and applications to exchange data with any physical object or device using standard HTTP requests, regardless of how the device is connected.

Figure 1.7. Since December 2013, the term Internet of Things has become more popular in news headlines than Web 2.0. [Source: Google Trends, September 25, 2015]

Figure 1.8. Three generations of wireless sensor nodes

Figure 1.9. The Nike+ ecosystem was one of the pioneers in the quantified self or wearables trend. [Photo by ivyfield on Flickr licensed under CC BY 2.0]

Figure 1.10. A Thinfilm printed NFC tag and temperature sensor. RFID tags, sensors, and batteries can now be printed, reducing the costs and allowing packages to become smart. [Source: Thinfilm, used with permission]

Figure 1.11. The Press for DP button manages the delivery of Dom Pérignon champagne in Savoy Hotel rooms within a few minutes. [Source: LVMH, used with permission]

Figure 1.12. The problem with Internet of Things. The Web of Things builds upon and extends existing and widely used web standards so that it can use the whole web ecosystem in place. [Source: http://xkcd.com/927/ used under Creative Commons 2.5 license]

Chapter 2. Hello, World Wide Web of Things

Figure 2.1. The Raspberry Pi and webcam you are accessing as they are set up in our London office

Figure 2.2. The setup of devices and sensors used in the examples of this chapter

Figure 2.3. The web page of the camera used in our setup. The image is a live screenshot taken by the camera.

Figure 2.4. The HTML homepage of the gateway of our WoT device. The two hyperlinks at the bottom of the page allow you to access the pages of the devices connected to the gateway.

Figure 2.5. The homepage of the Raspberry Pi. Here, you can use the links at the bottom to browse and explore the various resources offered by this device; for example, its sensors and actuators.

Figure 2.6. The list of sensors on the Pi. You can click each of them and see the latest known value for each.

Figure 2.7. The sensors on the camera. There’s only one sensor here, which is the current image.

Figure 2.8. Getting the root page of the gateway using the Postman web client. The request is an HTTP GET (1) on the URL of the gateway (2). The response body will contain an HTML document (4).

Figure 2.9. Getting the list of devices connected to the gateway via Postman. The Accept header is now set to application/json to ask for the results to be returned in JSON.

Figure 2.10. Getting the JSON representation of the Raspberry Pi. The JSON payload contains metadata about the device as well as links to its sub-resources.

Figure 2.11. Retrieve the temperature sensor object from the Raspberry Pi. You can see the latest reading (23.4 degrees Celsius) and when it took place (at 14:43 on October 4, 2015).

Figure 2.12. This graph gets a new value every few seconds from the device and is updated automatically.

Figure 2.13. The details of the LCD actuator, with the various properties that you can set, for example, the text that should be displayed next on the device

Figure 2.14. This simple client-side form allows you to send new text to be displayed by the Pi.

Figure 2.15. A mini-browser that parses your device metadata and displays the results

Figure 2.16. A physical mashup application. First (1), you retrieve the local temperature from Yahoo Weather and then the remote temperature from the sensor attached to our Pi (2). You compare it with the temperature in London and send the results to an LCD screen (3). When the screen displays the text you’ve sent, you retrieve a picture of the screen form the webcam (4) and display it on the mashup.

Chapter 3. Node.js for the Web of Things

Figure 3.1. The ranking of the most popular languages on GitHub. Since 2008 JavaScript has experienced a steady growth that led it to outnumber all other languages in terms of available projects on GitHub. [Source: GitHub.com]

Figure 3.2. Starting your first web server with Node (bottom) and returning the traditional “Hello World” to your web browser (top)

Figure 3.3. A simple Node web server returning temperature data with a JSON representation in Firefox

Figure 3.4. The GitHub page of a Node module. Look for the popularity metrics of the module when choosing it.

Figure 3.5. Dealing with a number of concurrent requests with a threading or process-forking approach: for each new client a new thread or process is created.

Figure 3.6. Dealing with a number of concurrent requests with a single-threaded event-driven approach. The event loop puts the clients on hold until the I/O operations have returned.

Figure 3.7. Callbacks and the event loop (simplification). F asynchronously fetches data from the network. Meanwhile, other functions are being served. When the data F requested is ready, the event loop calls the function specified by F for when the data is ready. This type of function is called a callback.

Figure 3.8. Running the server of listing 3.2 (terminal window, top) and consuming its data through a server-side mashup with callbacks called from a browser (bottom)

Chapter 4. Getting started with embedded systems

Figure 4.1. The Raspberry Pi 3 and the Pi Zero and their different ports and interfaces

Figure 4.2. Formatting an SD card for the NOOBS installer using Disk Utility on Mac OS. Make sure you format the card using the MS-DOS (FAT) format.

Figure 4.3. Sharing internet with your Pi over Thunderbolt Ethernet on Mac OS

Figure 4.4. Node.js download page: ARM CPUs are supported, but you need to select the right architecture for your embedded device model. As an example, the Pi 2 and 3 are built on an ARMv7 CPU architecture whereas the Pi Zero uses an ARMv6 architecture.

Figure 4.5. Layout of the GPIO, power, and ground pins on the Raspberry Pi Zero and Pi 3

Figure 4.6. A typical breadboard where the outer rows as well as the inner columns are connected. The line marked with a thin blue line is usually used for connecting to the ground, and the line marked with a thin red line is for connecting to the power source.

Figure 4.7. Wiring an LED to the GPIO ports of the Pi through a resistor. The resistor and the LED are plugged into the holes of the breadboard. No need to solder anything!

Figure 4.8. Connecting a passive infrared sensor to the Pi. The big sensor on the breadboard is the PIR, which is connected to a 5-volt power source, a GPIO pin, and the ground.

Figure 4.9. Connecting a DHT22 temperature and humidity sensor to the Pi

Chapter 5. Building networks of Things

Figure 5.1. From one Pi to a network of embedded devices to a network of embedded devices interacting with the web and its ecosystem

Figure 5.2. Star topology: all nodes communicate with a single central node. Star of stars topology: nodes connect to intermediate nodes (gateways), which are in turn connected to a central node using a star topology.

Figure 5.3. Mesh topology: messages are forwarded across several devices to reach their destination.

Figure 5.4. The OSI model (left) compared with the Internet Protocol Suite (aka TCP/IP, right), along with examples of some of the most relevant protocols and protocol stacks for the IoT (center)

Figure 5.5. Comparing the size and addressing space in IPv4 and IPv6

Figure 5.6. A good UDP/TCP joke! [Source: http://pcp-comics.com/, used with permission]

Figure 5.7. TCP communication: a client establishes a connection (SYN) to a server and starts pushing data to it. Once the data has been reliably transmitted, the client closes the connection to the server (FIN).

Figure 5.8. Two smart lamps communicating with web applications. Left: a smart lamp with Wi-Fi on board and implementing the IP stack. Right: a smart lamp implemented with ZigBee on board and implementing a ZigBee stack. In this second case, translators are required between the application and the lamp.

Figure 5.9. The HomeKit stack: both IP Things and Bluetooth Things are supported. Things based on other stacks are integrated via a HomeKit bridge. At the Application layer, HomeKit enables direct access to Things through iOS.

Figure 5.10. Typical protocol stacks for MQTT, MQTT-SN, and CoAP. MQTT is built on top of TCP. CoAP is built on top of UDP and usually IPv6 (6LoWPAN). MQTT-SN is usually built on top of UDP.

Figure 5.11. A connection between a client and a broker with QoS 1. The connection is kept open by sending regular PINGREQ requests. The frequency of these requests depends on a keepalive parameter set by the client. Because MQTT is a protocol working on connections that should be kept open, this parameter ensures that both the broker and client are connected. If the broker doesn’t receive a PINGREQ or any other message in 1.5x the keepalive interval, it will close the connection.

Figure 5.12. The Web of Things architecture stack with its various layers

Chapter 6. Access: Web APIs for Things

Figure 6.1. The Access layer of the Web of Things. This layer assumes that Things are connected in some way to the internet and focuses on how devices and their resources (properties, services, data, sensors, and so on) can be exposed as web APIs.

Figure 6.2. A Thing URL and the protocols each bit of the URL refers to. The first part specifies the protocol we use, here HTTP+TLS/SSL (HTTPS); then the domain is resolved by DNS to an IP address, the port is used by TCP to know what process to redirect to, and finally the REST resource is shown.

Figure 6.3. An example of URL structure of the various resources on a Raspberry Pi. The full URL of the X-axis reading of the acceleration sensor of the Pi highlighted in bold is http://devices.webofthings.io/pi/sensors/accel/x.

Figure 6.4. A preflight request corresponding to exercise 5 of chapter 2. The JavaScript needs to send a POST to another server with a Content-Type header. The server replies with the allowed origin, methods, and headers. Because they match what the script wanted, the call will be authorized.

Figure 6.5. Basic polling: a client app sends requests to a web Thing at regular intervals. The results the client app gets are not synchronized with new values available from the sensor.

Figure 6.6. Left: subscription pattern in a pub/sub. Client A subscribes to temperature updates, clients B and C to PIR updates. They all subscribe via the broker, which maintains a list of who has subscribed to what topic. Right: publication pattern. An intruder is detected, so the Thing publishes a PIR update to the broker. The broker delivers the update to clients B and C.

Figure 6.7. A webhook mechanism implemented between a Thing and a client. The client subscribes to the humidity resource via a POST on the Thing API. The Thing then informs the server of humidity changes via a POST on the client API.

Figure 6.8. Long polling: a client sends a request, which is kept on hold until an event is received from the sensor, at which point it gets forwarded by the web Thing to the client as the response of their initial request. After that, they reinitiate a new request, which will be kept open in the same way until a new value from the sensor is retrieved.

Figure 6.9. A WebSockets protocol handshake. First, the connection is opened via a GET request for a protocol upgrade. Then the persistent TCP connection is opened, and the client and server can exchange data frames. One of the parties (server or client) eventually sends a control frame to signal that the communication is over and can be closed.

Figure 6.10. A WebSocket protocol handshake in action as seen in the Network tool of Firefox. The client requests a protocol upgrade that the server accepts. From then on, the client and the server can send each other messages over the TCP connection, which will be kept open until the client or server decides to close it.

Chapter 7. Implementing web Things

Figure 7.1. Direct integration pattern. In this pattern the web Things are Wi-Fi–connected lamps that run an embedded HTTP server and therefore offer a Web of Things API directly. This allows web Thing clients, such as mobile applications or other web Things, to communicate with the lamps directly over HTTP. Image used with permission from http://model.webofthings.io.

Figure 7.2. The components architecture of our WoT server: The servers use the Express framework. The rest of the system is built around a model that plugins can observe and change. The plugins are built on other Node libraries, providing access to physical resources via GPIOs.

Figure 7.3. The resource tree of your Pi with a number of sensors and actuators and their hierarchy. Each resource gets a URL formed by following the path to this resource. As an example, the URL of the passive infrared sensor would be http://localhost:8484/pi/sensors/pir.

Figure 7.4. The middleware chain implemented for the WoT server: each middleware is added to the Express application with the app.use() function. Then, each middleware gets a reference to the request object, the response object, and the next middleware in the chain.

Figure 7.5. Sequence diagram of the WebSockets implementation of the WoT server: the WebSocket server is reacting to clients opening a WebSocket connection via an HTTP upgrade request by observing the corresponding resource;, for example, /temp. Whenever a new value for the resource is available, the WebSocket server sends it over the TCP connection it maintains open with the client.

Figure 7.6. Subscribing to temperature updates via WebSockets using a simple WebSockets client in Firefox. The upper part shows the protocol upgrade process and the lower part the incoming messages pushed from the Thing (a Pi here) directly to the browser-based client.

Figure 7.7. Gateway integration pattern. In this case, the web Thing can’t directly offer a web API because the device might not support HTTP directly. An application gateway is working as a proxy for the Thing by offering a web API in the Thing’s name. This API could be hosted on the router in the case of Bluetooth or on another device that exposes the web Thing API; for example, via CoAP.

Figure 7.8. Cloud integration pattern. In this pattern, the Thing can’t directly offer a Web API. But a cloud service acts as a powerful application gateway, offering many more features in the name of the Thing. In this particular example, the web Thing connects via MQTT to a cloud service, which exposes the web Thing API via HTTP and the WebSockets API. Cloud services can also offer many additional features such as unlimited data storage, user management, data visualization, stream processing, support for many concurrent requests, and more.

Figure 7.9. A physical device connects to a cloud platform using MQTT over TCP/IP and talks to its proxy on the web—called Thng. An external application can then talk to the Thng using a simple HTTP client.

Figure 7.10. See the smart plug directly from the dashboard and the properties being updated in real time.

Figure 7.11. How to create a short URL redirecting to the user interface of your device

Chapter 8. Find: Describe and discover web Things

Figure 8.1. The three problems of findability in the Web of Things. How can a client application find nearby web Things, interact with them, and understand what these things are and do?

Figure 8.2. The Find layer of the Web of Things. This layer relates to how one can easily understand the nature of things, what they relate to, how to access their documentation, what their API endpoints are, and how to access those (what parameters and their types). It also relates to the meaning of these properties in a standard way.

Figure 8.3. LAN-level resource discovery. Assuming that all web Things expose their root resource on port 80, web Thing clients can get their IPs from the router and then query each device to extract their metadata.

Figure 8.4. The various levels for describing web Things. Any device can have an HTTP API (1). Web Things (2) are HTTP servers that follow the requirements proposed in chapter 6; thus, APIs are more consistent, predictable, and easier to use. Using a shared model will make the web Thing more interoperable (3). Finally, adding semantic annotations will ensure stronger contracts between web Things and also more flexibility to define formally each element of the web Thing API (4).

Figure 8.5. The resources of a web Thing. Web Thing clients can interact with the various resources of the web Thing. The model resource provides metadata for discovery, properties are the variables of the Things (data, sensor, state, and so on), and actions are the function calls (commands supported by the web Thing). When the web Thing is also a gateway to other (non-web) Things, the Thing’s resource is a proxy to the non-web Things.

Figure 8.6. Resource tree of the Pi implementing the Web Thing Model. The notion of sensors and actuators is replaced by the idea of properties (variables) and actions (functions). Some of the resources, such as type or product, can be external references.

Figure 8.7. Implementation strategy of our Pi web Thing: the model is in the middle. It’s used by the routes creator to create the REST resources and their corresponding endpoints. Sensor plugins—for example, PIR—update the model whenever fresh data is read from a sensor. Actuator plugins listen for actions sent by clients, execute the action, and finally update the model when the action has been executed successfully; for example, they update the properties that have changed as a result of the action.

Chapter 9. Share: Securing and sharing web Things

Figure 9.1. The Share layer of the Web of Things. This layer focuses on how devices and their resources must be secured so that they can only be accessed by authorized users and applications.

Figure 9.2. The three principal challenges in securing the IoT. First, communications must be encrypted to prevent unauthorized entities from reading the messages between a client and a server. Second, the client must be sure they are really talking to whom they they are. Third, the server must be sure that a message comes from an authorized client allowed to send that request.

Figure 9.3. Asymmetric encryption in an IoT context. The heater shares its public key with Lena. It’s then up to Lena’s mobile app to encrypt messages sent to the heater. Thanks to the power of cryptography, the only way to decrypt the message is with the private key of the heater.

Figure 9.4. SSL/TLS handshake: the client and the server first negotiate the protocols and encryption algorithms, and then the server sends its certificate chain to prove who it is to the client. Finally, the client sends a preMasterSecret from which the client and server derive a masterSecret used to encrypt all the future messages.

Figure 9.5. The server of the WoT Pi can now be accessed via HTTPS. The details of the secure connection and certificates can be reviewed by clicking the small lock icon on the address bar.

Figure 9.6. OAuth delegated authentication and access flow. The application asks the user if they want to give it access to resources on a third-party trusted service (resource server). If the user accepts, an authorization grant code is generated. This code can be exchanged for an access token with the authorization server. To make sure the authorization server knows the application, the application has to send an app ID and app secret along with the authorization grant code. The access token can then be used to access protected resources within a certain scope from the resource server.

Figure 9.7. Social Web of Things authentication proxy: the auth proxy first establishes a secret with the Thing over a secure channel. Then, a client app requests access to a resource via the auth proxy. It authenticates itself via an OAuth server (here Facebook) and gets back an access token. This token is then used to access resources on the Thing via the auth proxy. For instance, the /temp resource is requested by the client app and given access via the auth proxy forwarding the request to the Thing and relaying the response to the client app.

Figure 9.8. User interface of a Social Web of Things authorization proxy: First (upper left), the UI allows the user to select a Thing to be shared and (lower left) the resource of the Thing that should be shared; for example, /temperature. Then (upper right) it lets the owner of the Thing log into their social network, such as Facebook, and (lower right) select a friend to share with or a list of friends. Here we share the temperature sensor of the Spot1 device with Dom’s sister via Facebook. [Source: Friends and Things Social Web of Things project]

Figure 9.9. A Social Web of Things authentication proxy for your Pi: client apps obtain a token via OAuth on Facebook; this token can then be used to access the Pi resources via the auth proxy. The auth proxy must be accessible on the web, or at least on the same network as the client app, but the Pi can be on a local network as long as the auth proxy can access it.

Figure 9.10. Setting up a new Facebook application for our Social WoT auth proxy. The app ID and secret will be used by Facebook to authenticate our app.

Figure 9.11. First, Facebook will prompt the user to accept the application request. After a successful Facebook authentication, the user is redirected to their Account page on the auth proxy, where they can retrieve their access token to be used in subsequent calls to the Things behind the proxy.

Chapter 10. Compose: Physical mashups

Figure 10.1. The Compose layer of the Web of Things architecture. This layer focuses on building web applications that can control Things or combine data and services from various sources to deliver complex processes. It brings the concept of web mashups to the Internet of Things.

Figure 10.2. The universal remote control for web Things. A web Thing client application (pure JavaScript/HTML) can find nearby devices, retrieve their Web Thing Model description, and use it to generate a custom user interface tailored for that specific device.

Figure 10.3. An HTML form to create ledState actions based on the web Thing model for a Raspberry Pi

Figure 10.4. An HTML view of the PIR and LED properties of the WoT Pi

Figure 10.5. The Node-RED user interface: the nodes (left) are dragged and dropped to create workflows by connecting them with wires, sending the data from one node to another.

Figure 10.6. Editing nodes: when double-clicking a node, the edit dialog pops up where the node can be configured. This edit dialog shows the configuration of an inject output node.

Figure 10.7. The flow of a physical mashup built with Node-RED. This physical mashup is a smart intruder alarm that listens for state changes of the PIR sensor via the WebSocket API . When an event arrives, Node-RED POSTs a ledState action to change the state of the LED –, and if the event contains a PIR sensor value of true , it GETs a snapshot from the webcam and POSTs it on Twitter –.

Figure 10.8. Configuration of the WebSocket input node and configuration of a new WebSocket client

Figure 10.9. IFTTT workflows are called recipes. They are composed of two parts: a condition (this) and a reaction (that) triggered when the condition is met.

Figure 10.10. Setting up the spreadsheet. IFTTT lets you add variables by clicking the Erlenmeyer flask icon. Here we use variables such as the Twitter user name (UserName), the content of the tweet (Text), and the timestamp of the Tweet (CreatedAt). All these fields will appear in the new row created in the Google spreadsheet located in an IFTTT/Twitter folder.

Figure 10.11. Step 7 is the final step of the workflow creation process. It summarizes the workflow you just created: if a tweet is pushed, then add a row to the Google Drive spreadsheet.

Figure 10.12. When an intruder is detected by the PIR sensor on your Pi, it tweets it via Node-RED. IFTTT detects this and adds a corresponding entry in your Google spreadsheet. Here you can see three intruder detection events.

Figure 10.13. Make a REST request via HTTP to your WoT Pi. This creates a new ledState action on your Pi by POSTing the corresponding JSON payload.