Implementation Of ZIGBEE in Home Automation using
Wireless Sensors
Final Year Project Report
Presented
By
Ghulam Murtaza
CIIT/SP10-BCE-010/ISB
Muhammad Waqas Saeed
CIIT/SP10-BCE-026/ISB
Zahid Ali Khan
CIIT/SP10-BCE-010/ISB
In Partial Fulfillment
of the Requirement for the Degree of
Bachelor of Engineering in Electrical (Computer) Engineering
DEPARTMENT OF ELECTRICAL ENGINEERING
COMSATS INSTITUTE OF INFORMATION TECHNOLOGY,
ISLAMABAD
Feb 2011

HOME AUTOMATION
Wireless sensor networks:
1.1 Introduction:
Wireless sensor networks (WSN) is an important and exciting new technology
with great potential for improving many current applications in medicine, transportation,
agriculture, industrial process control, and the military as well as creating new
revolutionary systems in areas such as global-scale environmental monitoring, precision
agriculture, home and assisted living medical care, smart buildings and cities, and
numerous future military applications.
A WSN referred to as wireless sensor network is a wireless network subsisting of
distributed autonomous devices which use sensors to monitor environmental and physical
conditions. A WSN system integrate a gateway that provides wireless connectivity back
to the wired world and distributed nodes (i.e. Figure 1). Some of the available protocol
standards include 2.4 GHz radios based on either IEEE 802.11(Wi-Fi) or IEEE 802.15.4
standards or proprietary radios, which are usually 900MHz. Although it depends on you
which standard do you select.
Figure 1. WSN Components, Gateway, and Distributed Nodes

We are living in a time where next step in the evolutionary development in home,
buildings, industrial, utilities, shipping, and transportation system is the integration of
smart environments. Like any a perceptive being, the smart environment relies mainly on
sensory data from the real world. And for that purpose this environment needs data from
within itself and from surroundings. The information that a smart environment needs is
provided by wireless sensor networks.
The figure elaborates the complexity of wireless sensor networks(WSN), which
generally includes data acquisition network that is kept in check by a center of
management. All this profusion of the technologies that are available, the selection of
components more difficult, let alone the design of reliable, consistent, robust overall
system. The study of entire wireless sensor networks is challenging as it requires an
enormous amount of knowledge from wide variety of versatile disciplines.
Fig 2. Wireless Sensor Networks

1.2 Mote and Wireless SensorNetworks:
A mote is a very low cost computer that consumes very less power. It may be
used to monitor one or more sensors. It is a radio link to the outside world and the
MOTEs are building blocks of a wireless sensor networks (WSN).
Whereas, wireless sensor networks are combination of multiple motes that can be
hundreds or thousands of motes that communicate with each other and pass data along
from one to another.
1.3 Challenges for wireless sensor networks:
Many challenging research problems must be addressed to produce a realistic
WSN application. This section discusses a number of the critical challenges, specifically
entitled: from raw data to knowledge, robust system operation, openness and
heterogeneity, security, privacy, real-time, and control (actuation). All of these challenges
must deal with noisy, uncertain and evolving environments. Each of the following three
applications addresses a subset of these challenges appropriate to their purpose.
1.3.1 From Raw Data to Knowledge
Several Wireless Sensor Networks may produce vast amounts of raw data. It is
necessary to develop techniques that convert this raw data into usable knowledge in an
energy efficient manner. For example, in the medical area, raw streams of sensor values
must be converted into semantically meaningful activities performed by or about a person
such as eating, poor respiration, or exhibiting signs of depression. Main challenges for
data interpretation and the formation of knowledge include addressing noisy, physical
world data and developing new inference techniques. In addition, the overall system
solution must deal with the fact that no inference method is 100% correct. Consequently,
uncertainty in interpreted data can easily cause users not to trust the system. For example,
in making decisions it is necessary to minimize the number of false negatives and false
positives and guarantee safety, otherwise the system will be dismissed as unreliable.
Location (the sensor node or base station) of the data processing is another critical issue:

processing at the sensor node consumes energy and is limited by the device capacity, but
it saves transmission energy and network contention. The correct tradeoffs on processing
location seem system dependent.
1.3.2 Robust System Operation
Many applications in wireless sensor networks typically initialize themselves by
self-organizing after deployment. At the conclusion of the self-organizing stage it is
common for the nodes of the WSN to know their locations, have synchronized clocks,
know their neighbors, and have a coherent set of parameter settings such as consistent
sleep/wake-up schedules, appropriate power levels for communication, and pair-wise
security keys. However, over time these conditions can deteriorate. The most common
(and simple) example of this deterioration problem is with clock synchronization. Over
time, clock drift causes nodes to have different enough times to result in application
failures. While it is widely recognized that clock synchronization must re-occur, this
principle is much more general. For example, even in static WSN some nodes may be
physically moved unexpectedly. More and more nodes may become out of place over
time. To make system-wide node locations coherent again, node re-localization needs to
occur (albeit at a much slower rate than for clock sync).
These types of required coherence services must combine with many other
approaches to produce robust system operation. This includes formal methods to develop
reliable code, in-situ debugging techniques, on-line fault tolerance, in-field-maintenance ,
and general health monitoring services. These problems are exacerbated due to the
unattended operation of the system, the need for a long lifetime, the openness of the
systems, and the realities of the physical world. The goal is for this collection of solutions
to create a robust system in spite of noisy, faulty and non-deterministic underlying
physical world realities.
1.3.3 Openness and Heterogeneity
Traditionally, the majority of sensor based systems have been closed systems. For
example, cars, airplanes, and ships have had networked sensor systems that operate

largely within that vehicle. However, these systems and other WSN systems are
expanding rapidly. Cars are automatically transmitting maintenance information and
airplanes are sending real-time jet engine information to manufacturers. WSN will enable
an even greater cooperation and 2-way control on a wide scale: cars (and aircraft) talking
to each other and controlling each other to avoid collisions, humans exchanging data
automatically when they meet and this possibly affecting their next actions, and
physiological data uploaded to doctors in real-time with real-time feedback from the
doctor. WSN require openness to achieve these benefits. However, supporting openness
creates many new research problems including dealing with heterogeneity. All of our
current composition techniques, analysis techniques, and tools need to be re-thought and
developed to account for this openness and heterogeneity. New unified communication
interfaces will be required to enable efficient information exchange across diverse
systems and nodes. Of course, openness also causes difficulty with security and privacy,
the topics of the next two subsections. Consequently, openness must provide a correct
balance between access to functionality and security and privacy.
1.3.4 Security
A fundamental problem that must be solved in WSN is dealing with security
attacks. Security attacks are problematic for WSN because of the minimal capacity
devices being used in parts of the systems, the physical accessibility to sensor and
actuator devices, and the openness of the systems including the fact that most devices
will communicate wirelessly. The security problem is further exacerbated because
transient and permanent random failures are commonplace in WSN and failures are
vulnerabilities that can be exploited by attackers. However, the considerable redundancy
in WSN creates great potential for designing them to continue to provide their specified
services even in the face of failures. To meet realistic system requirements that derive
from long lived and unattended operation, WSN must be able to continue to operate
satisfactorily in the presence of, and to recover effectively from security attacks. The
system must also be able to adapt to new attacks unanticipated when the system was first
deployed.

