Gautam Buddha University

IOT LAB MANUAL CS481

Submitted to Submitted by
Ashutosh Dixit Prakash Kumar
Roll no 19BCS122
 Index
S.No. Title Teacher
Signature

1. Basics of sensor networks, IoT,

6LoWPAN nodes (used in IoT
applications), OS Contiki, Network
Simulator COOJA, Download and
Installation of Contiki (OS for IoT),
Creation of Virtual Machine,
Download and Installation of VM
Player.

2. Initialization of Network Simulator COOJA,

Understanding of all windows on simulator,
study the Mote Configuration, Program the
Motes so that all motes display “Hello World”
on the output window, Change the values in
files to display any desired output by all the
motes.
3. Create a network topology having 5
motes of similar configuration.
Program them to broadcast the data.
Capture the broadcasted packets
and analyze the values of various
headers like IPv6, using analyzer.
Repeat the program by changing the
transmission range of all motes and
observe the effect.

4. Create a complete wireless sensor

network (WSN) topology having
6 motes. Configure 1 mote as
Border Router and rest of the 5
motes as sender Motes. Go to the
browser and check for the values
of routing table of your WSN.

5. Repeat the above program on

different topology (some motes
should not be in the direct range
of border router) and check its
effect on routing table of border
router.
6. Study of MoteWorksNetwork
Landscape for deployment of
wireless sensor network.

7. Study of MoteConfig and MoteView.

Program the motes using
MoteConfig and create a live sensor
network

8. To study and verify the self-healing

property of wireless sensor network.

9. Introduction to Cisco Packet Tracer

and configuring various network
devices, hosts & transmission media.
Study of components of IoT and
basic implementation of IoT
network on packettracer.

10. To deploy a home automation

application and perform remote
monitoring and control of
homeappliances
 Experiment – 1

Aim: Basics of sensor networks, IoT, 6LoWPAN nodes (used in IoT applications), OS Contiki,
Network Simulator COOJA, Download and Installation of Contiki (OS for IoT), Creation of
Virtual Machine, Download and Installation of VM Player.

Steps to be followed:
Steps to Download Instant Contiki
 Type “Contiki OS” in the browser.
 http://contiki-os.org/ Official website of Contiki
 Type “download instant contiki 2.7/3.0” in the browser.
 https://sourceforge.net/projects/contiki/files/Instant%20Contiki/Instant%20Contiki%203.0/ To
download Instant Contiki

Steps to Download VM Player

 After downloading Contiki, download VM Player.
 For this type “Download VM Player” in browser.
 https://my.vmware.com/en/web/vmware/downloads/info/slug/desktop_end_user_computing/vmwar
e_workstation_player/15_0 to download VM player
 You may choose higher version too i.e.16.0.
 Click on “Go to Downloads” on right side.
 Select desired option.

Steps to Install VM Player for VM

 After downloading, put the files on desktop.
 Install VM Player.

Steps to Install Instant Contiki

 You will see “Instant Contiki 2.7 zip” folder on desktop.
 Extract Contiki folder.
 After extracting, double click the folder.
 Various files will be visible.
 Choose “Instant_Contiki_....vmx” file.
 Kindly note you have to choose “.vmx” file.

Observation: The icons for instant Contiki and VM player will appear on the screen.

Result: VM is created and Contiki is ready to use.

 Experiment – 2

Aim: Initialization of Network Simulator COOJA, Understanding of all windows on simulator,

study the Mote Configuration, Program the Motes so that all motes display “Hello World” on the
output window, Change the values in files to display any desired output by all the motes.

Steps to be followed:
Steps to Start Instant Contiki
 Welcome screen of Instant Contiki will open.
 It may have 1/2/3 icons.
 Icon 1: Terminal
 Icon 2: Cooja
 Icon 3: Wireshark
 Icon 2 and 3 may or may not be present.

Steps to Start Cooja

 Start Cooja, either by double clicking on its icon or by double clicking on terminal icon.
 If clicking on terminal, then a command based window will appear.
 On $ prompt, write “ cd contiki/tools/cooja”
 Now you are in Cooja directory.
 On $ prompt, write the command “ant run” to start Cooja network simulator window.

