84 | Certified Internet of Things (IoT) Practitioner (Exam ITP-110)

Communicating with an
3 IoT Device
Lesson Time: 3 hours, 25 minutes

Lesson Introduction
You have set up an Internet of Things (IoT) device that can operate on its own power and
connect with other devices over the Internet, but it's still missing a few ingredients
commonly found in the Internet of Things. In this lesson, you'll give your device the ability
to communicate over various types of connections.

Lesson Objectives
In this lesson, you will:
• Use a wired connection to communicate with an IoT device.
• Use a wireless connection to communicate with an IoT device.
• Use the Internet Protocol Suite to communicate with an IoT device.
84 | Certified Internet of Things (IoT) Practitioner (Exam ITP-110)

TOPIC A
Communicate Using Wired Connections
An IoT device may use a wired connection to connect to other devices or the Internet.

Wired Data Communication Standards

When IoT devices are installed in a fixed location, a cabled data connection may provide higher
bandwidth, and a more reliable connection than wireless options afford. For example, radio noise
may be a problem in certain manufacturing environments, where cabled communication options
may be more appropriate for sensor and control devices. In some cases, power over Ethernet
options can be used to provide power and a network connection with just a single run of Ethernet
cable.

Industrial Ethernet Standards

In many cases, industrial settings have much more demanding requirements for data communication
than other domains, and the conditions are much harsher than typical office, home, or retail
environments. Temperatures may vary widely, there may be considerable vibration, chemical
exposure, and electrical noise.
Higher standards for Industrial Ethernet include such things as more rugged and resistant
connectors and cabling, and better assurance that data will be delivered on time and intact. Industrial
Ethernet standards may provide a MAC (Media Access Control) layer that is more robust than
standard Ethernet to provide low latency and ensure deterministic, real-time data communication.
Prevalent industrial Ethernet standards are described in the following.

Item Description
EtherNet/IP (EIP) An industrial networking protocol developed by ODVA, Inc., a global
trade and standards development organization. The protocol is based on
Common Industrial Protocol (CIP, also developed by ODVA), which is
widely used with Rockwell industrial automation systems. EIP operates
on standard Ethernet hardware, supporting IP communication using TCP
and UDP.
EIP distinguishes between these message types:
• Implicit messages: The data field does not contain protocol
information, but only real-time I/O data, minimizing the time needed
to process the message.
• Explicit messages: General purpose, point-to-point connections that
support request-response transactions between two devices, using
TCP/IP services to send messages over the industrial Ethernet
network.

Lesson 3: Communicating with an IoT Device | Topic A

 Certified Internet of Things (IoT) Practitioner (Exam ITP-110) | 85

Item Description
Process Field Net An industrial Ethernet standard maintained and supported by Profibus
(PROFINET) and Profinet International, designed to support real-time (under 1 ms or
less) data communication for the purpose of data collection and industrial
control.
The standard supports three levels of data communication:
• TCP/IP: Communications that are not time critical, with an expected
response within 100 ms.
• RT (Real-Time): Time critical communication with cycle times up to
10 ms.
• IRT (Isochronous Real-Time): Time critical communication with
cycle times less than 1 ms.
EtherCAT (Ethernet An Ethernet-based system developed by Beckhoff Automation, and
for Control standardized as IEC 61158. EtherCAT is intended to support real-time
Automation communication over Ethernet for process automation applications while
Technology) also supporting reduced hardware costs.
Precision Time A standard for precise clock synchronization of real-time devices
Protocol (PTP) communicating over Ethernet, originally defined in the IEEE 1588-2002
standard, published in 2002. PTP is intended to provide more accurate
synchronization than the services provided by Network Time Protocol
(NTP) and Global Positioning System (GPS). PTP was revised in 2008 as
IEEE 1588-2008, also known as PTP Version 2, to improve its accuracy,
precision, and robustness.
Time Sensitive A collection of standards under development by IEEE, Intel, Cisco,
Networking (TSN) National Instruments, and other organizations to provide Ethernet with
deterministic network behavior, meaning that it can be mathematically
determined precisely how long it will take for data to be delivered from a
"talker" to a "listener." With traditional Ethernet, which provides "best
effort" delivery, the delivery time cannot be determined. TSN can
function alongside traditional Ethernet, ensuring that deterministic traffic
will have priority over non-deterministic traffic.

Industrial Data and Information Management Standards

Prior to the advent of industrial data and information management standards, communication
between industrial control applications and the machinery they communicated with was difficult.
Separate device drivers and communication protocols were required for components from different
manufacturers. Two standards, Open Platform Communications (OPC) and Data Distribution Service for Real-
Time Systems (DDS), emerged in the 1990s to support interoperability communication between
devices and distribution of data.

OPC
In the 1990s, the Open Platform Communications (OPC) standard was pulled together based on
Microsoft's standards for distributed computing. While this solution provided much needed
interoperability, it was dependent on Microsoft Windows and starting to show problems of age,
such as cybersecurity issues. In 2002, Microsoft dropped support for standards that OPC was based
on.
In 2006, the OPC Foundation developed a new version of their open standard, renamed Open
Platform Communication Unified Architecture (OPC-UA) to include security improvements
and provide support across many different operating systems. It defines communications between a
86 | Certified Internet of Things (IoT) Practitioner (Exam ITP-110)

variety of systems, and has been adopted for use in a wide range of industries, including
manufacturing, energy, and pharmaceuticals.
OPC-UA supports:
• A streamlined binary protocol, which can easily be enabled through a firewall
• A web service protocol (SOAP), which uses standard HTTP/HTTPS ports
With the wide support for programming web services on microcontrollers, OPC-UA's support for
web services has made it a good choice for communicating with embedded devices, and because
OPC-UA has been widely adopted by many different vendors, it enables a wide range of equipment
from different vendors to interoperate.

DDS
In the late 1990s, the U.S. Department of Defense introduced the concept of the Global
Information Grid (GIG — essentially a military version of IoT). The DoD used the Data
Distribution Service for Real-Time Systems (DDS) standard developed by the Object
Management Group (OMG).
The DDS spec defines the Real Time Publish-Subscribe (RTPS) protocol, which defines a publish-
and-subscribe model for efficient delivery of data from programs producing information (such as
sensor devices) to programs consuming that data. The standard also includes the DDS
Interoperability Wire Protocol (DDSI-RTPS), which provides a standard for data communication
over an unreliable transport protocol such as UDP.

OPC-UA vs. DDS

OPC-UA and DDS continue to be used for machine-to-machine communication today, and there is
some overlap in their capabilities. To some extent because of their history, the two standards tend to
have a foothold in different industries. For example, OPC-UA is used in situations where DDS
might work as well or better, but OPC-UA is used primarily because OPC gained a foothold in
manufacturing before DDS.
However, the two standards may be used to complement each other, with OPC supporting direct
machine-to-machine communication between devices (using the device's IP address to direct
communication), and DDS distributing data produced by devices using a publish-and-subscribe
model to determine the recipients of the communication.
The following table compares the two standards.

Factor OPC-UA DDS

What the standard Client-server protocol, aware of Decentralized data model, unaware
defines network addressing and topology. of networking address and
topology.
Traditional footholds Manufacturing, process control, and Defense, medical, transportation,
energy. and energy.
How communication Client applications request data Applications anonymously read or
occurs from one or more servers. write data in a shared data space.
How data is located Client looks up a server by address, Data is sent to any clients that have
then connects and browses data in expressed interest in the topic.
the server's address space.
 Certified Internet of Things (IoT) Practitioner (Exam ITP-110) | 87

Factor OPC-UA DDS

Typical communication Non-time-critical, sending data out Real-time, reliable communication
to applications for aggregation and of data for consumption within the
analysis. local network as well as sending
data out to applications for
aggregation and analysis.
Configuration of Relatively static. Dynamic, constantly reconfigured.
devices
Examples: Examples:
• Communications directed at a • Logging of data sent by medical
particular medical device, such devices in a hospital setting,
as diagnostics, calibration, and which may be reassigned to
maintenance. different patients on a frequent
• Communications between field basis.
devices, sensors, controllers on • Military equipment.
the manufacturing floor. • Fleet vehicles.
Quality of service Not supported. Supports more than 20 configurable
(QoS) QoS policies.

Legacy Field Buses

Bus networks initially developed in the late 1970s to support industrial automation were called field
bus networks because they enabled communication among the various field devices communicating
with industrial controllers, such as the sensors, actuators, and other devices that monitor and control
production. Previously, this task was accomplished through RS-232 serial cabling, with each set of
wires providing a dedicated connection between two devices.
Some widely used field bus standards are described in the following.

Item Description
Modbus In 1979 Modicon (now known as Schneider Electric) produced this
protocol for use with its line of PLCs. This protocol is now commonly
used for industrial networking, and has been adopted by other vendors
because it is an open, royalty-free standard that is relatively easy to
implement.
In 2004, Schneider Electric transferred rights to the Modbus protocols to
the Modbus Organization, an association of users and suppliers of
Modbus-compliant devices.
HART Initially developed by Rosemount Inc. in the mid-1980s to support
Communication communication with their instrumentation products, this protocol
Protocol (Highway evolved into an industrial automation protocol that supports both digital
Addressable Remote and analog signaling methods. Because of its ability to communicate
Transducer) through legacy analog wiring, the Highway Addressable Remote
Transducer (HART) protocol provided an easy transition for
conversion of legacy instrumentation to smart systems, making it one of
the most widely used industrial protocols.