1.3.5 Privacy
The ubiquity and interactions of WSN provide many conveniences and useful
services for individuals, but also create many opportunities to violate privacy. To solve
the privacy problem created by single and interacting WSN of the future, the privacy
policies for each (system) domain must be specified. Once specified the WSN system
must enforce privacy. Consequently, the system must be able to express users’ requests
for data access and the system’s policies such that the requests can be evaluated against
the policies in order to decide if they should be granted or denied. One of the more
difficult privacy problems is that systems may interact with other systems, each having
their own privacy policies. Consequently, inconsistencies may arise across systems. Once
again, on-line consistency checking and notification and resolution schemes are required.
1.3.6 Real-Time
Classical real-time analyses assume a rigorously defined and highly deterministic
underlying system model, a set of tasks with known properties, a system that operates in
a well controlled environment, and they abstract away from properties of the physical
world. For WSN systems, none of these assumptions are true and stream models rather
than tasks models are prevalent. Further, WSN often support many real-time sensor
streams in noisy, uncertain, and open environments. In particular, a very difficult issue is
that wireless communication packet delivery is subject to burst losses. New concepts of
guarantees must be developed that will likely span a spectrum from deterministic to
probabilistic depending on the application, the environment, and noise and interference
models.
1.3.7 Control and Actuation
Many WSN utilize feedback control theory when actuation is involved. The
classical methodology includes creating a model of the system and then deriving a
controller using well known techniques to meet stability, overshoot, settling time, and
accuracy requirements. A sensitivity analysis is also performed. However, openness and
scale create many difficulties for this methodology. Openness means that the model of

the system is constantly changing. Human interaction is an integral aspect of openness
and this makes modeling extremely difficult. In addition, scaling and interactions across
systems also dynamically change the models and create a need for decentralized control.
While some work has been performed in topics such as stochastic control, robust control,
distributed control, and adaptive control, these areas are not developed well enough to
support the degree of openness and dynamics expected in WSN. A new and richer set of
techniques and theory is required. It is especially important to understand how large
numbers of control loops might interact with each other. To date there have already been
examples of WSN where control loops have competed with each other, one indicating an
increase in a control variable while the other loop indicating a decrease in the same
variable at the same time. Such dependencies must be addressed in real-time and in an
adaptive manner to support the expected openness of WSN.
Briefly, we can enumerate the challenges for configuring and implementing a wireless
sensor network in a system as:
1. Energy Efficiency
2. Responsiveness
3. Robustness
4. Scalability
5. Systematic design
6. Self-Configuration and adaptation
7. Heterogeneity
8. Privacy and security
1.4 Deployment Issues
1. Structured versus Randomized Deployment
2. Over deployed versus Incremental Deployment
3. Connectivity and Coverage Metrics of Interest

2. Applications Of Wireless Sensor Networks:
Applications of Wireless sensors networks depends on the interest towards the
most diverse fields like warfare, Surveillance, Environmental monitoring, Child
Education, agriculture and micro-surgery are only few of the examples.
Briefly we can divide the applications of wireless sensor networks into following
categories :
2.1 Environmental/Habitat Monitoring:
In this section, we are going to discuss the major sensor network applications, the
unique challenges they posed in front of us and the lessons we learned from them. All
these applications share a common theme that is: understanding the natural and
agricultural environments in response to major challenges. This application includes the
water-quality monitoring, microclimate monitoring for rain forests and forms, and cattle
monitoring and control.
Each application posed different challenges which includes energy, actuation,
mobility and intermittent connectivity. Our design choices and technologies were
response to these challenges and have eventually evolved over time but the rate of
change/evolving is slowing and at present we are at a stage where the core technology is
configurable and reliable enough that it has been unaided, deployed, by domain scientists.
2.1.1 Cattle Monitoring
We developed a network at a research farm over 500 km from our laboratory. The project
has had several phases and technology generations, and it has been the primary driver of
our technology development. The first phase involved recording the positions of cattle
over time, and also soil moisture at various points in a paddock. Soil moisture is an
important indicator of how quickly pasture will grow and therefore important for
planning stocking rates (number of animals per unit area).

2.1.1.1 Challenges:
Information from static and mobile nodes was to be relayed to a base station and
then over the internet to a remote server. We later added nodes with cameras that
periodically transmitted images of key locations such as water troughs. This was our first
deployment that included both mobile and static nodes and this raised new challenges for
routing and network topology maintenance.
2.1.1.2 Technology:
From our early experiments with Mote hardware we saw the need to develop a
device with improved radio range, solar power capability (for a country where solar
insolation is of the order of 20 MJ/𝑚2
/day), mechanical and electrical robustness, and
ease of interfacing to transducers. This became the Fleck series of nodes.
The Fleck-1 used the Atmega 128 processor, with 128 KB of program flash
memory, 4 KB of RAM, and a stream-based Nordic nRF903 radio transceiver at 433
MHz which provided a 72-kb/s channel and a range of 500 m using a quarter-wave
antenna. The board was 60×60𝑚𝑚2
in size and includes power supply, solar charging
circuit, and sensing for on-board temperature, battery voltage, and charging current.
In retrospect the most inspired part of the system design was the simplest. A
screw terminal block on the Fleck made it very easy to install. Battery, solar cell, serial,
and analog and digital transducers could be connected using just a screwdriver no
expansion board was required. However, for more complex interfacing, a simple
microprocessor pinout expansion bus was provided and an expansion board for the soil
moisture transducers was developed.
The nodes carried by the animals were the Fleck-2 which was specialized for
animal tracking applications. It has the functionality of the Fleck-1 with additional
onboard global positioning system (GPS), three-axis magnetometer (electronic compass),
three-axis accelerometer, and a multimedia card (MMC) socket for local bulk data