Running Cooja Network Simulator

 After pressing “enter”, files will start building.
 Above step will take approximately a minute.
 After that you will see the screen of your Cooja network simulator.

Steps to configure and program the motes

 Go to FILE. Click new simulation. Click on create.
 Select motes in network simulator window. Click add motes. Create new mote type. Select sky
motes.
 In mote type window select home => user =>Contiki 2.7 => examples => hello-world =>hello-
world.c
 Choose number of motes to be added. Click add motes.
 Run the simulation.

Observation: Various motes will appear on screen ready to print their message.

Result: All motes which are on network simulator window will print “Hello World” on the screen.
 Experiment – 3

Aim: Create a network topology having 5 motes of similar configuration. Program them to
broadcast the data. Capture the broadcasted packets and analyze the values of various headers like
IPv6, using analyzer. Repeat the program by changing the transmission range of all motes and
observe the effect.

Steps to be followed:
Steps to configure and program the motes to broadcast the data.
 Go to FILE. Click new simulation. Click on create.
 Select motes in network simulator window. Click add motes. Create new mote type. Select sky
motes.
 In mote type window select home => user =>Contiki 2.7 => examples => IPv6 => simple-udp-rpl
=>broadcast.example.c
 Click open
 Click compile
 Click create
 Choose number of motes to be added.
 Write 5 in this experiment. Click add motes.

Steps to connect and use packet analyzer

 Click on tools.
 Choose radio messages.
 Choose 6LoWPAN analyzer.
 Click start
 See values of packets in analyzer window.

Steps to change the transmission value

 Right click on network window.
 Select change transmission range.
 Change Tx range.
 Reload the program.

Observation: 5 motes will appear on screen ready to broadcast their message.

Result: All motes which are on network simulator window will start broadcasting their data.
 Experiment – 4

Aim: Create a complete wireless sensor network (WSN) topology having 6 motes. Configure 1
mote as Border Router and rest of the 5 motes as sender Motes. Go to the browser and check for
the values of routing table of your WSN.

Steps to be followed:
Steps to configure and program the motes as border router.
 Go to FILE. Click new simulation. Click on create.
 Select motes in network simulator window. Click add motes. Create new mote type. Select sky
motes.
 In mote type window select home => user =>Contiki 2.7 => examples => IPv6 =>rpl-border-router
=> border-router.c
 Click open
 Click compile
 Click create
 Choose 1 mote to be added.
 Click add motes.

Steps to configure and program the motes as sender motes.

 Select motes in network simulator window. Click add motes. Create new mote type. Select sky
motes.
 In mote type window select home => user =>Contiki 2.7 => examples => IPv6 =>skywebsense
=>skywebsense.c
 Click open
 Click compile
 Click create
 Choose 5 mote to be added.
 Click add motes.
Steps to connect border router
 Open terminal
 Cd Contiki/examples/ipv6/rpl-border-router
 $make connect – router-cooja
 Press enter
Steps to create routing table
 Start simulation.
 Go back to terminal.
 Copy ipv6 address.
 Paste in browser window.
 Press enter
 Routing table will be displayed on the screen.

Observation: 6 motes will appear on screen. 1 mote is border router and other 5 are sender motes.
Result: Border router is created and routing table is displayed on the screen.
 Experiment – 5

Aim: Repeat the above program on different topology (some motes should not be in the direct
range of border router) and check its effect on routing table of border router.
Steps to be followed:
Steps to configure and program the motes as border router.
 Go to FILE. Click new simulation. Click on create.
 Select motes in network simulator window. Click add motes. Create new mote type. Select sky
motes.
 In mote type window select home => user =>Contiki 2.7 => examples => IPv6 =>rpl-border-router
=> border-router.c
 Click open
 Click compile
 Click create
 Choose 1 mote to be added.
 Click add motes.
Steps to configure and program the motes as sender motes.
 Select motes in network simulator window. Click add motes. Create new mote type. Select sky
motes.
 In mote type window select home => user =>Contiki 2.7 => examples => IPv6 =>skywebsense