Lesson 3: Communicating with an IoT Device | Topic A

88 | Certified Internet of Things (IoT) Practitioner (Exam ITP-110)

Item Description
PROFIBUS (Process In the late 1980s, a German initiative backed by 21 organizations
Field Bus) proposed a plan for a serial field bus, which was promoted by the
German department of education and research (BMBF) and implemented
by Siemens in their industrial automation products. PROFIBUS is part of
the IEC 61158 open standard.
The Field bus Message Specification (FMS) specification was released
first. Later the Decentralised Peripherals (DP) specification was released.
FMS supports non-deterministic communication, while DP is designed
for deterministic communication.

Legacy Serial Communication

Numerous serial data interfaces have been developed for specific applications, and several have been
adopted as de facto standards.
• UART (Universal Asynchronous Receiver Transmitter) is an old, simple, and still widely used
serial protocol. Microcontrollers commonly include an onboard UART interface. UART uses
one data line to transmit, and another to receive, typically in chunks of 8 bits, with two other bits
used to start and stop the sequence. The start bit is typically set to the low voltage value and the
stop bit to the high voltage value, ensuring a transmission will always start with a transition from
high to low. UART doesn't specify a particular voltage level, so the default voltage of the
microcontroller can be used.
• SPI (Serial Peripheral Interface) is another simple serial protocol. With SPI, a clock signal is sent
over a wire that is used as a reference to determine when data bits begin and end, so they can be
extracted from the signal at the other end of the communication. SPI requires at least three signal
wires.
• CAN (Controller Area Network) is typically used to support communication between various
electronic embedded devices that are part of a single system, such as those in an automobile,
which is where this serial protocol was first used in the mid 1980s.
• RS-232 is a serial standard that was originally used in the early 1960s to enable peripherals such
as data terminals and printers to be connected to data communications equipment and
computers. Higher voltages (such as 12 volts) are used to enable the cable to span longer
distances than would be possible with UART. RS-232 ports were commonly provided on early
personal computers for connection to a printer, mouse, and other peripherals.
• RS-485 (now called TIA-485) is used not only to connect one device to another (one to one) but
also as a simple bus network to interconnect multiple devices, with a range and data rate that
exceed RS-232. RS-485 uses differential signaling on two lines for effective noise cancellation.
• USB (Universal Serial Bus) was developed as an industry standard for communication, and
power supply between personal computers and their peripheral devices. USB versions 1 and 2
provide a single serial channel with half-duplex communication (only one direction at a time).
USB 3 supports full duplex communication (two directions at one time). For backward
compatibility, a third communication channel is provided, which supports half duplex
communication compatible with USB 1 and 2.
Note: The new Universal Serial Bus type C standard can also carry other types of
communication, including parallel, when it is used to connect display devices. USB 3.2 also
supports parallel data connections.

Data Communication During Development and Testing

During development and testing, wired connections are commonly used to communicate with IoT
devices. For example, a USB cable may be used to upload firmware and programs to the device, and
may also be used to communicate with the device during debugging.
Lesson 3: Communicating with an IoT Device | Topic A
 Certified Internet of Things (IoT) Practitioner (Exam ITP-110) | 89

Guidelines for Communication Using Wired Connections

Follow these guidelines to communicate using wired connections.

Note: All of the Guidelines for this lesson are available as checklists from the Checklist tile on
the CHOICE Course screen.

Use Wired Connections

Consider using wired network connections for IoT when:
• You are programming the device and need a temporary connection to upload large portions of
compiled code to the device.
• You are deploying the device and:
• It is practical to cover the distances required using wires (with signal repeaters, if necessary).
• The device is in a fixed location, and will seldom be relocated (includes installed components
communicating with each other within a mobile vehicle).
• A wired connection would be more immune to radio noise in the local environment than a
wireless connection.
• Wired communication will consume less battery power than wireless, conserving limited
energy resources.
• Existing data lines can be used, saving the cost of running new lines.
• Devices must communicate large amounts of data (such as images or video), requiring more
bandwidth or lower latency than the supported wireless networking options can easily
support.
• Using a wired connection provides improved network security the application requires.

Lesson 3: Communicating with an IoT Device | Topic A

90 | Certified Internet of Things (IoT) Practitioner (Exam ITP-110)

ACTIVITY 3-1
Communicating over a Wired Serial Connection
Before You Begin
The course data files are installed on your computer in C:\095024Data. These files include a
customized version of the Arduino IDE (located in C:\095024Data\Tools\arduino), which
contains example programs that you will use in this course. The example programs are contained in
the File > Sketchbook sub-menus inside the Arduino IDE.
The ESP8266 microcontroller is connected to a USB port on the development computer. The
Arduino IDE is not running.

Scenario
The ESP8266 microcontroller can obtain and process all sorts of data, but unless you have a display
device of some sort attached to it, it can't display the information it processes. So you must
communicate with it somehow to obtain that information. One way you can do that is using the
USB serial interface that you have already used to upload a program. In this activity, you will upload
a program that queries the microcontroller for various types of information, and displays that
information in a console on the development computer.
Note: During the course, we suggest that you not install updates if the Arduino IDE prompts
you to do so. The course was written for the version of the Arduino IDE and software libraries
that are included with the course, and installing the updates may change menu options and
features, and may cause some of the source code to not compile correctly.

1. Launch the Arduino integrated development environment.

a) From the Windows Start menu, select Arduino to start the Arduino IDE.

2. Open the Serial_Communication sketch.

a) Select File→Sketchbook→Communicating with an IoT Device→Serial_Communication.
b) Close the other Arduino IDE window, which is still open in the background.

3. Set the communication rate between the two devices.

a) Examine line 8 in the setup function shown in the Serial_Communication window.

• Line 8 specifies that the IoT device will use 9600 baud as its data rate.
• A computer communicating with this device will need to match this data rate to correctly read
data from the device, so it knows how frequently to sample the data for values.
b) Select Tools→Serial Monitor to display the serial monitor window.

Lesson 3: Communicating with an IoT Device | Topic A

 Certified Internet of Things (IoT) Practitioner (Exam ITP-110) | 91

c) Arrange the windows so you can see the code window and serial monitor side by side.

d) In the serial monitor window, set the line ending characters to Carriage return and the baud rate to
9600 baud.

4. Compile and upload the program while you review the rest of the source
code.
a) Select Sketch→Upload or press Control+U to start the compile and upload process.

Lesson 3: Communicating with an IoT Device | Topic A

92 | Certified Internet of Things (IoT) Practitioner (Exam ITP-110)

b) Examine the code in the setup function in the Serial_Communication window.

• When the program starts running, lines 15 through 24 print information about the microcontroller
out to the serial connection.
• This information will be sent over the serial data line (USB cable) from the IoT device to the
development computer.
c) Examine the code in the loop function in the Serial_Communication window.

• Similar to the Blink program, each time this program runs its main loop, it just flashes the LED on
and off.

5. When the program runs on the IoT device, examine the message the IoT
device sends over the USB cable.

Lesson 3: Communicating with an IoT Device | Topic A

 Certified Internet of Things (IoT) Practitioner (Exam ITP-110) | 93

a) In the serial monitor, examine the message received from the IoT device.

• Information about the microcontroller appears in the serial monitor. This information was
transported from the device to your development computer over the USB serial connection.
• Communication through wired serial connections is useful for development and debugging, and
for situations where IoT devices are in a fixed location where wiring is practical.
• Wireless technologies such as Wi-Fi and LTE are typically better suited for connecting mobile
IoT devices or those in situations where wiring is impractical.
• The requirements for this project are that the device be connected wirelessly, so you'll need to
add some code in order to connect to Wi-Fi and communicate using TCP/IP.

Note: Your microcontroller may be using different versions of SDK, core, and
bootloader than those shown here.
b) In the serial monitor, observe how much sketch memory is in use, and how much space is
remaining.
• This small program gives you an idea of how much code you can upload to the microcontroller.
• As you can see from the numbers output in the serial monitor, it's already using about 10%, so
the programs you install on the device must be fairly small.
• This reveals an important point about designing IoT devices; typically, code on the devices
themselves must be quite small and efficient.

Lesson 3: Communicating with an IoT Device | Topic A

94 | Certified Internet of Things (IoT) Practitioner (Exam ITP-110)

TOPIC B
Communicate Using Wireless Connections
You've established wired communication with a prototype IoT device for development purposes,
but the requirements call for a device that can connect to a network wirelessly. You will now enable
the device to connect to a wireless network.

Wireless Communication
Using wireless communication enables devices to be mobile, or located in remote locations where
wired communication options may not be practical. However, the distance over which data can be
transmitted by wireless devices is an important design concern. As a general rule, doubling the range
covered by a wireless transmission requires a fourfold increase in power. There are tradeoffs
between power consumption, data rates, and the distance that can be traversed, so it is important to
identify your requirements for these different attributes before selecting a technology.
The following terms are often used to provide a conceptual description of the various ranges that
may need to be supported by different devices.