storage as a safeguard against intermittent network connection or the case where data rate
exceeds network capacity. The Fleck-2 nodes were built into collars that were worn by
the cattle [Fig. 3 (left)].
For image processing the Atmega processor lacks memory and computational
power. Unlike the Cyclops, we chose to implement the camera as an expansion board
with a Texas Instruments 32-b 150-MHz digital signal processor (DSP) with 1 MB of
SRAM connected to a 640x480 color image sensor. The DSP performs image capture,
buffering, and processing and sends the image in small blocks over the serial peripheral
interface (SPI) bus to the Fleck for transmission over the radio network.
Fig 3. Sensor nodes in the farm deployment: (deployment) cowcollars,(right) second
generation environment housing with solar cell on top.
We had significant problems with the environmental housings, a prosaic but
critical part of a sensor network system. Our first generation housings were standard gray
plastic electrical boxes and the quarter-wave 433-MHz antennas were externally
mounted. Box penetrations for transducers, solar power, and radio frequency (RF) were
potential sources of water and insect ingress, but the bigger problem was the time taken
to assemble each unit which was nearly half a day. The bigger form factor of the Fleck-2,
60×120𝑚𝑚2
was problematic for mounting in the animal collars and there was, in

retrospect, no clear advantage in cost or reliability of the single board solution. In fact the
small number that was manufactured led to higher unit costs.
2.2 Ground Water Quality Monitoring
Deployment C was a relatively small network, nine nodes, located 2000 km from
our lab. Its purpose was to monitor the salinity, water table level, and water extraction
rate at a number of bores within the Burdekin irrigated sugar cane growing district. This
is a coastal region and over extraction of water leads to saltwater intrusion into the
aquifer. The area we monitored was approximately 2×3𝑘𝑚2
.
2.2.1 Challenges:
The WSN had to operate unattended, and compared to previous sensor net
deployments the network was very sparse with very long wireless transmission ranges
(with average link length over 800 m). One simplification was that many nodes could be
mains powered (since they were collocated with pumps).
2.2.2 Technology:
The Fleck-3 series used a Nordic nRF905 radio which had a more sensitive
receiver giving longer radio range. It has an inbuilt proprietary media access control
(MAC) that supports packets up to 32 B and required only an SPI-bus connection to the
processor. Like its predecessor, this transceiver did not provide received signal strength
indication (RSSI) or link quality (LQ) information. It also used a different modulation
scheme making it incompatible with the Fleck-1 and -2 radio, and we also made the
decision to move from 433 to 915 MHz primarily for the smaller antenna size (which
could then be placed inside the enclosure). This was the period when the rest of the WSN
community was moving en masse to 2.4 GHz. The node also included an improved solar
charger that allowed the solar cells to be disconnected from the battery, under software
control, to prevent over charging. Developments in microelectronics also allowed the
board to be slightly smaller, 50×60 𝑚𝑚2
.

We used the TinyOS operating system and implemented the MintRout𝑒3
network
protocol which uses a shortest-path-first algorithm to route packets to the base station on
the basis of a definable routing metric. We chose bidirectional Expected number of
Transmissions (ETX) as our routing metric which works well with the radio chip we
selected. We also use hop-to-hop retransmission to increase end-to-end delivery rates.
2.2.3 Lessons Learned:
The technology was transitional: our last system to use Tiny𝑂𝑆3
and the Surge
protocol and our first to use the new Fleck-3 node. We deployed no other network using
this technology combination. The importance of protocols became very clear, and this
system was able to achieve more than 95% end-to-end delivery rates in deployment when
the individual LQ was higher than 15%. We conducted a radio survey to determine
achievable communications distances in the environment, but we did this when the fields
were bare. We neglected to account for the sugar cane which is up to 4.5 m tall when
fully grown and interferes with line-of-sight wireless communication.
Fig 4. Evolution of CSIRO WSN mote platforms.(a) Mica Mote. (b) Fleck 1c. (c)
Fleck 2. (d) Fleck 3.(e) Fleck 3b stack
The network was deployed in 2006 and operated for 1.5 years, delivered more than 1
million water quality readings, and required only two maintenance visits. One visit was to
repair a number of nodes damaged in a violent electrical storm.

2.3 Virtual Fencing
A new group of large-scale and remotely operated deployments was looming that
included cattle control. The lessons learned so far stressed the need for better
foundational technology. This led us to develop our own operating system and a new
node with a better radio but which was incompatible with the Fleck-1 and Fleck-2.
Deployment D, at our laboratory, was a tested to shakedown this “new technology”.
We also developed a molded plastic case that was quick to assemble and had the
antenna inside the enclosure [Fig. 3(right)]. The new unit could be assembled in just 15
min.
2.3.1 Challenges:
Key requirements included the ability for access to status and control of remote
nodes, and this was particularly important to meet the ethics requirements for the virtual
fencing experiments.
2.3.2 Technology:
The new Fleck-3 was incompatible with the Fleck-2 nodes used in the cow collars.
Rather than redesign a Fleck-3 variant for animal tracking, we chose this time to exploit
the expansion bus on the Fleck. Expansion boards are stackable [Fig. 4(e)] and the whole
assembly could be bolted together PC-104 style leading to systems that were extremely
robust mechanically and electrically. The Fleck-2 functionality now fitted on two
50×50𝑚𝑚2
expansion board: inertial sensing (accelerometers, gyroscopes, and compass),
and GPS/MMC combination. The growing complexity of our deployments led us to
develop our own operating system. A sensor network operating system must abstract
underlying hardware, facilitate resources sharing, and be power conscious and sleep
whenever possible. TinyOS was the first open source operating system for sensor nodes
and is event based. However, we and others have found that event driven code is difficult
to write, understand, maintain, and debug. It does not scale well with program size,
leading to difficulty in developing and maintaining large applications. It requires that