=>skywebsense.c
 Click open
 Click compile
 Click create
 Choose 5 mote to be added.
 Click add motes.

Steps to connect border router

 Open terminal
 Cd Contiki/examples/ipv6/rpl-border-router
 $make connect – router-cooja
 Press enter
Steps to create routing table
 Start simulation.
 Go back to terminal.
 Copy ipv6 address.
 Paste in browser window.
 Press enter
 Routing table will be displayed on the screen.

Observation: 6 motes will appear on screen. 1 mote is border router and other 5 are sender motes.
Result: Border router is created and routing table is displayed on the screen. The motes which are
not in direct range of border router, routing paths will be displayed.
 Experiment- 6
Part (A)
Aim: Study of MoteWorksNetwork Landscape for deployment of wireless sensor
network.
Theory: A wireless network deployment is composed of the three distinct software tiers:

1. The Mote Tier, where XMeshresides, is the software that runs on the cloud of sensor nodes
forming a mesh network. The XMeshsoftware provides the networking algorithms
required to form a reliable communication backbone that connects all the nodes within the mesh
cloud to the server.
2. The Server Tier is an always-on facility that handles translation and buffering of data
coming from the wireless network and provides the bridge between the wireless Motes and the
internet clients. XServeand XOtapare server tier applications that can run on a PC or Stargate.
3. The Client Tier provides the user visualization software and graphical interface for
managing the network. Memsic provides free client software called MoteView.

XMesh Mote Tier: XMeshis a full featured multi-hop, ad-hoc, mesh networking protocol
developed by Memsic forwireless networks. An XMeshnetwork consists of nodes (Motes) that
wirelessly communicate toeach other and are capable of hopping radio messages to a base station
where they are passed to aPC or other client. The hopping effectively extends radio communication
range and reduces thepower required to transmit messages. By hopping data in this way, XMeshcan
provide twocritical benefits: improved radio coverage and improved reliability. Two nodes do not
need to bewithin direct radio range of each other to communicate. A message can be delivered to
one ormore nodes in-between which will route the data. Likewise, if there is a bad radio link
betweentwo nodes, that obstacle can be overcome by rerouting around the area of bad service.
Typicallythe nodes run in a low power mode, spending most of their time in a sleep state, in order
toachieve multi-year battery life.XMeshprovides a TrueMesh networking service that is both self-
organizing and self-healing.
XMeshcan route data from nodes to a base station (upstream) or downstream to individual nodes. It
can also broadcast within a single area of coverage or arbitrarily between any two nodes
in a cluster. QOS (Quality of Service) is provided by either a best effort (link level
acknowledgement) and guaranteed delivery (end-to-end acknowledgement). Also, XMeshcan be
configured into various power modes including HP (high power), LP (low power), and ELP
(extended low power).

XServe Server Tier: XServeserves as the primary gateway between wireless mesh networks and
enterpriseapplications interacting with the mesh. At its core, XServeprovides services to route data
to andfrom the mesh network with higher level services to parse, transform and process data as it
flowsbetween the mesh and the outside applications. Higher level services are customizable
usingXML based configuration files and loadable plug-in modules.XServeoffers multiple
communication inputs for applications wishing to interact with XServeorthe mesh network. Users
can interact with XServethrough a terminal interface applications canaccess the network directly or
through a powerful XML RPC command interface.

MoteView Client Tier: MoteViewis the client user interface that enables MoteWorksto deliver an
end-to-end solutionacross all tiers of wireless sensor networks. MoteViewdisplays the information
from the networkto developers or end-users. The entire network or individual nodes can be
displayed andanalyzed in graphical charting or textual format. MoteView’s playback capability
allowshistorical viewing of network status and sensor readings over time, and is based on the
logginginformation stored in XServe. MoteView’s analysis capabilities allow automatic e-mail
alertswhen user-definable conditions are met. MoteViewenables end-users to optimize network
layout and configuration, analyze sensor information interactively and then take corrective action.
MoteViewprovides an interface to remotely configure motes in the wireless network. Each node
can be individually updated with configuration parameters provided by the mote. This makes it
transparent for the user of an installed wireless sensor network to configure motes, e.g. change
frequency of sensor readings, without requiring any programming knowledge.