Item Description
Near Range • Very short range
• Typical: Hand-to-hand exchange
• Distances measured in inches
• Example: Devices used as a digital wallet, or "bumping" smartphones
to exchange data
PAN (Personal Area • Short to medium range
Network) • Typical: Same room
• Distances of no more than 15 feet
• Example: Wearable fitness tracker that uses Bluetooth to send data to
a smartphone app
HAN (Home Area • Medium range
Network) • Typical: Within a single residence, extending into the surrounding yard
• Distances up to hundreds of yards
• Example: Actuators located throughout a home to control lighting
and power to electrical outlets.
LAN (Local Area • Medium range
Network)
• Typical: Same building
• Distances up to hundreds of yards
• Example: Sensors located throughout a single assembly line using Wi-
Fi to transmit data to a gateway device in the engineering office
WAN (Wide Area • Long range
Network) • Typical: Same campus
• Distances in miles
• Example: An industrial network supporting industrial control systems
throughout the entire campus

Lesson 3: Communicating with an IoT Device | Topic B

 Certified Internet of Things (IoT) Practitioner (Exam ITP-110) | 95

Item Description
MAN (Metropolitan • Long range
Area Network) • Typical: Same city
• Distances up to a few miles
• Example: Smart parking sensors connected in a mesh network
throughout an entire city

Note: These terms may be useful to identify the conceptual range a wireless network must
cover, but they don't correspond directly to a specific distance that must be covered. For
example, one home area network might cover a small apartment, while another might cover
several acres.

Note: To learn why mesh networks are beneficial for IoT implementations, check out the
Spotlight on Mesh Networks for IoT presentation from the Spotlight tile on the CHOICE
Course screen.

Near Range Wireless Communication

Communication protocols commonly used for near range wireless communication include NFC and
RFID.

Item Description
Near Field This protocol is used for very short range communication (less than two
Communication inches). It is commonly used for payment systems, and also has been used
(NFC) for asset tracking and smartphone data exchange.
Radio Frequency Electronic tags attached to objects store identifying information that can
Identification be read by an RFID reader, typically over a range of a few feet or less.
(RFID)
RFID tags may be passive or active.
• Passive tags are suitable for devices without batteries since the power
source is not required by the tag.
• Active tags periodically broadcast their ID, while assisted passive tags
become active when RFID reader is present.
RFID is commonly used for inventory tracking in retail and industrial
IoT.

Medium Range Wireless Communication

Communication protocols commonly used for medium range wireless communication include
technologies based on IEEE 802.11 (Wi-Fi), Bluetooth®, and IEEE 802.15.4 (which includes
Zigbee, Thread, WirelessHART, and others).

Item Description
IEEE 802.11 (Wi-Fi) The IEEE 802.11a/b/g/n specification defines protocols for wireless
connection to a local area network, and is very widely used by the current
generation of IoT devices. Wi-Fi is a trademark of the Wi-Fi alliance,
which certifies products that adhere to IEEE 802.11a/b/g/n, ensuring
interoperability of those products. 802.11n produces very high data
throughputs at the cost of high power consumption. IoT devices may
instead use 802.11b or 802.11g to conserve power.

Lesson 3: Communicating with an IoT Device | Topic B

96 | Certified Internet of Things (IoT) Practitioner (Exam ITP-110)

Item Description
Bluetooth Bluetooth short-link radio technology was initially developed in 1989 by
Ericsson Mobile to support the connection of wireless telephone headsets
to cell phones. Bluetooth radios are rated for a range of no more than 100
meters.
Bluetooth Low Energy (BLE) (originally named Wibree) is a Bluetooth
alternative designed to support small personal devices like wearable health
and fitness trackers, using much less power while providing a similar
communication range.
IEEE 802.15.4 This specification, originally released in May 2003, defines a wireless
personal area network that achieves extremely low power consumption
through simple technologies that provide low data rates. The standard's
efficient use of power and simplicity makes it well suited for constrained
devices.
This standard is implemented by various competing technologies,
including Z-Wave, Zigbee, 6LoWPAN, Thread, WirelessHART, and
others.

Zigbee

Figure 3-1: A Zigbee network interconnected with an IP network.

Zigbee builds on the physical layer and media access control specifications defined in IEEE
802.15.4 to provide a medium range wireless network for applications such as home automation,
wireless sensor networks, industrial control, medical data collection within a clinical or home setting,
and smart buildings. Zigbee is not well suited for situations in which the networked devices are
highly mobile and require frequent reconfiguration.
Zigbee provides a less complicated and more energy-efficient alternative to Wi-Fi and Bluetooth.
Zigbee operates on the same 2.4 GHz radio frequency as BLE, but with a longer range (up to 100
meters) and a slightly lower data rate (250 kbps maximum) than BLE's 270 kbps.

Lesson 3: Communicating with an IoT Device | Topic B

 Certified Internet of Things (IoT) Practitioner (Exam ITP-110) | 97

Zigbee supports mesh, star, and tree network configurations. Devices play various roles in a Zigbee
network: coordinator, routers, and end devices.
• Coordinator: At least one coordinator is required, functioning as the root device, and providing
a gateway to other networks. The coordinator processes and stores information on behalf of
other devices.
• Router: Routers manage the flow of data between devices.
• End device: End devices perform various sensor and actuator functions. To conserve battery
power, they have limited communication functionality, relying on routers and coordinators to
manage communication and data aggregation.
Some devices in the network can sleep to save power, but other devices must remain awake between
bursts of network communication to function as routers or coordinators, depending on their current
position and role in the network.
Note: Zigbee is named for the zig-zag pattern honeybees follow when collecting pollen.
Likewise, Zigbee data can "zig" and "zag" through a reconfigurable mesh network until a
suitable path is found to the destination.

Zigbee Topologies

Figure 3-2: Zigbee network topologies.

Zigbee supports various network topologies. Star, mesh, and cluster tree are the most commonly
used. The type of network topology used influences the number and configuration of devices
required. Regardless of the topology, at least one coordinator is required.
A network can be set up as a star, with each end device connecting directly to the coordinator, and
no routers required. The coordinator manages communication over the network. This topology is
simple and easy to configure.
When you introduce routers into the mix, other configurations are possible, such as mesh and
cluster tree.

Lesson 3: Communicating with an IoT Device | Topic B

98 | Certified Internet of Things (IoT) Practitioner (Exam ITP-110)

Routers can be interconnected to create redundancy paths in the network. If any node loses
connectivity, data can be routed automatically through remaining paths. In this way, a mesh
topology can improve the reliability of wireless sensor networks like Zigbee.

Z-Wave
Z-Wave is another wireless communication technology based on IEEE 802.15.4. Z-Wave was
designed by Zensys, a Danish company based in Copenhagen, for use in home automation. It
started as a proprietary technology, and was later released into the public domain. Z-Wave provides
interoperability among home control systems of different manufacturers that are a part of the Z-
Wave alliance. With hundreds of companies in the alliance and thousands of products using the
standard, Z-Wave is widely used in home automation products.
Based on IEEE 802.15.4, Z-Wave was designed to use less power than Wi-Fi, and provides a greater
range than Bluetooth. It is designed to be easy to set up and configure. A Z-Wave hub serves as the
network controller, enabling up to 232 devices to wirelessly communicate with each other. From
one device to another, the range is about 100 meters, but because Z-Wave uses a mesh network,
each connected device may extend the network's overall reach. Z-Wave signals hop from one device
to another, extending the network to more devices, so five devices could span a total distance of 400
meters.
For security, the Z-Wave network and each of the devices within the network have unique IDs that
communicate only with other local devices and the hub. A different hub cannot control devices
associated with the local hub. Sensitive devices like door locks and alarms use AES-128 encryption
to provide even more security.
Z-Wave communicates in the 800-900 MHz radio frequency range, so it is not subject to
interference from Wi-Fi, unlike Zigbee, which operates in the 2.4 GHz frequency that is commonly
occupied by Wi-Fi signals.

6LoWPAN and Thread

6LoWPAN is a networking specification that stands for IPv6 over Low-Power Wireless Personal Area
Networks. 6LoWPAN supports IEEE 802.15.4 low-power wireless networking on IPv6 networks.
6LoWPAN enables even small, low-power IoT devices to have their own IPv6 address, making it
useful for access to wireless sensor networks. This protocol has applications in industrial
automation, home automation, entertainment, and smart electrical grid.
This standard will play an important role in IoT because it enables large IPv6 packets to be sent over
802.15.4 links that support much smaller packet sizes. Without 6LowPAN IPv6, IP traffic would
not be allowed in IEEE 802.15.4 Low Power Wireless Personal Area Networks.
The Thread protocol for home automation devices, which is backed by Google, Nest, Samsung, and
other organizations, runs over 6LoWPAN. Thread is IP-addressable, with cloud access and
Advanced Encryption Standard (AES) encryption. It currently supports up to 250 devices in one
local network mesh. A device such as a Nest thermostat serves as the networking hub, using its own
Wi-Fi connection to provide an Internet gateway for low-power devices in the local Thread
network.

WirelessHART
In 2004, WirelessHART was developed to provide a wireless communication protocol compatible
with HART to provide an easy transition path for those wishing to use new, wireless technologies in
their legacy industrial networks that use the HART protocol. WirelessHART is a reliable protocol
that uses advanced encryption to provide security over a wireless connection.

Lesson 3: Communicating with an IoT Device | Topic B

 Certified Internet of Things (IoT) Practitioner (Exam ITP-110) | 99

Long Range Wireless Communication