logically blocking sequences be written in a state-machine style. The result is that the
control flow for a single conceptual task and its state are split across several language
procedures, effectively discarding language scoping features.
Our Fleck operating system (FOS) sits at the “sweet Spot” identified by Adya. FOS
provides a priority based no preemptive (cooperative) threading environment. This
simple concurrency model means that semaphores are not required. The scheduler is
responsible for CPU power management and enters the lowest mode consistent with
thread resource requirements. Other approaches to threads on sensor nodes include
preemptive threading and protothreads. Interestingly TinyOS itself eventually supported
the threading model and justified it in terms of ease of use and significantly greater
expressivity compared to the event-based model.
FOS provides uniform access to underlying resources via a POSIX-like application
programmer interface (API) with blocking read and write primitives. FOS supports the
many transducer interface boards we have developed. Time critical operations such as
analog data sampling or high speed timers are handled by interrupt-level callbacks. A
virtualized timer based on an event-time queue is provided for non-time-critical delays.
The kernel is a relatively small piece of software, around 12 000 lines of C code.
The most well-known and cited disadvantages of threads are that each thread must
reserve its own stack space that cannot be shared and, because it is difficult to know in
advance how much stack space a thread needs, the stack is typically overprovisioned. We
addressed these concerns in several ways. We developed a static analyzer for estimating
required stack sizes for each thread which eliminates wastage. We use an interrupt stack
so that we do not have to allocate space for interrupt handlers on every thread stack.
Finally, the kernel checks sentinel bytes in the stack on each system call and invokes a
panic if a stack overflow has occurred. In practice, the memory required for thread stacks
has not proved to be a limitation, and applications with ten or more threads are routinely
created.
Other support tools include a wireless boot loader that uses our remote procedure call
(RPC) protocol for command and status, and a negative-acknowledgment based protocol

for efficient reloading of multiple nodes simultaneously over the radio. Software failures
return control to the boot loader allowing remote intervention or restart. A postmortem
memory dump analyzer provides complete state and symbolic debugging information
from memory images uploaded from nodes that have failed in the field.
FOS needed a routing protocol and we chose diffusion routing to meet the mobility
requirements. In diffusion a node (source) periodically broadcasts/advertises interests.
Other nodes (destination) can subscribe to the interests and the sensed data will be routed
from source to the destination via the reverse path.
As an alternative to programming the node we can consider that the node exports a
predefined set of services which a client program can access. The services are accessed
using RPCs. Other RPC systems have been proposed for sensor networks but our system
is now the mainstay of many long-lived deployments and has proven invaluable for
diagnostics and network re-tasking.
The exported services are code segments, called actions, which closely resemble C-
language functions. An RPC generator takes a set of actions and creates two sets of
output files: the server-side C-code to be included on the node, and the client-side Python
class. Our tiny RPC system uses a state less protocol, and the RPC server runs as a
separate thread on the node. Every node includes a set of standard services including
reading or writing RAM or electrically erasable programmable read only memory
(EEPROM), reading transducers or battery condition, and rebooting.
An application, which is a WSN client written in Python, invokes a method call on an
RPC object which causes the arguments to be marshaled, and sent via a gateway node to
the WSN. There the action is executed and the return values marshaled and returned to
the application. In the case that the function call is broadcast rather than unicast the
method call returns a list of return values. Thus, a client program running on a host
computer can seamlessly access services on one or more sensor nodes.
Using this facility, we have developed the network equivalent of a “symbolic
debugger,” a keyboard-interactive tool which allows node state to be examined or altered.

If the node application’s symbol table is available we can address remote node memory
symbolically. Our experience validates the experience of others, for example, regarding
the importance and utility of remote monitoring and control mechanisms.
As the number and complexity of deployments grew we had a problem with the
number of different message formats. This deployment (E), for example, was highly
heterogeneous with many different kinds of transducers such as soil moisture, battery
voltage, and GPS position, as well as virtual sensors such as node and network
performance metrics. We refactored several applications and created a general message
format called tagged data format (TDF).
TDF is a self-describing schema for any data transmitted within the network,
including RPC call and return frames. When a node sends data, it is packed into the
payload of a message and tagged, prepended by a unique byte value, to identify the type
of data and implicitly its length in bytes. This enables the creation of generic “backend”
tools that can parse the message payloads without knowledge of the application that
created them.
2.3.3 Actuation:
“Virtual fencing” (VF) not only requires sensing of position and velocity information,
but also actuation which in this case is the application of audio and mild-electrical stimuli
to the animals. While applying stimuli is technically trivial, an independent ethics
oversight committee required that it be applied ethically. With a nonzero probability that
software bugs could breach the ethics commitment, we designed our stimulation
hardware with a dedicated low-level controller that enforced our ethics constraints.
Additionally, we designed the application to deactivate the VF logic should a
communications link back to the base be lost. This meant that we could monitor the
animals in real-time, deactivate collars if necessary via RPC, and know that when we
could not contact the collars, that no stimuli was being applied. As the confidence in the
logic matured, the need for a continuous communications link was relaxed, however the
embedded ethics-enforcing logic on the hardware has remained. We have successfully

demonstrated significant reduction of grazing on exclusion zones designated using our
“VF” algorithm on hundreds of cattle not previously exposed to the technology.
2.3.4 In-Network Processing:
The cattle monitoring work also gave us the opportunity to investigate some
challenges around in-network processing of high sample-rate GPS data. The cattle nodes
have a fixed-sized memory buffer to which position data are added at a constant rate, and
from which data are downloaded at a non-constant rate when they come into contact with
static sensor nodes. We have developed a novel algorithm that performs online
summarization of position data within the buffer, where the algorithm naturally
accommodates data input and output rate mismatch, and also provides a delay-tolerant
approach to data transport. The algorithm has been extensively tested in a large-scale
long-duration cattle monitoring and control application.
Data summarization and aggregation has been a growing area of focus within the
sensor networks community. For many applications, the “sample-and-send” paradigm is
not the right one, especially in applications which require periods of streaming high-
fidelity data and periods where no data are required. Growth in solid-state memory
capacity and shrinking costs mean that availability of local storage space is increasingly
not a challenge. The key research opportunities here revolve around the most effective
ways to compress data which allow for efficient search and communication of the most
valuable information contained within.
2.3.5 Lessons Learned:
The decision to change both hardware and software was correct in retrospect, even if
it was painful at the time. From a hardware perspective, the pain was in obsoleting all the
nodes we had previously built at a significant cost, and this was difficult to “sell” to our
partners. Writing code on a developing operating system was difficult for all concerned,
but we did achieve the goal of a programming environment that was more convenient for
applications developers. FOS was rapidly adopted and led to a huge jump in productivity.
we found that students and visitors were up and running in hours. We routinely created