Result:MoteWorksNetwork Landscape for deployment of a wireless sensor network has been

studied successfully.

Part(B)

Aim: Study of TinyOS and nesC

Theory:

TinyOS: TinyOS is an open-source operating system designed for wireless embedded sensor
networks. Itfeatures a component-based architecture, which enables rapid innovation and
implementationwhile minimizing code size as required by the severe memory constraints inherent
in sensornetworks. TinyOS’s component library includes network protocols, distributed services,
sensordrivers, and data acquisition tools—all of which can be used as-is or be further refined for
acustom application. TinyOS’s event-driven execution model enables fine-grained
powermanagement yet allows the scheduling flexibility made necessary by the unpredictable nature
ofwireless communication and physical world interfaces.TinyOS is not an operating system (“OS”)
in the traditional sense; it is a programmingframework for embedded systems and set of
components that enable building an application specificOS into each application. The reason for
this is to ensure that the application code has anextremely small memory foot print. In addition
TinyOS is designed to have no file system,supports only static memory allocation, implement a
simple task model, and provide minimaldevice and networking abstractions.

TinyOS has a component-based programming model (codified by the nesC language). Like other
operating systems, TinyOS organizes its software components into layers. The lower the layer the
closer it is to the hardware; the higher the component, the closer it is to the application. A complete
TinyOS application is a graph of components, each of which is an independent computational
entity.

Components have three computational concepts: 1) commands, 2) events, and 3) tasks. Commands
and events are mechanisms for inter-component communication, while tasks are used
to express intra-component concurrency. A command is typically a request to a component to
perform a service. A typical example is starting a sensor reading. By comparison, an event would
signal the completion of that service. Events may also be signaled asynchronously, for example,
due to hardware interrupts or message arrival. From a traditional OS perspective, commands are
analogous to downcalls and events to call backs. Commands and events cannot block. However,
a request for a service is split-phase in that the request for service (the command) and
thecompletion signal (the corresponding event) are decoupled. The command returns immediately
and the event signals completion at a later time. Rather than performing a computation
immediately, commands and event handlers may post a task, a function executed by the TinyOS
scheduler at a later time. This allows commands and events to be responsive, returning immediately
while deferring extensive computation to tasks. While tasks may perform significant computation,
their basic execution model is run-to completion, rather than to run indefinitely; this allows tasks to
be much lighter-weight than threads. Tasks represent internal concurrency within a component and
may only access state information within that component. The TinyOS scheduler uses a non-
preemptive, first in, first out (“FIFO”) scheduling policy.

The nesC Language: The nesC (network embedded systems C) is an extension to C designed to
embody thestructuring concepts and execution model of TinyOS. The basic concepts behind nesC
are:

Separation of construction and composition

Programs are built out of components, which are assembled (“wired”) to form whole programs.
Components define two scopes, one for their specification (containing the names of their interface
instances) and one for their implementation. Components have internal concurrency in the form of
tasks. Threads of control may pass into a component through its interfaces. These threads are
rooted either in a task or a hardware interrupt.

Specification of component behavior in terms of set of interfaces

Interfaces may be provided or used by the component. The provided interfaces are intended to
represent the functionality that the component provides to its user, the used interfaces represent the
functionality the component needs to perform its job.

Interfaces are bidirectional

Interfaces specify a set of functions to be implemented by the interface’s provider (commands) and
a set to be implemented by the interface’s user (events). This allows a single interface to represent a
complex interaction between components (e.g. registration of interest in some event, followed by a
callback when that event happens). This is critical because all lengthy commands in TinyOS (e.g.
send packet) are non-blocking; their completion is signaled through an event (send done). By
specifying interfaces, a component cannot call the send command unless it provides an
implementation of the sendDone event. Typically commands call downwards, i.e., from application
components to those closer to the hardware, while events call upwards.

Components are statically linked to each other via their interfaces