Communication protocols commonly used for long range wireless communication include
technologies based on satellite, cellular, and new communication standards driven by IoT's need for
low power wide area networks (LPWANs). LPWAN technologies such as LoRa, LoRaWAN, and
SigFox provide long range wireless data communication at a low data rate to conserve battery
power, with data rate ranges typically less than 50 Kbps on a single channel.
The following are various long range wireless communication technologies.

Item Description
Cellular With IoT, machine-type communications (MTC) are expected to
represent a significant portion of communications provided by services
such as cellular. Cellular systems designed for human-type
communications were not intended to efficiently send very short packets
between massive numbers of devices. Furthermore, IoT applications
require wide-area coverage with deep indoor penetration, while
maintaining low costs and energy efficiency. New cellular technologies
address these needs.
The challenges for cellular providers have been described as ultra-reliable
machine-type communication (uMTC) and massive machine-type communication
(mMTC). While uMTC focuses on availability, low latency, and high
reliability, mMTC focuses on the challenge of scaling wireless
connectivity to tens of billions of IoT devices.
Narrowband IoT (NB-IoT) is an LPWAN radio standard that enables a
wide range of cellular devices and services, focusing on indoor coverage,
low cost, long battery life, and high connection density. NB-IoT
implements a subset of the LTE standard, operating in a single narrow
band of 200kHz.
5G, when released, will also support the objectives of uMTC and mMTC.
LoRaWAN LoRaWAN (long range wide area network) refers to a vendor alliance
(Semtech, IBM, Microchip, Cisco, Bouygues Telecom, Singtel, KPN,
Swisscom, FastNet, and Belgacom) focused on creating LPWAN
technologies for IoT devices. It is relatively inexpensive to add
LoRaWAN to a new area, making it a good choice for IoT products that
need to be located in areas where cellular service is not already present.
This technology is primarily for data uplinks, sensor networks where most
of the communication from the sensor devices are uploads to a gateway
or cloud service.
While LoRaWAN is an open standard, the chipset it runs on is
proprietary, owned by Semtech. long range (LoRa) is the physical layer
technology that LoRaWAN runs on. LoRa uses license-free sub-gigahertz
radio frequency bands such as 169 MHz, 433 MHz, 868 MHz (Europe),
and 915 MHz (North America), and supports low-power data
transmissions with a range of more than 10 km (6 miles) in rural areas.
SigFox SigFox has been providing wireless networks for low-power devices since
2009. SigFox uses proprietary technologies, with a signal that can pass
freely through solid objects.
Like LoRaWAN, this technology is also for data uplinks.
RPMA Random Phase Multiple Access (RPMA) is a proprietary LPWAN
technology stack developed by Ingenu. RPMA uses the globally available
2.4 GHz spectrum used for Wi-Fi and Bluetooth.
Lesson 3: Communicating with an IoT Device | Topic B
100 | Certified Internet of Things (IoT) Practitioner (Exam ITP-110)

Item Description
Satellite Satellite communication provides a good wireless backhaul option,
enabling devices in remote locations to connect to the Internet.
Narrowband providers such as L-band currently dominate IoT satellite
offerings, but newer high-throughput Ku-band and Ka-band are well
suited for use in IoT. New transceiver designs will use compact electronic
antennas (no dish) and power-saving modems suitable for use with IoT
devices.

Guidelines for Communication Using Wireless Connections

Follow these guidelines when selecting a wireless communication option.

Use Wireless Connections

Consider using wireless network connections for IoT when:
• You want to avoid cost of running new data lines.
• The physical location of devices makes it dangerous, awkward, or impractical to run wires.
• Electromagnetic noise in the local environment is not sufficient to interfere with communication.
• The most effective locations for IoT devices are where data lines are not allowed, or cannot be
run easily, cost effectively, or safely.
• The devices are mobile.

Select Appropriate Data Processing and Communication Strategies for Wireless

Devices
Apply the following principles and strategies when designing a network for wireless IoT devices.
• Match the range required for your use case. For example, don't use BLE to connect devices
that need to operate over a range of several miles.
• Match the power requirements for your use case. For example, try to use a low-power
protocol for devices that operate on batteries.
• Match the data rates and sizes for your use case. For example, sensor devices may transmit a
very small amount of data in each transmission, such as a few bytes, whereas the smallest size of
a data packet may be much larger than that.
• Use edge computing to your advantage. When you must transmit data from constrained
devices over a long distance, consider relaying the data to a more powerful device located on the
same local network as the IoT devices, performing appropriate processing there, and then
forwarding the results to the cloud for further processing and analysis.
• Use appropriate radio frequencies. Lower radio frequencies generally correspond to better
range, better penetration through walls, and lower power draw. Higher radio frequencies
generally correspond to higher data rates.

Select a Wireless Communication Option

Refer to the following summaries when selecting a wireless communication option.

Technology Frequency Range (feet) Data Rate Power Cost of Chip

(Mbps) Consumption Sets

IEEE 802.11 2.4 GHz, 5 115 - 230 150 High Average

(Wi-Fi) GHz

Lesson 3: Communicating with an IoT Device | Topic B

 Certified Internet of Things (IoT) Practitioner (Exam ITP-110) | 101

Technology Frequency Range (feet) Data Rate Power Cost of Chip

(Mbps) Consumption Sets

Satellite 1 - 40 GHz (Global) 10 (X band High High

with 45 cm
antenna)
Cellular 824-896 MHz 3000 typical 100 (LTE High Average
(Traditional) Cat3)
710 - 787 MHz 150 (LTE
(LTE) Cat4)
300 (LTE
Cat5)
Bluetooth 2.4 GHz 200 (version 4) 25 (version 4) Average Low
800 feet 50 (version 5)
(version 5)
6LoWPAN 2.4 GHz 380 0.25 Low Low
Thread 2.4 GHz 100 0.25 Low Average
Zigbee 2.4 GHz, 915 100 - 325 0.02 - 0.25 Low Average
MHz (US), 868
depending on
MHz (EU)
frequency used
Z-Wave 915 MHz (US), 100 - 325 0.02 - 0.04 Low Average
868 MHz (EU)
depending on
frequency used
SigFox 868 MHz (EU) 9,842 - 164,000 Low Average
915 MHz (US)
LoRa Various Up to 105,600 0.05 Low High
options within
150 MHz - 1
GHz
Bluetooth Low 2.4 GHz 200 feet 0.125 Low Low
Energy (BLE)

Lesson 3: Communicating with an IoT Device | Topic B

102 | Certified Internet of Things (IoT) Practitioner (Exam ITP-110)

ACTIVITY 3-2
Testing Wi-Fi Communication with a
Microcontroller

Before You Begin

The course data files are installed on your computer in C:\095024Data. These files include a
customized version of the Arduino IDE (located in C:\095024Data\Tools\arduino), which
contains example programs that you will use in this course. The example programs are contained in
the File > Sketchbook sub-menus inside the Arduino IDE.
The ESP8266 microcontroller is connected to a USB port on the development computer. The
Arduino IDE is running.

Scenario
You will start implementing wireless capabilities on the device by establishing that you can connect
to a local Wi-Fi network. Although a user interface of some sort will have to be provided so end
users can configure the device for the Service Set Identifier (SSID) and Wi-Fi password, for now
you'll just hard-code that information into the program.

1. Open the Wi-Fi_Communication sketch.

a) Select File→Sketchbook→Communicating with an IoT Device→Wi-Fi_Communication.
The sketch opens in a new Arduino IDE window. The window you were previously using,
Serial_Communication, is still open in the background.
b) Close the Serial_Communication window, and position the WiFi_Communication window side by
side with the serial monitor.

2. Examine the code that connects to a Wi-Fi network router.

Lesson 3: Communicating with an IoT Device | Topic B

 Certified Internet of Things (IoT) Practitioner (Exam ITP-110) | 103

a) Examine the Wi-Fi_Communication sketch.

• Placeholders are provided in lines 3 and 4 for the Wi-Fi network's SSID and password. (You'll
replace these later.)
• Lines 7 through 13 in the setup function set up the serial connection, similar to how this was
done in the previous activity. The serial connection is being used here only to provide the
developer with feedback. It's not needed in order to connect to Wi-Fi.
• Line 19 starts the Wi-Fi connection. It uses the SSID and password values that were defined in
lines 3 and 4.
• The code that implements the ability to connect to Wi-Fi is contained in the ESP8266WiFi
library, which is included in the project through an include directive in line 1.
• The program runs a loop at lines 20 through 23 until the connection is completed.
• The network automatically assigns an IP address to the device, which is printed out to the serial
port in line 27, so you can see the device's IP address printed in the serial monitor.

3. Configure the device to access the Wi-Fi router.

Lesson 3: Communicating with an IoT Device | Topic B

104 | Certified Internet of Things (IoT) Practitioner (Exam ITP-110)

a) In line 3, revise the text within the double quotes to identify the SSID for the local Wi-Fi router.

Note: Your instructor will provide you with the SSID and password for the
classroom Wi-Fi router. If you are a remote student, you'll need to use the
credentials for the Wi-Fi router in your remote course environment (e.g., your
office or home Wi-Fi router).
b) In line 4, revise the text within the double quotes to provide the password for the Wi-Fi router.

4. Upload and run the program, and examine the output to the serial monitor.
a) Make sure the serial monitor window is showing and set for a 9600 baud connection.
b) Upload the sketch to the microcontroller.
c) When the program runs, examine the output in the serial monitor.

The IP address assigned to the device is shown in the serial monitor.