complex applications with ten or more threads. This is counter to the choices made by
other groups and advocated in the literature. In our experience, memory limits turned out
not to be an issue, and in retrospect the tradeoff made in early WSN research where
memory was saved at the expense of increased program complexity was perhaps not the
right one.
Increased productivity and several parallel projects meant that message formats got
out of control, they were not defined by FOS, and each project defined its own message
format for data and for commands. This reached crisis point and was refactored into the
self-describing data format TDF and a tiny remote procedure call system. These tools
were quickly adopted by the team and led to another lift in productivity and in our
ambition. we could contemplate building much more complex systems because the
foundations and the debugging tools were strong.
The downside of adopting custom hardware, a radio with no LQI or RSSI and a small
packet size, and custom software was that we cut ourselves off from the mainstream of
sensor network development. We made do with “good enough” networking algorithms
and devoted our effort to system integration. One interpretation of this is that the gains
from protocol development are diminishing, and that systems issues now dominate. In
fact our code base has a kernel with 12 000 lines of code (LOC) and the Python support
tools and utilities have 23 000 (LOC).
2.4 Rainforest Monitoring
Deployment F was part of a major initiative to provide reliable, long-term monitoring
of rainforest ecosystems. Our target was a rainforest area in South-East Queensland
(Springbrook, Australia) which had a high priority for monitoring the restoration of
biodiversity. The first phase of the project was to develop a better understanding of the
challenges in deploying long-term, low-power WSNs in rainforest environments the
engineering testbed.
These environments are typically characterized by areas with very limited solar
energy with adverse and dynamic radio environments. In order to develop the network

and energy management protocols required for robust and reliable performance of long-
term, rainforest networks, we had to first quantify the performance of current WSN
technology under these conditions.
2.4.1 Challenges:
A well-recognized constraint on sensor networks, identified in the earliest research,
has been energy resources. Sensor nodes are expected to be deployed in environments
away from the energy grid and must either hold sufficient energy resources to last the
required lifetime, or have their energy store replaced manually or replenished
continuously with energy harvested from the surrounding environment. Sensor networks
nodes comprise a number of core components such as a microcontroller, radio, flash
memory, transducers, and other peripherals. Each of these components can be in one of a
number of states each of which has different power consumption. Fig. 5 illustrates the
energy consumption rates of a node as a function of the states of its core components.
Based on these data and given a typical radio duty cycle of 5%, and transducer
sampling/sending rate of around 5 min, we can estimate that node’s average current
consumption is around 2 mA.
2.4.2 Technology:
Our current approach to managing battery storage is to combine both rechargeable
and non-rechargeable batteries in each device. In the default mode of operation, all
energy for the device will come from three rechargeable 1.2-V 2700-mAh NiMH
batteries working in combination with monocrystalline solar panels capable of supplying
up to 300 mA of current. In the event no further energy is harvested for long periods, the
system will switch to the non-rechargeable (Alkaline) energy supply when the
rechargeable battery voltage falls below a threshold, and switches back whenever this
voltage rises again.
Fig. 6 shows the results of an experiment over two weeks with nodes deployed in
open and covered areas. All nodes are deployed in the open with the exception of nodes
“20,” “Log-runner,” and “19,” which are placed in forested areas. Whereas nodes in the

open typically harvest over 10 kJ/day, the covered rainforest nodes harvest as little as 100
J on average sonly 1% of the energy of nodes in the open. A node drawing an average of
2 mA requires 600 J/day so sustainable operation would require an average current
consumption of less than 0.33 mA.
The engineering testbed deployment showed that the links were highly dynamic and
asymmetric. To meet high end-to-end delivery requirements we implemented a LQ-based
routing protocol for FOS which became the protocol used across all future deployments,
and was retrofitted to deployment E. LQ is similar to the collection tree protocol (CTP) in
TinyOS and uses ETX as routing metrics and takes bidirectional LQ into account.
However, hardware LQ indicators, such as RSSI and LQI, are not available from the
Fleck-3’s transceiver. Instead packet reception rates (PRRs) are estimated by snooping
neighbor traffic. Snooping a packet from a neighbor has the same energy cost as
receiving a packet but is better than the alternative of using node goodput to estimate
PRRs. The estimation of LQ to sibling and child nodes based only on replies to
infrequent beacon messages will not be as fresh as the estimate obtained by snooping
neighbor traffic. For a difficult rainforest communication environment, we trade off
energy for the robustness of communications. As a result, LQ achieved more than 99%
end-to-end delivery rates when the network was connected.
Fig 5. (a)breakdown oftotal current consumption by CPU and radio (100% duty cycle)
for different states. (b) Breakdown oftransducer energy consumption per sample. (a) CPU
and radio. (b) Sensors.

To help meet the power budget, we implemented a low-power MAC protocol based
on low-power listening (LPL). In LPL, nodes wake up periodically (every 57 ms) for a
short period (3 ms) to check for communication activities and attempt to receive
messages. Consequently, a source node needs to transmit a long “preamble” to wake up
destination node before transmitting a message and this incurs a slightly higher cost for
the sending node. Because traffic is typically low in a habitat monitoring sensor network,
messages are sent every 5 min; nodes using LPL can sleep most of the time and conserve
energy.
Fig 6.Average Daily energy harvested by each node
The nodes used the now standard Fleck-3 boards and environmental housings as
shown in Figs.7 and 8. A custom expansion board was built to interface to the many
transducers: wind speed and direction, soil moisture, leaf wetness, temperature, and
relative humidity.
We also started the next generation of video and audio interface. The system
developed for deployment B used a DSP that had a poor software development
environment. We redesigned this to use an Analog Devices Black Fin processor and we
experimented with both uCLinux and the Visual DSP++ environment before settling on
the latter as our development environment of choice. The new interface has a mega-pixel
color image sensor, two audio channels and interfaces to passive infra red (PIR)
transducers for triggering. The applications include event-based and periodic image

capture or sound recording. Some initial work into classification of vocalizing species has
been undertaken.
Fig 7. Inside the second generation environment housing showing the seals.
Fig 8. A microclimate node deployed in the Springbrook rainforest.

2.4.3 Lessons Learned:
We learned that radio propagation through dense and wet forest is poor, and that the
decision to move from 433 to 900 MHz may not have been the right one. The LQ
protocol did work very well despite the limitations of the radio transceiver. Results from
experiments showed that throughput for nodes in open area ranged from>99% for one-
hop nodes down to 80% for nodes up to four hops from the sink. In the case of forest
nodes, throughput ranged from 95% to less than 20% in the worst case periods. In
particular, we found that many links of forest nodes would completely breakdown during
and after heavy rain events.
This was also the deployment where we learned that available solar power is not
always enough to power a node especially when a large suite of transducers must be
powered. This does however raise an important question about an unwritten assumption
for WSNs that nodes are deployed and never revisited. In practice, our rainforest nodes
are visited every few months to remove leaves, sticks, and insect nests from the
transducers. It would therefore be quite feasible to replace the battery on each visit,
eliminating the complexity associated with energy management discussed above.
Other than those above mentioned applications WSNs have wide range of
applications which cannot be covered in this short document even after a lot of hard
work and time. Below are Some Sample Applications enumerated:
1. Industrial and Commercial Uses
2. Inventory Tracking–RFID
3. Automated Machinery Monitoring
4. Smart Home or Smart Office
5. Energy Conservation
6. Automated Lighting
7. Military Surveillance and Troop Support
8. Chemical or Biological Weapons Detection
9. Enemy Troop Tracking
10. Traffic Management and Monitoring