This increases runtime efficiency, encourages robust design, and allows for better static analysis of
programs.

Use of whole-program compilers

NesC is designed under the expectation that code will be generated by whole-program compilers.
This allows for better code generation and analysis. An example of this is nesC’s compile-time data
race detector.

Tasks and interrupt handlers

The concurrency model of nesC is based on run-to-completion tasks, and interrupt handlers which
may interrupt tasks and each other. The nesC compiler signals the potential data races caused by
the interrupt handlers.

Result: TinyOS which is an open-source operating system designed for wireless embedded sensor
networks has been studied successfully. The basic concepts of nesC which an extension to C
designed to embody thestructuring concepts and execution model of TinyOS has also been studied.
 Experiment: - 7
Part(A)
Aim: Study of MoteConfig and MoteView. Program the motes using MoteConfig and create a live
sensornetwork

Theory:MoteConfigis a Windows-based GUI utility for programming Motes. This utility provides
an interface for configuring and downloading pre-compiled XMesh/TinyOS firmware applications
onto Motes. MoteConfig allows the user to configure the Mote ID, Group ID, RF channel and RF
power. The user can also enable the over-the-air-programming feature present on all XMesh- based
firmware. The Over-The-Air-Programming (OTAP) feature allows users to reprogram a Mote over
a wireless link. OTAP allows one or more Motes in the XMeshnetwork to receive new firmware
images from XServe(via the XOtapservice).

Each Mote has a 512kB external non-volatile flash divided into 4 slots. These slots have a default
size of 128 kB. Slot 0 is reserved for the OTAP image. Slots 1, 2 and 3 can be used for user-
specified firmware. During the OTAP process, the server sends a command to the Mote to reboot
into the OTAP image (slot 0). A user-specified firmware image is broken up into fragments and
transmitted to the Mote and stored into Slot 1, 2 or 3. The server can send a message to transfer the
newly uploaded firmware into the program flash and reboot the Mote.

MoteViewis designed to be an interface (“client tier”) between a user and a deployed network of
wireless sensors. MoteViewprovides the tools to simplify deployment and monitoring. It also
makes it easy to connect to a database, to analyze, and to graph sensor readings. Three layer
framework is used for deploying a sensor network system. The first part is the Mote layer or sensor
mesh network. The Motes are programmed with XMesh/TinyOS firmware (“application”) to do a
specific task: e.g., microclimate monitoring, asset tracking, intrusion detection, etc. The second
layer or Server tier provides data logging and database services. At this layer sensor readings arrive
at the base station (e.g., MIB510, MIB520, MIB600, or Stargate) and are stored on a server or
Stargate. The third part is the client tier in which software tools provide visualization, monitoring,
and analysis tools to display and interpret sensor data. MoteViewsupports all of Memsic’s sensor
and data acquisition boards as well as the MICA2, MICA2DOT, and MICAz processor/radio
platforms. In addition, MoteView can be used to deploy and monitor sensor integrated platforms
such as the MSP Mote security/intrusion detection system and the MEP Mote environmental
monitoring system.
MoteViewhas four main user interface sections:

1. Toolbar / Menus: Allows the user to specify actions and initiate command dialogs.
2. Node List: Shows all known nodes in a deployment and health status summary.
3. Visualization Tabs: Enables the user to view the sensor data in various ways.
4. Server / Error Messages: Displays a log of server events and incoming messages.

Result: MoteConfig and MoteView have been studied successfully.

Part(B)

Aim:. Connect the live sensor network to a local PC and analyze the results usingMoteview.

Theory: Following steps are used to access data from a live sensor network connected to a local
PC via the MIB510, MIB520 or MIB600 gateway:

1. Select File > Connect to WSN… from the menu. Select the Mode tab, check on Acquire Live
Data as operation mode and Local as acquisition type and click on Next >>.

2. In the Gateway tab, specify the Interface Board type, Port/Host Name etc as described below.
i. If using a MIB510, in the Gateway tab make sure that the MIB510’s COM is set to the correct
port number and that the baud rate is 57600.
ii. If using MIB520, enter the higher of the 2 COM ports installed by the MIB520’s driver and set
the baud rate to 57600.
iii. If using a MIB600, select MIB600 from Interface Board dropdown and enter the IP address of
the MIB600 in the Hostname text-box. The Port should default to 10002.