5. If an IoT device is assigned a dynamic IP address, how will users be able to

find the device on the network?

6. Many IoT devices do not have their own display or keyboard. How can you
provide users with access to the IoT device so it can be configured to access
the local Wi-Fi network access point?

Wireless IoT Device Configuration

One of the challenges of wireless communication on an IoT device is the initial configuration
required to connect the device to the network. Many devices are essentially "headless." They don't
have a display or keyboard and local controls may be limited to a power/reset button and perhaps
an LED.
Connecting to a wireless network typically requires that the operator provide credentials. For
example, provisioning a device on a Wi-Fi network requires the user select the access point's SSID
and password. Typically configuration can be accomplished through another device, such as a

Lesson 3: Communicating with an IoT Device | Topic B

 Certified Internet of Things (IoT) Practitioner (Exam ITP-110) | 105

smartphone, but there must be some way for the smartphone to easily connect directly to the IoT
device.
Since many smartphones also have Bluetooth, consumer IoT devices often use Bluetooth to pair up
an IoT device with a smartphone. Then an app on the smartphone can be used to provide the user
interface through which the IoT device can be configured for the wireless network.
Of course, wireless provisioning schemes like this should be carefully designed so as not to create
security or usability problems. There are different tradeoffs with each approach.

Guidelines for Providing a Wi-Fi Configuration Manager

Follow these guidelines when providing a user interface to enable users to connect an IoT device
with a Wi-Fi network.

Provide a Wi-Fi Configuration Manager

Consider the pros and cons of various approaches such as those listed when you select an approach
to implement a Wi-Fi configuration manager.
• WPS Wi-Fi Protected Setup. Press a button on the router to configure Wi-Fi.
• Pro: Provides an industry standard method for provisioning headless Wi-Fi devices.
• Pro: Does not require that user type a complicated SSID and password.
• Con: Requires that the router support WPS Wi-Fi protected setup.
• Con: Devices may include a design flaw that permits a brute-force attack on the network
password.
• Con: Potential usability problems, such as requiring that the user have physical access to the
access point. May require moving back and forth between separate rooms or locations to
complete configuration.
• Use a temporary wired connection. Provide an Ethernet, serial, or USB port on the IoT
device to connect the device by cable through the local area network or directly to a computer or
mobile device for initial setup.
• Pro: Wired connections tend to be much simpler to establish and initialize than wireless
connections.
• Pro: Most end users are comfortable plugging cables into their computers and mobile devices
— especially USB.
• Con: Requires that the user either have their own USB cable, or you provide one with the
device. There are various types of USB connectors, so the type of cable needed depends on
the product the user has.
• Con: Requires that the IoT device include support for other communication protocols in
addition to Wi-Fi, increasing the cost and complexity of the device.
• Use a different wireless connection. Use another wireless protocol, such as Bluetooth, to pair
the IoT device with a smartphone or computer to provide an initial connection.
• Pro: Bluetooth was designed to connect headless devices (such as a telephone headset) to
smart devices such as smartphones.
• Pro: Bluetooth is provided by virtually all smartphones and many desktop computers.
• Con: User may not own a phone or computer that supports Bluetooth.
• Con: Requires that the IoT device include support for another wireless protocol in addition
to Wi-Fi.
• IoT device enters "access point" mode. The IoT device makes itself available as a Wi-Fi
access point when it can't connect to the Wi-Fi network. The operator can use a smartphone or
computer to connect to the IoT device (as though connecting to a Wi-Fi network) to establish
direct communication with it. To provide some level of security, the configuration manager
would require the user to enter a password to gain access. The user interface for selecting the

Lesson 3: Communicating with an IoT Device | Topic B

106 | Certified Internet of Things (IoT) Practitioner (Exam ITP-110)

SSID and entering the network password could be provided through a simple web page hosted
on the IoT device.
• Pro: Uses technologies commonly found in most mobile devices and computers.
• Pro: Other options for configuring the IoT device can be presented along with the Wi-Fi
settings.
• Pro: Additional security could be provided through a button on the IoT device, which must
be pressed to enable the configuration mode. If such a button is provided, a pre-defined
password for the configuration manager could be provided, simplifying setup for the user.
• Con: The IoT device must include code to host a simple web server, which may consume
storage needed for other programs.

Lesson 3: Communicating with an IoT Device | Topic B

 Certified Internet of Things (IoT) Practitioner (Exam ITP-110) | 107

ACTIVITY 3-3
Providing a Wi-Fi Configuration Manager
Before You Begin
The course data files are installed on your computer in C:\095024Data. These files include a
customized version of the Arduino IDE (located in C:\095024Data\Tools\arduino), which
contains example programs that you will use in this course. The example programs are contained in
the File > Sketchbook sub-menus inside the Arduino IDE.
The ESP8266 microcontroller is connected to a USB port on the development computer. The
Arduino IDE is running, and the serial monitor is showing.

Scenario
You have previously hard-coded your prototype IoT device to connect to Wi-Fi. Now you will set it
up to present a Wi-Fi configuration manager to provide a user interface through which users can
provide it with the SSID and password whenever it cannot connect to a Wi-Fi router.
When you assign an SSID and password to the ESP8266, it caches them so it can reconnect later.
Since you've already successfully connected the device to Wi-Fi, you'll start by running a program
that will clear the previous Wi-Fi credentials.

1. Upload a program that will clear the device's current Wi-Fi configuration.
a) Select File→Sketchbook→Communicating with an IoT Device→WiFi_Forget.
The sketch opens in a new Arduino IDE window. The window you were previously using,
WiFi_Communication, is still open in the background.

Lesson 3: Communicating with an IoT Device | Topic B

108 | Certified Internet of Things (IoT) Practitioner (Exam ITP-110)

b) Close the WiFi_Communication window, and position the WiFi_Forget window side by side with the
serial monitor.
c) Select Sketch→Upload.

2. While the sketch is being compiled, examine the source code.

a) Examine the code in WiFi_Forget.

• Line 17 calls WiFi.disconnect(), which clears the previously cached Wi-Fi connection.
• Lines 13 through 14 and 20 through 21 contain print statements to show the data stored before
and after the Wi-Fi data is cleared, so you can verify the data has actually been cleared from the
device.

3. Examine the results.

Lesson 3: Communicating with an IoT Device | Topic B

 Certified Internet of Things (IoT) Practitioner (Exam ITP-110) | 109

a) When the program runs, examine the output in the serial monitor.

• The SSID and password you provided earlier are shown. Then the connection is cleared. The
second time the SSID and password are shown, they are empty text.
• The next time the device accesses Wi-Fi, it will not be able to reuse the last SSID and password.

4. Load a new sketch that uses a Wi-Fi configuration manager.

a) Select File→Sketchbook→Communicating with an IoT Device→WiFi_Manager.
The sketch opens in a new Arduino IDE window. The window you were previously using,
WiFi_Forget, is still open in the background.
b) Close the WiFi_Forget window, and position the WiFi_Manager window side by side with the serial
monitor.

5. Change the device name.

a) Examine the device name defined in line 6.
This is the name that will be shown to the user when connecting to the device as a Wi-Fi access
point. You can change this to something more meaningful and unique. In the classroom, this is
important because multiple devices may be running as access points at the same time, and you'll
want a unique ID to connect to the right one.
b) In line 6, replace YourName with your name. Just use letters for your name, and don't include any
spaces.

6. Start the process to compile and upload the sketch.

a) Make sure the serial monitor window is still showing, and ensure the baud rate is set to 9600 baud.
b) Select Sketch→Upload.

7. While the sketch is being compiled, examine the source code.

Lesson 3: Communicating with an IoT Device | Topic B

110 | Certified Internet of Things (IoT) Practitioner (Exam ITP-110)

a) Examine the setup() code in WiFi_Manager.

• Line 27 prints the currently cached SSID to the serial port. This is done only for debugging and
development purposes, since it won't be necessary to use the serial monitor in the finished
product.
• Lines 30 through 36 use the Wi-Fi manager software library to establish the Wi-Fi connection.
• The software library contains code that will set up the device as a Wi-Fi access point if it can't
use cached credentials to connect.
b) Examine the configModeCallback() code.

• This function is called when the device has to enter configuration mode (because the cached
credentials don't enable it to connect).
• More information is shown for debugging and development purposes. In an actual product, the
device might flash an LED or provide some other feedback to inform the user the device is in
configuration mode.

8. Connect to the device as an access point.

Lesson 3: Communicating with an IoT Device | Topic B

 Certified Internet of Things (IoT) Practitioner (Exam ITP-110) | 111

a) When the program runs, examine the output in the serial monitor.

• The device doesn't have a stored SSID and therefore needs the user's help to connect to a Wi-Fi
router. The user documentation for the device would provide the user with information similar to
that shown in the serial monitor to establish a connection to a new Wi-Fi router.
• In practice, you might also include a button on the device to force the device into configuration
mode when pressed. This would enable you to specify a different SSID and password, even if
the device currently has cached credentials that enable it to successfully connect.
b) Using your computer, smartphone, or tablet with a Wi-Fi capability, browse the available Wi-Fi
routers, and attach to the IoT device that you named.