But the application we have worked on, we are going to discuss in upcoming
subsections that is Home Automation or Smart Home/Office application of the wireless
sensor networks.
3. Home Automation-An Introduction
Home automation refers to the use of computer and information technology to
control home appliances and features (such as windows or lighting). Systems can range
from simple remote control of lighting through to complex computer/micro-controller
based networks with varying degrees of intelligence and automation. Home automation is
adopted for reasons of ease, security and energy efficiency.
In modern construction in industrialized nations, most homes have been wired for
electrical power, telephones, TV outlets (cable or antenna), and a doorbell. Many
household tasks were automated by the development of specialized appliances. For
instance, automatic washing machines were developed to reduce the manual labor of
cleaning clothes, and water heaters reduced the labor necessary for bathing.
Other traditional household tasks, like food preservation and preparation have
been automated in large extent by moving them into factory settings, with the
development of pre-made, pre-packaged foods, and in some countries, such as the United
States, increased reliance on commercial food preparation services, such as fast food
restaurants. Volume production and the factory setting allows forms of automation that
would be impractical or too costly in a home setting. Standardized foods enable possible
further automation of handling the food within the home.
The use of gaseous or liquid fuels, and later the use of electricity enabled
increased automation in heating, reducing the labor necessary to manually refuel heaters
and stoves. Development of thermostats allowed more automated control of heating, and
later cooling.
As the number of controllable devices in the home rises, interconnection and
communication becomes a useful and desirable feature. For example, a furnace can send

an alert message when it needs cleaning, or a refrigerator when it needs service. Rooms
will become "intelligent" and will send signals to the controller when someone enters. If
no one is supposed to be home and the alarm system is set, the system could call the
owner, or the neighbors, or an emergency number.
In simple installations, domotics may be as straightforward as turning on the
lights when a person enters the room. In advanced installations, rooms can sense not only
the presence of a person inside but know who that person is and perhaps set appropriate
lighting, temperature, music levels or television channels, taking into account the day of
the week, the time of day, and other factors.
Other automated tasks may include setting the HVAC to an energy saving setting
when the house is unoccupied, and restoring the normal setting when an occupant is
about to return. More sophisticated systems can maintain an inventory of products,
recording their usage through bar codes, or an RFID tag, and prepare a shopping list or
even automatically order replacements.
Home automation can also provide a remote interface to home appliances or the
automation system itself, via telephone line, wireless transmission or the internet, to
provide control and monitoring via a smartphone or web browser.
An example of remote monitoring in home automation could be triggered when a
smoke detector detects a fire or smoke condition, causing all lights in the house to blink
to alert any occupants of the house to the possible emergency. If the house is equipped
with a home theater, a home automation system can shut down all audio and video
components to avoid distractions, or make an audible announcement. The system could
also call the home owner on their mobile phone to alert them, or call the fire department
or alarm monitoring company.
In terms of lighting control, it is possible to save energy when installing various
products. Simple functions such as motion sensors and detectors integrated into a
relatively simple home automation system can save hours of wasted energy in both
residential and commercial applications. For example, imagine an auto on/off at night

time in all major city office buildings, say after 10pm. When no motion is detected, lights
shut down, and the owner could save kilowatts of wasted overnight energy. Similar
controls on HVAC (Heating Ventilation and Air Conditioning) in buildings could save
even more energy.
Recently, Web technologies have been suggested as an application-level solution
to address the problem of heterogeneous home devices, building upon the concepts of the
Web of Things.
3.2 Technologies used in Home Automation:
Several technologies are used to deploy an automated system at home/office.
Some of the popular technologies are:
3.3.1 Bluetooth:
The Bluetooth wireless technology is set to revolutionize the way people perceive
digital devices in our homes and office environment. Now they are no longer just the
individual devices; instead, with the embedded Bluetooth technology, they form a
network in which appliances can communicate with each other. This wireless technology
is especially useful in home environment, where there exists hardly any infrastructure to
interconnect intelligent appliances. It could be suitably used for home automation in a
cost-effective manner. Operating over unlicensed, universally available frequency of 2.4
GHz, it can link digital devices within a range of 10 m (expandable to 100 m, by
increasing the transmitted power) at the speed of 1 Mbps. Building upon this theme; we
propose a home automation system based on Bluetooth technology.
There are certain issues involved in the design of a home automation system. The
system should be scalable, so that new device can easily be integrated into it. It should
provide a user-friendly interface on the host side, so that the devices can be setup,
monitored and controlled. The interface should also provide some diagnostic services so
those problems with the system, if any, can be tracked down. The overall system should

be fast enough to realize the true power of wireless technology. It should also be cost
effective in order to justify its application in home automation.
The system developed during the course of this research consists of a Host
Controller (HC) implemented on a Personal Computer (PC), and a microcontroller based
temperature-sensor/fan-controller, that is able to communicate with the host through the
Bluetooth link. The system is based on Home Automation Protocol (HAP), developed by
the authors in order to facilitate the master – slave communication in a home automation
network. This protocol ensures a prioritized, interlocked exchange of data. It also
supports dynamic addition and removal of devices on the network. A user interface on
the PC offers device registration, control as well as diagnostic utilities. Bluetooth
development kit from Ericsson was used for the development. A microcontroller was
used as a device controller for client modules.
3.3.2 RTOS based Home Automation System using Android
With the promotion of Android as a Smart Phone Operating System by Google
Inc., Smartphones are becoming more and more popular around the world. Currently,
Android has grown to more than 75% of Smart Phones/Tablets user base. This mass
adoption of Smart Phones has fuelled a demand for applications both soft and hard.
Today, Smartphones are more than just Phones, they’re now the main Human
Interaction Devices and users thus want to control/accomplish most of their tasks
from their Smart Phones rather than conventional ways. The many wireless
protocols that come embedded on a Smartphone has introduced a wireless lifestyle
reliving people from the “wired” cable chaos. With the exception of few low cost
tablets, Bluetooth can be found in almost all Android based devices which have been
very popular over years for wireless data transmission with ease. Home
automation systems are one of the major adopters of Bluetooth technology. Here,
we propose a home automation system based on Bluetooth technology.
Some of the factors that influence the design of a home automation system
include the scalability of the system, the ease of integrating new devices into the system