Once the Gateway settings are complete, click on Next >>.

3. In the Sensor Board tab, uncheck the View Alternate Table checkbox and choose the XMesh
Application Name that matches the firmware programmed into the Mote from Application Name
dropdown. Click on Done.
 Result: A live sensor network has been connected to a local PC and data is received successfully
on PC.
Precautions:
1. Check the Live check box on the main MoteViewscreen if it has not been previously checked.
2. Use the Server Messages pane at the bottom of your MoteViewdisplay to verify that node data is
being received by your PC.
 Experiment: - 8
Aim: To study and verify the self-healing property of wireless sensornetwork.

Theory: Following steps are required:

1. Place the programmed motes at desired locations covering a small geographical area.

2. Connect the live wireless sensor network to PC and observe the data collected from various nodes
through MoteView.

3. Once live data collection started, define and view the topology of mote deployment by using the
Topology tab in MoteView .

4. Nodes can be dragged and placed at a new location on the map with a left click of the mouse.
Node locations are stored in the database and are shared by all users of that database.

5. Under the visualization properties the time duration after which the link between the nodes goes
grey can be specified. If a packet is not received from any after the specified minutes, the link
would turn grey.

6. To observe the self –healing property of sensor network, place one of the motes to a distant
location.

Observations: A change in topology is observed on placing a mote to a distant location. Instead of

a direct link between the mote and base station, an indirect link through a different mote becomes
active, depicting the self healing property of wireless sensor network.

Result: Self-healing property of wireless sensor network has been studied and verified.
 Experiment: - 9
Aim: - Introduction to Cisco Packet Tracer and configuring various network devices, hosts &
transmission media. Study of components of IoT and basic implementation of IoT network on
packettracer.

Theory:-Packet Tracer is a cross-platform visual simulation tool designed by Cisco Systems that
allows users to create network topologies and imitate modern computer networks. The software
allows users to simulate the configuration of Cisco routers and switches using a simulated
command line interface. Packet Tracer makes use of a drag and drop user interface, allowing users
to add and remove simulated network devices as they see fit. The software is mainly focused
towards Certified Cisco Network Associate Academy students as an educational tool for helping
them learn fundamental CCNA concepts. Previously students enrolled in a CCNA Academy
program could freely download and use the tool free of charge for educational use. Packet Tracer
can also be run on Linux, Microsoft Windows, and macOS. Similar Android and iOS apps are also
available. Packet Tracer allows users to create simulated network topologies by dragging and
dropping routers, switches and various other types of network devices. A physical connection
between devices is represented by a 'cable' item. Packet Tracer supports an array of
simulated Application Layer protocols, as well as basic routing with RIP, OSPF, EIGRP, BGP, to
the extents required by the current CCNA curriculum. As of version 5.3, Packet Tracer also
supports the Border Gateway Protocol. Cisco Packet Tracer is a Cisco proprietary multi-platform
tool that enables possibility for students to create networking and IoT simulations without need of a
hardware or preexisting network. The tool is free of charge, runs on the major operating systems
and it is downloadable from Cisco NetAcad page for all students and teachers having a valid
NetAcad account.

The Internet of things (IoT) describes the network of physical objects—“things”—that are
embedded with sensors, software, and other technologies for the purpose of connecting and
exchanging data with other devices and systems over the Internet.
The definition of the Internet of things has evolved due to the convergence of multiple
technologies, real-time analytics, machine learning, commodity sensors, and embedded
systems.[1] Traditional fields of embedded systems, wireless sensor networks, control
systems, automation (including home and building automation), and others all contribute to
enabling the Internet of things. In the consumer market, IoT technology is most synonymous with
products pertaining to the concept of the "smart home", including devices and appliances (such as
lighting fixtures, thermostats, home security systems and cameras, and other home appliances) that
support one or more common ecosystems, and can be controlled via devices associated with that
ecosystem, such as smartphones and smart speakers.
Result: Cisco Packet Tracer ,IoT, configuring various network deviceshas been studied
successfully.
 Experiment: - 10