• For example, in the Windows 10 Settings app, you can select Network & Internet, and then
select Show Available Networks to display available networks, as shown in the following. When
you select your device and select Connect, you will be prompted to enter the password.
c) When you are prompted for the password to the IoT device access point, enter 123!Pwd$
• Your computer is no longer connected to the local Wi-Fi network, but is instead connected to the
IoT device as a Wi-Fi access point.
• After you have logged in to the IoT device as an access point, a browser may be launched after
a few seconds.
• Depending on the computer or device you are using, the browser may automatically open the
configuration page at 192.168.4.1.
d) If your browser does not automatically open the configuration page after a few seconds, open the
address 192.168.4.1 in your browser.

Lesson 3: Communicating with an IoT Device | Topic B

112 | Certified Internet of Things (IoT) Practitioner (Exam ITP-110)

e) Examine the Wi-Fi configuration page.

• This web page is provided by the IoT device, which is running as a web server.
• The Wi-Fi network provided by the IoT device is not Internet connected. There are only two
devices on its little network—the IoT device itself, and the computer you have used to attach to
it.
• The purpose of this page is to temporarily provide an accessible user interface for the IoT
device, so you can provide the device with the SSID and password of the actual Wi-Fi network it
should attach to.

9. Configure the Wi-Fi connection.

a) Select Configure WiFi.
A list of available Wi-Fi networks is shown.
b) Select the link for the Wi-Fi network you want to attach the IoT device to (the SSID for your local Wi-
Fi network).
The SSID is copied to the upper text box.
c) In the lower text box (password), enter the password, and select save.

d) If the Credentials Saved browser window did not automatically close itself, then close it.

Lesson 3: Communicating with an IoT Device | Topic B

 Certified Internet of Things (IoT) Practitioner (Exam ITP-110) | 113

e) In the Arduino IDE, examine the serial monitor.

After a moment, the device connects to the Wi-Fi network using the SSID and password you
provided.
f) In the computer, smartphone, or tablet you used to configure the device, show the available Wi-Fi
networks again.

Your IoT device is no longer available as an access point. (It may take a moment to disappear.)

Note: You may need to reselect the local Wi-Fi router to reattach your
computer to the local Wi-Fi network. In many cases, the computer will reattach
automatically to the local Wi-Fi network once the IoT device stops functioning
as an access point.

10. Examine how the device reconnects to Wi-Fi, once it has been configured—
even if a new sketch is uploaded.
a) Select Sketch→Upload to upload a new copy of the program.
b) When the program runs, examine the output in the serial monitor.

• As long as the IoT device can successfully reattach to the network using the cached Wi-Fi
credentials, it will continue to do so.
• If the device cannot connect to Wi-Fi at any point, it will present itself as a Wi-Fi hotspot again,
so it can be reconfigured.

Lesson 3: Communicating with an IoT Device | Topic B

114 | Certified Internet of Things (IoT) Practitioner (Exam ITP-110)

11. What
do you like and dislike about using the "IoT device enters access point
mode" approach to Wi-Fi configuration on a headless device?

Lesson 3: Communicating with an IoT Device | Topic B

 Certified Internet of Things (IoT) Practitioner (Exam ITP-110) | 115

TOPIC C
Communicate Using Internet Protocols
You've enabled an IoT device to connect to the network. Now that it is on the network, it can use
application-layer messaging protocols to communicate with other devices, such as IoT gateways, or
client applications. In this topic, you will enable a device to communicate using common web
protocols provided by the Internet Protocol Suite.

The Internet Protocol Suite

Figure 3-3: The Internet Protocol Suite.

The Internet of Things, as the name implies, relies on the Internet to communicate, and underlying
the Internet is the Internet Protocol Suite, the communication standards that define how the
Internet works. The Internet Protocol Suite is also called TCP/IP after two of the major protocols
in the suite.
Thinking of the Internet Protocol Suite as a four-layer reference model may help in understanding
the tasks performed by protocols at each distinct layer, as well as how each layer interacts with
another in the communication process. These are the four layers of the TCP/IP reference model:
• Application layer: Defines the protocols used by applications as well as how host applications
interface with the transport layer protocols to access network resources.
• Transport layer: The protocols that manage session connections between host computers and
control data transfer.
• Internet layer: The protocols that package data into IP datagrams, which include source and
destination information, to control packet routing between hosts and across networks.
• Network interface layer: The protocols that define how IP datagrams are packaged and
physically transmitted through the network.

HTTP and HTTPS Web Protocols

Hypertext Transfer Protocol (HTTP) provides a standard way for applications to exchange data
such as HTML web pages, XML data, images, and so forth over the World Wide Web. Hypertext
Transfer Protocol Secure (HTTPS) is essentially the same protocol with security features added.
Applications such as web browsers and web-enabled mobile or desktop apps follow the rules of
HTTP to submit a request for information from a web server.
For example, a user might compose a simple request by entering an address in a web browser, such
as https://www.mysite.com/index.htm. Using a DNS lookup, the address for mysite.com is
Lesson 3: Communicating with an IoT Device | Topic C
116 | Certified Internet of Things (IoT) Practitioner (Exam ITP-110)

translated to an IP address, and the HTTP request composed by the browser is sent to the server.
Behind the scenes, the HTTP request is essentially a text document with lines ending with a carriage
return and line feed characters.
A request might be in the form of a GET request, which specifies the requested resource (/
index.htm), the protocol for the request (HTTP 1.1), and the web host's address.
GET /index.htm HTTP/1.1
Host: www.mysite.com
When the web server receives an HTTP or HTTPS request, it replies with a response such as the
following.
HTTP/1.1 200 OK
Date: Wed, 30 May 2018 12:22:21 GMT
Server: Apache
Last-Modified: Sun, 22 May 2018 09:33:11 GMT
ETag: "51142bc1-7449-479b075b2891b"
Accept-Ranges: bytes
Content-Length: 29769
Content-Type: text/html
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head> ...
The response begins with a header that describes what is contained in the response, followed by the
content of the response. Typically the content is an HTML page (abbreviated previously to save
space).

Send Data with a Request

With HTTP/HTTPS, data can be sent as part of a request.
Using a GET request, a small amount of data can also be sent to the server as part of the URL, as
shown.
GET /sendContactInfo.php?name=Bill%20Thornton HTTP/1.1
Host: www.mysite.com
In this example, the user's name is passed to the server within the URL using a query string
parameter. The query string follows the page name, and often begins with a question mark. With
this approach, the name data is not part of the request's content, and would therefore not be
encrypted when sent through an HTTPS request. In a web browser, it would also be visible in the
address bar as https://www.mysite.com/sendContactInfo.php?name=Bill%20Thornton.
Data that needs to be kept secure should be transmitted in a POST request using HTTPS. A POST
request includes data as part of the request. For example, when a user submits a web form, it is
typically composed as a POST request, as shown.
POST /sendContactInfo.php HTTP/1.1
Host: www.mysite.com
Content-Length: 64
Content-Type: application/x-www-form-urlencoded
name=Bill%20Thornton&address=123%20Brookdale%20Street%20Bobtown%20NY
The previous content is fairly easy to read, and the user's name and address can be easily identified.
(The %20 codes represent spaces.) If a request like this were intercepted on the network, its content
could be revealed. However, such requests are typically submitted using Secure HTTP (HTTPS), so
the content in the request would be encrypted when being sent to the server.

Web Protocols in IoT

The HTTP and HTTPS web protocols are commonly associated with web browsers and web
servers, but they are commonly used by other types of programs throughout the Internet of Things.
Lesson 3: Communicating with an IoT Device | Topic C
 Certified Internet of Things (IoT) Practitioner (Exam ITP-110) | 117

For example, web protocols can be used to provide a remote management interface for setting up
and configuring IoT devices, gateways, routers, and so forth. Devices not commonly thought of as
web servers can present themselves as a web server to provide a user interface that can be accessed
by remote users.
Cloud services that aggregate, process, and present IoT data can present users with a web
application that enables users to view aggregated data, filter and search, generate reports, and
perform other tasks.
HTML web pages provide the user interface for examples described previously. But HTML is not
the only payload that HTTP can deliver. HTTP can also be used to deliver XML, JSON, and
numerous other file formats. Behind the scenes, applications can use HTTP to communicate over
the web. Programs running throughout the entire IoT infrastructure commonly use HTTP/HTTPS
to interact with web/cloud services—exchanging data, messages, and other communications.

IP Addressing
One vision for IoT is to provide every IoT device with its own unique IP address to represent its
presence on the Internet.
Internet Protocol version 4 (IPv4), the traditional Internet addressing scheme that many users are
familiar with, can provide about four billion devices with a unique IP address, such as 184.30.114.35.
Four billion is a very large number but it is not enough to give every person on the planet his or her
own IP address for a personal device like a computer, tablet, or smartphone. Add to this the routers,
switches, gateways, and many other network devices on the Internet, and you've already run out of
addresses. With the Internet of Things, presumably billions more "things" will be added to the mix.
Cisco predicts there will be 50 billion connected devices by 2020.
Internet Protocol version 6 (IPv6) offers a solution to this problem by increasing the number of
possible addresses to 340 undecillion. (Another way of expressing that amount is 340 trillion trillion
trillions.) It's hard to imagine running out of addresses with IPv6 for a long time to come.
Furthermore, the software that supports IPv4 has been around a long time, and many security
vulnerabilities have surfaced over the years. Many cybersecurity lessons were learned before IPv6
software was developed, so simply moving to IPv6 may improve the security outlook somewhat.

Lesson 3: Communicating with an IoT Device | Topic C