and security. Also important is the ease of use and friendly user controlling
interface. A cost effective system would qualify it for mass adoption.
Neng- Shiang Ling has presented an architecture for home automation
where the system is based on a dedicated network. This system depicted how to
solve home automation problems at the software level and no hardware aspects were
included. Yavuz and Hasan presented a telephone and PIC based remote control
system. Other studies such as those presented in give examples of web based home
automation system.
Another PC based home automation system for appliances control was
proposed by Sriskanthan. However, the system cannot be controlled by a mobile/cell
phone. R.Piyare proposed a Bluetooth based home automation system using cell
phone. However, this is a very basic system without advanced features like integration
of RTOS, and also lacks onboard sensors like light and temperature that are used
to intelligently control the home appliances without human intervention.
Fig 10. Block Diagram ofHome Automation System using Android

3.3.3 Wi-Fi based Home Automation System:
Wi-Fi (Short for Wireless Fidelity) is a wireless technology that uses radio
frequency to transmit data through the air. Wi-Fi has initial speeds of 1mbps to 2mbps.
Wi-Fi transmits data in the frequency band of 2.4 GHz. It implements the concept of
frequency division multiplexing technology. Range of Wi-Fi technology is 40-300 feet.
The controlling device for the automation in the project is a Microcontroller. The data
sent from PC over Wi-Fi will be received by Wi-Fi module connected to
Microcontroller. Microcontroller reads the data and decides the switching action of
electrical devices connected to it through Relays and Triac switches. The Microcontroller
is programmed used embedded ‘C’ language.
In recent years, wireless systems like WLAN have become more and more common
in home networking. Also in home and building automation systems, the use of wireless
technologies gives several advantages that could not be achieved using a wired network
only.
3.3.3.1 Reduced installation costs:
First and foremost, installation costs are significantly reduced since no cabling
is necessary. Wired solutions require cabling, where material as well as the
professional laying of cables (e.g. into walls) is expensive.
3.3.3.2 Easy deployment, installation, and coverage:
Wireless nodes can be mounted almost anywhere. In adjacent or remote places,
where cabling may not be feasible at all, e.g., a garden house or the patio, connection
to the home network is accomplished instantly by simply mounting nodes in the area.
Hence, wireless technology also helps to enlarge the covered area.
3.3.3.3 System scalability and easy extension:
Deploying a wireless network is especially advantageous when, due to new or
changed requirements, extension of the network is necessary. In contrast to wired

installations, additional nodes do not require additional cabling which makes
extension rather trivial. This makes wireless installations a seminal investment.
3.3.3.4 Aesthetical benefits:
As mentioned before, placement of wireless nodes is easy. Apart from covering a
larger area, this attribute helps to full aesthetical requirements as well. Examples include
representative buildings with all-glass architecture and historical buildings where design
or conservatory reasons do not allow laying of cables.
3.3.3.5 Integration of mobile devices:
With wireless networks, associating mobile devices such as PDAs and
Smartphones with the automation system becomes possible everywhere and at any time,
as a device's exact physical location is no longer crucial for a connection (as long as the
device is in reach of the network).
Typical examples include an engineer who connects to the network, performs a
particular management task, and disconnects after having finished the task; or control of
blinds using a remote control.
For all these reasons, wireless technology is not only an attractive choice in
renovation and refurbishment, but also for new installations.
Fig 11. The Home Automation System using Wi-Fi

There are ways other than of technologies mentioned above or say same technologies
with different microcontrollers, for instance PIC microcontroller—that can be used in
Home Automation.
3.4 ZIGBEE based Home Automation
Home automation is one of the major application areas for ZIGBEE wireless
networking. In this section, a number of these use cases are reviewed. The typical data
rate in home automation is only 10 Kbps . Figure 3.4.1 shows some of the possible
ZIGBEE applications in a typical residential building. Most of the applications shown in
Figure 3.4.1 are briefly reviewed in this chapter.
3.4.1 Security Systems
A security system can consist of several sensors, including motion detectors, glass-
break sensors, and security cameras. These devices need to communicate with the central
security panel through either wire or a wireless network. ZIGBEE-based security systems
simplify installing and upgrading security systems . Despite ZIGBEE’s low data rate, it is
still possible to transfer images wirelessly with acceptable quality. For example, ZIGBEE
has been used in a wireless camera system that records videos of visitors at a home’s
front door and transmits them to a dedicated monitor inside the house.
Fig 3.4.1. Possible ZIGBEE-Enabled Devices in a typical Residential Building

3.4.2 Meter-Reading Systems
Utility meters need to be read on a regular basis to generate utility bills. One way to do
so is to read the meters manually at homeowners’ premises and enter the values into a
database. A ZIGBEE-based automatic meter-reading (AMR) system can create self-
forming wireless mesh networks across residential complexes that link meters with
utilities’ corporate offices. AMR provides the opportunity to remotely monitor a
residence’s electric, gas, and water usage and eliminate the need for a human visiting
each residential unit on a monthly basis.
An AMR can do more than simply deliver the total monthly usage data; it can gather
detailed usage information, automatically detect leaks and equipment problems, and help
in tamper detection . ZIGBEE-based wireless devices not only perform monitoring tasks,
they can manage the usage peak by communicating with the appliances inside the house.
For example, when there is a surge in electricity usage, a ZIGBEE-enabled electric water
heater can be turned off for a short period of time to reduce the peak power consumption.
Fig 3.4.2. Light control in a residential Building using ZIGBEE wireless
3.4.3 Irrigation Systems
A sensor-based irrigation system can result in efficient water management. Sensors
across the landscaping field can communicate to the irrigation panel the soil moisture
level at different depths. The controller determines the watering time based on moisture
level, plant type, time of day, and the season. A distributed wireless sensor network
eliminates the difficulty of wiring sensor stations across the field and reduces the
maintenance cost.