Aim:- To deploy a home automation application and perform remote monitoring and control of
homeappliances
Software Required: Cisco Packet Tracer, Windows OS

Theory:
The Internet of Things (IoT) is a system of interrelated computing devices, mechanical and digital
machines, objects, animals or people that are provided with unique identifiers (UIDs) and the
ability to transfer data over a network without requiring human-to-human or human-to- computer
interaction.
This process contains three parts:
Part 1: Add Home Gateway to the Network
Part 2: Connect IoT Devices to the Wireless Network Part 3: Add End User Device to the
Network

Part 1: Connect a Home Gateway to the Network

Ste p 1: Adding a home gateway
a) Select the Home Gateway device. Click the Wireless Devices icon in the Device-Type Selection
box. Click the Home Gateway device icon and then click in the Logical workspace to add
thedevice.
b) Connect the Home Gateway to the Cable Modem. Click the Copper Straight-Through connector
icon in the Device-Type Selection box, and then click the Home Gateway to add one end of the
cable to the gateway. Next, click the Cable Modem icon to connect the other end of the cable to the
Internetport.
Part 2: Connect IoT Devices to the Wireless Network
Step 1: Select wireless devices
a) Click the Home Devices icon in the Device-Type Selection box and add the Fan, the Door, and the
Lamp to the workspace.
Step 2: Add devices to the home wireless network.
a) Add a wireless adapter to the Fan device. Click the Fan icon in the workspace to open the Config
tab and then click the advanced button in the bottom right corner of the window. Notice that the
tabs at the top of the configuration window change. There are now more tabs. Click the I/O Config
tab and change the Network Adapter type to the PT-IOT-NM-1Wwirelessadapter.
b) Change the display name of the Fan device. Click the Config tab. In the Display Name box, type
CeilingFan.
c) Verify that the Fan device is connected to the wireless network. While still in the Config tab, click
the Wireless0interface in the left pane. In the configuration settings, the Home Gateway network
should be listed in the SSID box. Verify that the DHCP is selected in the IP Configuration settings,
the IP address is 192.168.25.100 and the default gateway is 192.168.25.1. This indicates that the
fan is connected to the network and is receiving IP configuration information from the home
gateway.Close the Ceiling Fan configurationwindow.
d) Connect the Door and the Lamp to the wireless network following the same steps used for thefan
Part 3: Add a Wireless Tablet to the Network
Step1: Add the wireless tablet to the workspace
a) Click the End Devices icon in the Device-Type Selection box and add the Wireless Tablet to
theworkspace.
Step 2: Connect the wireless tablet to the Home Gateway network
a) Change the wireless tablet network settings. Click the Tablet icon to open the Tablet configuration
window. Click the Config tab and then click the Wireless0Interface. Change the SSID from Default
to Home Gateway. After the network SSID is changed the Tablet should learn an IP address
through DHCP within a fewseconds.
b) Access the home gateway IoT server from the tablet. Click the Desktop tab and then click the
Web Browser icon to open a Web browser. Type 192.168.25.1(the address of the home gateway) in
the URL box and click Go. At the Home Gateway Login page, enter admin as the username and
admin as the password and click the Submit button to connect to the Home Gateway server. Note
that no devices appear in the Home Gateway IoT Server -Devices list.
Ste p 3: Configure IoT devices to register with the Home Gateway server
a) Register the ceiling fan to the home gateway server. Click the Fan icon in the workspace, click the
Config tab, and then click Settings in the left pane. At the IoT Server options list, click the Home
Gatewaybutton.
b) Verify that the devices are now registered with the Home Gateway server.Click the Tablet icon in
the workspace and open the Web Browser. Connect to the Home Gateway
bytyping192.168.25.1intheURLboxandthenclickgo.Enteradminastheusername
and password and click Submit. After a few seconds all three devices should be
listed in the Home Gateway IoT Server –Devices list.
Close the Tablet window

Result:-Network configured successfully implemented.