118 | Certified Internet of Things (IoT) Practitioner (Exam ITP-110)

Encapsulation

Figure 3-4: Data is encapsulated at the sender and decapsulated at the receiver.

Network communication begins with an application composing the payload (such as a message or
request) to send to another device. In the case of a web application, for example, this would be in
the form of an HTTP/HTTPS request. The application opens communication with the receiver.
Depending on the type of connection it needs to establish, it will open either a TCP or UDP
connection.
The application uses the transport services provided by TCP/IP to start the process of
encapsulating the data. The data is encapsulated within a TCP segment or UDP packet. These
containers act as shipping envelopes, providing an encapsulation (wrapping) around the data and
information needed to handle that data during transit, and at its destination. It's similar to the way an
envelope provides a wrapper for a letter and provides information (such as the recipient's address)
needed during transit and delivery. Information provided at this layer includes a checksum that can
be evaluated to ensure data at the other end is intact and has been transported successfully.
The transport services then pass the encapsulated data off to Internet services, which encapsulate
the whole thing with a wrapper, which provides information used for addressing and delivery, such
as the IP addresses of the sender and receiver.
The Internet services then pass the data off to the data link and physical layers, which encapsulate it
even further, adding framing information necessary to ensure the data is physically encoded and
transported over the network.
At the other end, the encapsulation process is reversed, with the outermost wrapper removed and
information provided in the wrapper read and interpreted by the receiver to reassemble the data,
verify it, and eventually hand it off to the receiving application it was sent to.
Each layer of encapsulation provides a specific set of data to be used at the other end, so it is
important for the sender and receiver to use the same protocols at both ends of the communication.

Lesson 3: Communicating with an IoT Device | Topic C

 Certified Internet of Things (IoT) Practitioner (Exam ITP-110) | 119

Connect Different Networks

By definition, the Internet of Things involves internetworking—interconnecting local area
networks to the Internet to establish end-to-end connections between IoT devices, cloud services,
and end user applications.
Traditional IT networks have used a variety of different devices to provide connections between
different networks. For example, a bridge may be used to connect two portions of a network. The
traditional definition of a bridge is a device that connects two segments of the same type of network
—for example, two segments of a TCP/IP network.
Bridges have been used to localize traffic on one segment from reaching another segment. Only
traffic that actually needs to reach a destination in the other segment is forwarded across the bridge.
This cuts down on unnecessary traffic and improves the overall performance of the network. The
need for this type of bridge has largely been eliminated as many networks now use network
switches to isolate traffic.
Another type of bridge is a wireless bridge, which connects two segments of a network separated
by distance. For example, a wireless bridge may be used to connect a TCP/IP segment in one
building to a wireless router on a TCP/IP segment in another nearby building, essentially bridging
the networks in the two buildings.
When the various networks you are connecting all use the same networking protocols (such as
TCP/IP), communication can be relatively straightforward. However, frequently IoT involves a
variety of different networking protocols, such as Zigbee, Thread, and Bluetooth Low Energy. Some
of these protocols do not provide direct interoperability with the Internet protocols (IPv4 and IPv6)
that you must use to communicate with cloud services. In cases like this, you can use a gateway to
connect networking using different protocols.
A gateway is essentially multilingual when it comes to networking. It has the ability to physically
connect to two or more networks (such as TCP/IP, Zigbee, and Z-Wave) and has software that can
receive incoming data from one type of network and send it back out to another type of network.

IoT Gateway as a Means to Connect Different Networks

Figure 3-5: Using an IoT gateway to manage communications between Zigbee and TCP/IP
networks.

Lesson 3: Communicating with an IoT Device | Topic C

120 | Certified Internet of Things (IoT) Practitioner (Exam ITP-110)

A common network design pattern used for IoT devices and sensor networks involves setting up an
IoT gateway to serve as the communication manager between IoT devices and the cloud. The IoT
devices may only communicate with each other and with the IoT gateway over the local network,
whereas the IoT gateway can communicate over the local network and over the Internet. The IoT
gateway uses TCP/IP to communicate over the Internet, enabling it to handle all communication
with cloud services on behalf of the devices in its local network.
Although a Wi-Fi or Ethernet based TCP/IP network could also be used for the local network, a
lightweight network protocol geared toward IoT, such as Zigbee or Z-Wave, may be used for local
communications. This enables the constrained devices (IoT devices and sensors) to communicate as
quickly as possible, offloading the more demanding communication tasks to the IoT gateway.
Note: Networking tasks such as encapsulation, bridging, encryption, VPN tunneling, and so
forth can add significant overhead to networking, increasing the required bandwidth, electrical
power, time, and other resources. An important part of designing an IoT network is planning
where these tasks should occur.

Note: Although IPv6 addressing would enable every IoT device to have its own Internet
address, IPv6 has not been fully adopted yet, and even where it has been adopted, the best
option may not be to provide every IoT device with its own global IP address—or with any IP
address at all.

Smart Home Hubs

Consumer-oriented IoT product lines, particularly those providing "smart home" capabilities, often
include a product that functions as the gateway between the local sensor network and the Internet.
The product is typically marketed as a hub, gateway, or controller. It may be sold as a standalone
device, but a hub capability may also be provided in a hybrid device that serves some other purpose,
such as a thermostat or smart speaker.
For example, the Amazon Echo Plus smart speaker can connect to Wi-Fi, Bluetooth, and Zigbee. In
addition to functioning as a smart speaker, it also includes basic smart home hub capabilities.
Responding to voice commands, the smart speaker can discover and control smart home devices,
including devices produced by other manufacturers. Using its Wi-Fi capabilities, the smart speaker
manages communication between Zigbee devices and the Internet. Using an accompanying
smartphone app, the user can perform additional configuration of smart home devices that the hub
discovered, and can program "routines" to perform multiple activities based on a single trigger, such
as changing the home temperature, turning on lights, raising window blinds, and starting to brew
coffee when the user issues a particular voice command. The Nest thermostat is another device that
doubles as a smart home hub. It supports networking of devices that use the Thread protocol.
Companies like Honeywell that produce a wide range of products for heating, air conditioning,
security, and related home automation products provide gateways (such as Honeywell's RedLINK
gateway) and hubs that simplify installation when using multiple products from the same product
line. Some use proprietary protocols, but others support standard protocols to enable integration
with third-party products. In many cases, they also provide connected services that enable customers
to view and control their connected products from computers and mobile devices.
Standalone smart home hubs tend to support more protocols than hybrid devices. For example, the
Samsung SmartThings Hub supports Z-Wave, Zigbee, Wi-Fi, and Ethernet, enabling it to support a
wide range of smart home devices.

Routing and QoS

When designing communications for IoT, it is often necessary to prioritize certain communications
for fast delivery and reliability. In some cases, for example, data may need to be processed and acted
upon very quickly. In many cases, the protocols you use may provide quality of service (QoS)

Lesson 3: Communicating with an IoT Device | Topic C

 Certified Internet of Things (IoT) Practitioner (Exam ITP-110) | 121

parameters that enable you to prioritize some communications over others, or to specify reliability
requirements.
Typically, QoS settings involve a tradeoff. For example, if you configure communications to be
acknowledged by the receiver, then you can ensure that a message reached its destination. But such
acknowledgment produces more network traffic and takes longer to complete. So before you design
and configure quality of service, you must take time to identify which communications have priority,
and determine the rules underlying your priorities.
Note: If you give one type of communication more priority, then other types of
communications will have less priority. If you give all communications high priority, then
essentially all communications will have average priority.
Multiple layers of protocols may be involved in a particular communication scenario, and each layer
of protocols may have its own QoS parameters that you can specify. For example, an application
may use a certain messaging protocol that provides quality of service parameters, and the network
that application is communicating over may use a network protocol that has its own QoS
parameters. So tailoring quality of service may involve multiple QoS parameters in multiple protocol
layers.
For example, IoT devices might be using an unreliable network-layer protocol such as User
Datagram Protocol (UDP), where delivery is not acknowledged or guaranteed. But QoS parameters
used in the Application layer can ensure the message gets delivered. For example, the messaging
service could be configured with a QoS setting to resend messages until they are acknowledged by
the receiver.
Also, note that QoS options must have some leeway to prioritize traffic or routing in order to have
an impact. This can be useful, for example, on a wireless mesh network, where multiple paths may
exist between two points.
Note: In practice, under certain conditions (such as very high or very low network traffic
volumes), QoS options may have little effective impact on the quality of service provided.

Networking Abstraction
It is predicted that billions of new IoT devices will be added to networks in the next few years.
Many of these devices will be mobile, with applications in transportation, logistics, wearables, and so
forth. And many of the devices that are stationary will be added and removed frequently. The
predicted increase in network traffic and complexity of the communications involved in IoT will
bring new challenges for network administrators, programmers, and system integrators.
Careful design, planning, and implementation strategies can help to make IoT networks easier to
reconfigure and more resilient to problems caused by change. For example:
• Using routing and quality of service parameters to make the most efficient use of the network.
• Distributing processing and communication tasks where they can be handled most effectively
(such as IoT devices handing off heavy processing and communication tasks to an IoT gateway).
• Strategically selecting appropriate network protocols and technologies for specific tasks within
the overall architecture (such as lightweight encryption and communication protocols for
constrained devices).
• Using wireless networks to reduce the need to physically reconfigure networks.
• Using mesh networking topologies for wireless devices to provide alternate paths as devices go
offline.
However, in many cases, optimum network configuration will be a moving target. Scaling and
reconfiguring network capabilities will be a never-ending task. A possible solution to this problem is
to automate the task of reconfiguring the network. Network virtualization technologies, such as
software-defined networking (SDN) and network function virtualization (NFV), help to make
this kind of automation possible.

Lesson 3: Communicating with an IoT Device | Topic C

 122 | Certified Internet of Things (IoT) Practitioner (Exam ITP-110)

SDN

Figure 3-6: Components of software-defined networking.

Software-defined networking (SDN) technology automates network management tasks by

separating the processes traditionally performed by network devices such as routers. These
processes are divided into two planes:
• Control plane: Oversees and determines how network packets should be forwarded
• Data plane: Forwards network packets to their destination
You might think of the control plane as the brains of the routing operation and the data plane as the
brawn that gets the job done. By separating these functions, the control plane is decoupled from
router firmware and policies, and can be implemented through centralized, programmable code,
enabling routing and network behavior to be updated dynamically in response to changing
conditions.
Rather than each router having to be configured independently, all routers follow policies imposed
through a centralized console, enabling quick adjustments that affect every router, and enabling
them to work in a more cooperative manner, based on changing demands of the network.
The application layer may implement a wide range of different services to control and manage the
network, such as data flow and load balancing, intrusion detection and other security services, and
network monitoring and provisioning. Such functions can be managed manually by a network
administrator or automatically on demand, through automation software.
Note: Software-defined networking is based on design principles first used in the public
switched telephone network, which were developed to simplify provisioning and management of
telephone switching equipment.

Network Function Virtualization

Network Function Virtualization (NFV) is the process of moving network services such as firewalls,
intrusion detection and prevention systems, caching, and load balancers from traditional dedicated
hardware into virtual machines running on commodity hardware. Driven by a software defined
networking system, these functions can be automatically scaled up or down as needed, reducing
costs associated with maintaining unused hardware while providing the ability to quickly scale when
there is demand, and deploy functions where needed.

Lesson 3: Communicating with an IoT Device | Topic C

 Certified Internet of Things (IoT) Practitioner (Exam ITP-110) | 123

Note: NFV and SDN are sometimes confused. They are complementary but different
technologies. While NFV and SDN are similar in that they move network services to a virtual
environment, NFV does not include policies to automate the environment.

Lesson 3: Communicating with an IoT Device | Topic C

124 | Certified Internet of Things (IoT) Practitioner (Exam ITP-110)

ACTIVITY 3-4
Communicating with an IoT Device Using HTTP
Before You Begin
The course data files are installed on your computer in C:\095024Data. These files include a
customized version of the Arduino IDE (located in C:\095024Data\Tools\arduino), which
contains example programs that you will use in this course. The example programs are contained in
the File > Sketchbook sub-menus inside the Arduino IDE.
The ESP8266 microcontroller is connected to a USB port on the development computer. The
Arduino IDE is running, and the serial monitor is showing. You have successfully connected the
device to the Wi-Fi network, and the SSID and password are now cached on the device.

Scenario
In most cases, IoT devices are "headless." That is they do not have their own monitor or display
that can be used to provide a user interface. The typical IoT device is controlled through a remote
client application the user launches on a computer or mobile device. In some situations, however,
the IoT device might have its own compact web server, which a user can access through a web
browser to communicate with the device.
In this activity, you will explore this approach by loading a simple web server on the IoT device, and
accessing it in your development computer's web browser. Controls on the web page will enable you
to turn the device's onboard LED on or off.

1. Load a sketch that configures the IoT device as a web server.

a) Select File→Sketchbook→Communicating with an IoT Device→Web_Server.
The sketch opens in a new Arduino IDE window. The window you were previously using,
WiFi_Manager, is still open in the background.
b) Close the WiFi_Manager window, and position the Web_Server window side by side with the serial
monitor.