3.4.4 Light Control Systems
Light control is one of the classic examples of using ZIGBEE in a house or commercial
building. In traditional light installation, to turn on or off the light it is necessary to bring
the wire from the light to a switch. Installation of a new recess light, for example,
requires new wiring to a switch. If the recess light and the switch are equipped with
ZIGBEE devices, no wired connection between the light and the switch is necessary. In
this way, any switch in the house can be assigned to turn on and off a specific light.
Figure 3.4.2 is an example of wireless connections between wall switches and lights.
In our example, the lights are located in a residential building entrance, living area, and
hallway. The wall switch in the entrance can turn on and off any of the four lights. The
living area Wall switch, in contrast, communicates only with the lights in the living area.
Living area lights are in close proximity to each other, and therefore a single ZIGBEE
device can be used for both lights.
The concept of using binding tables is applicable in the example of Figure 3.4.2.
Wall switch 1 is logically connected to all four lights. Wall switch 2 is bound only to the
lights in the living area. One of the devices in the network has the task of storing and
updating the binding table.
A ZIGBEE-enabled recess light can be more expensive than a regular recess light, but
the installation cost of a ZIGBEE-enabled light is lower because it requires no additional
wiring to a wall switch. Using wireless remotes to control the lights is not a new concept.
ZIGBEE provides the opportunity to implement this concept on a large scale by ensuring
long battery life and interoperability of products from various vendors in a reliable and
low-cost network.
In addition to potential cost savings, ZIGBEE-enabled lights can have other benefits in
a house. For example, the ZIGBEE devices embedded in the recess lights can act as
routers to relay a message across the house, or the lights can be programmed to dim
whenever the television set is turned on. The ZIGBEE light control mechanism has been
used for street light controls as well.
3.4.5 Multizone HVAC Systems
The Multizone control system allows a single heating, ventilation, and air-conditioning
(HVAC) unit to have separate temperature zones in the house. Zoning the HVAC system
can help save energy by controlling the flow of air to each room and avoiding cooling or
heating unnecessary areas. Figure 3.4.3 is a simplified diagram that shows motors
controlling air dampers and regulating the flow of air to different zones. ZIGBEE devices
control these motors based on the commands they receive from the main HVAC zone
control panel and temperature sensors. An alternative way of implementing a Multizone

Fig 3.4.3. Multizone Air conditioning using ZIGBEE controlled Air Dampers
control system is to connect the zone control panel, motors, and temperature sensors via
wires instead of a wireless network. A wired system has less flexibility and additional
labor cost for wiring, but the cost of the parts might be slightly lower. Total system cost
and flexibility for future modifications should be the decision factors in selecting between
these two implementation methods.
4. WHY ZIGBEE?
ZIGBEE is a worldwide open standard for wireless radio networks in the monitoring
and control fields. The standard was developed by the ZIGBEE Alliance (an association
of international companies) to meet the following principal needs:
 low cost
 ultra-low power consumption
 use of unlicensed radio bands
 cheap and easy installation
 flexible and extendable networks
 integrated intelligence for network set-up and message routing
Some of the above requirements are related - for example, the need for extremely
low power consumption is motivated by the use of battery-powered nodes which can be
installed cheaply and easily, without any power cabling, in difficult locations.
4.1 Features:
Some exceptional features that differentiate ZIGBEE from other wireless
protocols are as follows:

4.1.1 Easy Install
 Do-it-yourself installation simplicity
 Ideal for remodel or new construction
 Self-organizing networks simplify set-up and maintenance
 Proven interference avoidance ensures worry-free operation
4.1.2 Internet Connectivity
 Control devices from anywhere in the world
 Use mobile phones to control smart home
4.1.3 Power Control
 Monitor power use
 Turn on/off devices remotely
4.1.4 Security
 Easily add devices to create an integrated smart home security system
 Built-in security ensures integrity of smart home
4.1.5 Lighting Control
 Customize lighting levels based on activity and create scenes
4.2 ZIGBEE TECHNOLOGY
 ZIGBEE specification
 2.4 GHz global operation
 Long battery life; over 7 years for security sensors
 Wireless range up to 70m indoors and 400m outdoors
 Networking flexibility to cover homes of all sizes
 Open and freely available specification based on international standards
 Highly scalable solutions for thousands of devices
 Integrates control and monitoring devices for lighting, security, occupancy,
motion detection and convenience

4.3 DEVICES SUPPORTED
4.3.1 Generic
 On/Off Switch
 Level Control Switch
 On/Off Output
 Level Controllable Output
 Scene Selector
 Configuration Tool
 Remote Control
 Combined Interface
 Range Extender
 Mains Power Outlet
 Door Lock
 Door Lock Controller
 Simple Sensor
 Consumption Awareness Device
 Home Gateway/Energy Management System
 Smart Plug
 White Goods
 Meter Interface
 4.3.2 Lighting
 On/Off Light
 Dimmable Light
 Color Dimmable Light
 On/Off Light Switch
 Dimmer Switch
 Color Dimmer Switch
 Light Sensor
 Occupancy Sensor
4.3.3 Closures
 Shade
 Shade Controller
 Window Covering Device
 Window Covering Controller

4.3.4 HVAC
 Heating/Cooling Unit
 Thermostat
 Temperature Sensor
 Pump
 Pump Controller
 Pressure Sensor
 Flow Sensor
4.3.5 Intruder Alarm Systems
 IAS Control and Indicating Equipment
 IAS Ancillary Control Equipment
 IAS Zone
 IAS Warning Device
4.4 BENEFITS
4.4.1 Affordable
Devices designed for do-it-yourself or professional installation Promotes greater
energy awareness and control Open standard supports competitive marketplace of
multiple products that lowers cost through competition Years of battery life and ease of
maintenance reduce operating costs for service providers and allow affordable solutions
for consumers.
4.4.2 Easy
Wireless technology eliminates cost and hassle of running wires Certified
interoperability, global 2.4GHz spectrum simplifies installation and operation Automatic
features simplify use Internet connection for greater access and control Simple set-up
procedures support do-it-yourself configurations.
4.4.3 Safety
Easily install wireless sensors to monitor a wide variety of conditions Receive
automatic notification upon detection of unusual events.

4.4.4 Secure
AES 128 encryption secures personal information Device authentications secures
networks from neighboring networks.
4.4.5 Interoperable
Integrates control and monitoring devices for lighting, security, appliances and home
access Customer can select from a variety of products to meet needs Interoperability
between a variety of products regardless of manufacturer Works with other ZIGBEE
networks.
So ZIG BEE is the suitable technology for this kind of application. The following
table gives a better understanding of why choosing ZIGBEE.
Table 1.1.
5. Wireless Sensors

Architecture:
External Memory
DigitalI/Oports
Radio Transceiver
AnalogI/OPorts
Microcontrolle
r
D/
A
A/
D
D/A