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 Fulfillmentof 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 Sensor Networks:

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/m2/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×60mm2 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) cow collars,(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×120mm2 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×3km2.

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 mm2.

We used the TinyOS operating system and implemented the MintRoute3 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 TinyOS3 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

mm2 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 of total current consumption by CPU and radio (100% duty cycle) for different states. (b) Breakdown of transducer 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 of Home 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:

D/A

A/D

D/AMicrocontroller

Analog I/O Ports

Radio Transceiver

Digital I/O ports

External Memory