2. Start the process to compile and upload the sketch.

a) Select Tools→Serial Monitor to display the serial monitor window, and ensure the baud rate is set to
9600 baud.
b) Select Sketch→Upload.

3. While the sketch is being compiled, examine the source code.

Lesson 3: Communicating with an IoT Device | Topic C

 Certified Internet of Things (IoT) Practitioner (Exam ITP-110) | 125

a) Examine lines 1 through 23 in the Web_Server sketch.

• Much of this code builds on the code from the previous activity.
• Line 4, which is new, imports a software library that enables the program to function as a web
server.
• Line 18 defines an object that will be used to manage the web server. As is typical, the web
server will run on port 80.
• Lines 21 and 22 define objects that will be used in the program. The LED will initially be set to
HIGH. On the microcontroller you're using, this will set the LED to be off initially.

Lesson 3: Communicating with an IoT Device | Topic C

126 | Certified Internet of Things (IoT) Practitioner (Exam ITP-110)

b) Examine the setup() function.

• Again, much of this code has been carried over from the previous sketch. It establishes a
connection with the serial monitor and sets up Wi-Fi.
• Line 43 is new. This line starts the web server. You'll be able to access it using the IP address
provided by the Wi-Fi connection.
• Lines 53 and 54 set the initial state of the LED to off, using the LED pin value that was initialized
in line 21.

Lesson 3: Communicating with an IoT Device | Topic C

 Certified Internet of Things (IoT) Practitioner (Exam ITP-110) | 127

c) Examine lines 60 through 79 of the loop() function.

• These lines process the web request, which is communicated in a format that adheres to the
HTTP protocol.
• The request is issued by the user's web browser when the user enters the URL in the address
bar.
• The request is output to the serial port, so you'll be able to see the actual request in the serial
monitor when you run the program.
• Lines 77 and 78 extract text from the URL that is used to communicate the desired LED state,
and line 79 sets the data pin for the LED to set its state based on the request.

Lesson 3: Communicating with an IoT Device | Topic C

128 | Certified Internet of Things (IoT) Practitioner (Exam ITP-110)

d) Examine lines 81 through 100 of the loop() function.

• These lines compose the web response, which is communicated back to the user's web browser
in a format that adheres to the HTTP protocol.
• This HTTP response is returning web page content in the HTML format. The DOCTYPE of the
response, specified in line 85, is HTML.

4. Access the device through a web browser.

a) When the program runs, examine the output in the serial monitor.

The serial monitor shows the device's web address. You will use the address shown in your serial
monitor to load the configuration page in your web browser.

Lesson 3: Communicating with an IoT Device | Topic C

 Certified Internet of Things (IoT) Practitioner (Exam ITP-110) | 129

b) On your development computer, launch a web browser and enter the web address of your IoT
device.

Note: Your device may use a different URL than the one shown here. Use the
address that was shown in your serial monitor in step 4a.
c) Examine the microcontroller, and verify that its onboard LED is off.
d) Examine the serial monitor.

One or more HTTP requests are shown in the serial monitor.

• The first request is GET /, which retrieves the main web page from the server.
• The second request, if present, is GET /favicon.ico. This refers to the favorites icon, which
is used when a user creates a shortcut to the web page. How and when the favorites icon is
requested varies from one browser to another, so you might not see this request, or you might
see multiple instances of it.

Lesson 3: Communicating with an IoT Device | Topic C

130 | Certified Internet of Things (IoT) Practitioner (Exam ITP-110)

e) Select the Turn it ON link. Observe the web page that loads, and the state of the microcontroller's
LED.

• Once the request is processed, the onboard LED illuminates.

• The new web page is loaded, showing that the LED is now on, and providing a link to turn it off
again.
• The LED state was passed to the web server (your IoT device) through the state=on
querystring parameter in the URL.
f) Examine the GET /led?state=on HTTP request in the serial monitor.

Note: You may need to scroll up to see this request if another GET /
favicon.ico request was issued.
• Querystring parameters are often used to pass data values to the server as part of the URL.

Lesson 3: Communicating with an IoT Device | Topic C

 Certified Internet of Things (IoT) Practitioner (Exam ITP-110) | 131

g) Position the mouse pointer over the Turn it OFF link, and examine the link information shown in the
browser's status bar.

h) In the browser address bar, change on to off, and press Enter to load the revised address.
The LED is turned off, and the new page provides a link to turn it on again.

5. What issues should you consider when designing a direct web-based

interface for an IoT device, like the one you experimented with in this activity?

6. Clean up the desktop.

a) Close all browser windows.
b) Close all Arduino IDE windows that are open on your desktop.

Licensed For Use Only By: Multimatics . [email protected] Nov 22 2019 3:26AM
Lesson 3: Communicating with an IoT Device | Topic C
132 | Certified Internet of Things (IoT) Practitioner (Exam ITP-110)

Summary
In this lesson, you used various methods to communicate with an IoT device. You communicated
over a serial cable, and you used a wireless network connection. You also used the Internet Protocol
Suite and HTTP to provide the IoT device with a remote user interface to configure its Wi-Fi
connection, view its current state (LED status), and control it (turn the LED on or OFF).

As simple as it is, what major software subsystems are now installed on the
device?

What challenges will you encounter in provisioning IoT devices on your

networks?

Note: Check your CHOICE Course screen for opportunities to interact with your classmates,
peers, and the larger CHOICE online community about the topics covered in this course or
other topics you are interested in. From the Course screen you can also access available
resources for a more continuous learning experience.

Lesson 3: Communicating with an IoT Device |