Wireless Sensor Home Automation Networks Based

Wireless Sensor Home Automation Networks Based upon Sun SPOT Gengkun Wang*, Wei Xiang*, Haoyu Chen† , and Peng Wen* *Faculty of Engineering and Surveying † Faculty of Business University of Southern Queensland, Toowoomba, QLD 4350, Australia Email: {Gengkun.Wang, Wei.Xiang}@usq.edu.au

Keywords:WSN, HAA, WSHAN, Sun SPOT.

Abstract This paper aims to develop a simple wireless sensor home automation network (WSHAN). The WSHAN is implemented using two different specialised motes, i.e, collector and interface motes. The environmental data is sampled and broadcast by collector motes, and the data is received by interface motes and host. Interface motes can forward data to external systems, i.e., climate control, light control and alarm systems, while the host can save received environmental data for further use. Six testbeds are defined to verify the accuracy and performance of the proposed WSHAN. The results show that the selected sensors are deemed to be accurate enough for an WSHAN. Even though the development kit only includes two physical Sun SPOTs (Small Programmable Object Technology), it is possible to develop a working WSHAN. A combination of the physical and virtual Sun SPOTs provide enough motes for the WSHAN to cover a small house.

1.

Introduction

Home automation (HA) can provide safety, comfort, convenience and effective management for home equipments. It is becoming an attractive research issue in industry areas [1]. An HA system is a integration of various services, which contains security system, airconditioning, heating system, lighting control, electronic appliance control, communication system, and so on. The basic characteristics and requirements for an HA are described in [2]. The most common technologies in HA are wired technologies such as Ethernet, Lonwork, and X-10 [3]. Even though the Ethernet and Lonwork have impressive reliability and stability, they have disadvantages in the cost and connection [4]. Electric power wires are used to transmit signals and

25

controls in X-10, which reduces the wiring problem [5]. However, the unexpected power off and other electric power problems also make the X-10 system unreliable. With the rapid development of the wireless network technology, the HA system bases on wireless sensors networks (WSNs) becomes more practicable. WSN is a promising network technology that generally consists of a number of small sensor nodes with sensing, data processing, and wireless communications capabilities [6]. WSNs are usually used in home automation applications (HAAs) due to their characteristics of selforganization, high sensing fidelity, low cost and rapid deployment. Although these advantages are very attractive, WSNs present certain challenges related to practical design and implementation in HAAs. This type of network topology changes randomly due to the mobility of the nodes. Since nodes in HAAs have limited transmission range, some of them are unable to communicate directly and a good routing algorithm is important. Technologies intended to implement the WSN in the HAA include: IEEE 802.11 wireless local area network (WLAN), IEEE 1394, IEEE 802.15.4 wireless personal area network (WPAN) used primarily to control all kinds of home appliances [7]. IEEE 802.15.4, considered mainly for WSNs, is unfit to transmit high-capacity data. However, this technology is suitable for HAAs which has low-data rate requirement [8]. The aim of the paper is to develop a simple wireless sensor home automation network (WSHAN). For this purpose a small programmable object technology (SPOT) developed by Sun Microsystems is utilised. Sun SPOT implements WPAN technology with the IEEE 802.15.4 standard. The plan is to create an WSHAN which would utilise physical and virtual WSN nodes (Motes). Once the application is running, motes will collect data such as temperature, light level, battery capacity, alarm trigger, and carbon monoxide level, then send the data to the base station or other motes. Motes can be configured to

ICSSC2011

forward any transmissions from other motes. When the host application is started, it listens for any new data from the motes and processes the received data. If required, the host can send information to one or more motes in the network. The paper is organized as follows. A WSHAN is designed in Section II. A detailed description of the design and implementation process is shown in Section III. Once the WSHAN has been implemented, the various testbeds are configured and data collected to gather the results. Suitable testbeds are selected to simulate different aspects of the WSHAN, and experimental results are showed in Section IV. Finally, concluding remarks and future work are given in Section V.

2.

WSHAN System Model

In many HAAs, the potential users often expect to monitor and configure all the home facilities with network. In general, WSHAN devices can be divided into three categories: sensors, actuators, and mobile user interface devices. In the proposed system, roller door remote control, remote switching lights, remote control room temperature, and a number of other scenarios are discarded since significant additional hardware is required or the physical characteristics of the mote prevent a realistic scenario. Precisely, the proposed WSHAN includes the following functions:

Figure 1: System Model 4. HAA, the application which collects data and interacts with the other members of the WSHAN via the base station. According to the structure and network topology, Sun SPOT is used as the mote in our system. Compared to legacy motes, Sun SPOT has the following features: 1. Hardware capability: Sun SPOT has more powerful processor and larger memory space compared with legacy motes. More computing tasks can be directly processed locally instead of sending message back to central server;

1. Collect environmental data, i.e., temperature and light level; 2. Forward data to external systems; 3. Log events and environmental data on the host computer;

2. Extendibility: Sun SPOT supports analog and digital I/O. Even actuators like servos, speaker and force feedback component can be integrated easily;

4. Provide user interface on host computer. The proposed WSHAN system is shown in Fig.1, which consists of a host computer, a base station and motes. The WSHAN is unable to make a proper assessment of the current status in the house unless a number of motes are deployed to gather environmental data. Motes deployed in the house are made up of collector motes (collect environmental data and forward to host or other motes) and interface motes (receive data from host or other motes and forward to external systems). The base station can receive the data sent from the motes and transmit to the host computer. It is connected to the host computer via USB. The host computer runs multiple applications to fulfill various tasks:

3. Programmability: With the advent of programmable motes, developing embedded applications becomes easier; 4. Open source: Sun SPOT is an Open Source Platform. Not only software, but also hardware is open source. Developers can freely customize it to meet any special requirements; Due to the above reasons, we choose to develop our application based on Sun SPOT instead of legacy motes. The abilities of the Sun SPOT allow the measurement of temperature and light levels without developing additional hardware. Due to the limited output capabilities of the physical Sun SPOTs, only screen captures of virtual Sun SPOTs are possible. The number of virtual Sun SPOTs deployed during the tests are limited by the

1. NetBeans IDE 6.8 to launch HAA; 2. Sun SPOT Manager to launch Solarium; 3. Solarium to deploy and run the virtual Sun SPOTs;

26

Data Temperature Light level Battery capacity Alarm trigger Carbon monoxide

Sender

Type of Communication Port Send IEEE Address(broadcast) 66 Host Listen for environmental data 67 Listen for status 68 Listen for host 66 Interface Mote Listen for environmental data 67 Send status to host(unicast) 68 Collector Mote Send environmental data(broadcast) 67

Sample Interval 1 min. 1 min. 30 min. 1 sec. 10 sec.

Table 3: Collected environmental data

Table 1: Port allocation

Identifier 1 2 3 4 5

Data Receivers Temperature Host and Climate Control Mote Light level Host and Light Control Mote Battery capacity Host Alarm trigger Host and Alarm System Mote Carbon monoxide Host and Carbon Mono Control Mote

Message Type Temperature Light Battery Alarm Carbon Monoxide

Table 4: Receivers of collected data

Table 2: Message type identifier collector motes the WSHAN to establish what type of information is included in the packet. The message and the corresponding data types are defined in Table 2. In addition, the collector motes also need to send the location to inform the receivers where the data is collected. The location information had to be of type ”String”. To conserve power, the collector motes is awake only when a sample is to be taken, and the data is transmitted only if the new sampled value differ from the previous measurement. For trouble shooting purposes, any sampling or sending events are indicated by using the light emitting diodes (LEDs) located on the SPOT. The measured environmental data is sent via broadcast datagram to other members of the WSHAN. Table 3 shows the data sample interval, which includes the sample time. Table 4 defines the recipients of the data. The precision of the data sent is 10−2 .

processing power of the desktop computer. Five virtual motes are configured to collect only one environmental data type and transmit the data via broadcast to one virtual interface mote. As specified in Section IV a sample is forwarded every ten seconds from each virtual collector mote.

3.

Implementation

To ensure that different components of the WSHAN can properly interact with each other, we will discuss the implementation of different motes functions in this section.

3..1

WSHAN Configuration

3..3

Each member can have multiple ports open at any time. Therefore, the ports shown in Table 1 are used to communicate between different members in the WSHAN.

Interface to External Systems

For the interface motes the following assumptions are made: 1. The motes is located near the external system.

3..2

Data Collection

2. The motes communicate via universal asynchronous receiver/transmitter (UART) with the external system.

According to the deployment shown in Fig. 1, the data comes from different parts of the house. However, the temperature and light levels outside are also captured by the motes. To streamline the deployment of the application to individual motes, a single multi-functional application is designed for the data collection motes. Each data collection function is run in a separate thread. To identify the message type at the receiver, data sent by the collector motes has to be identified with unique value of type ”byte”. This would allow the the other members of

3. The motes have reliable power to make them less reliant on the battery. 4. The motes is running most of the time to listen for incoming data. The communication to the external system is via UART is to reduce the number of possible ways to communicate with external systems. An exception is made for

27

the door interface. Assuming that one of the analogue or digital outputs is used to drive a solenoid to unlock the door. All interface motes should announce themselves to the WSHAN and communicate the status of the external interface. This allows the host to keep track if the external system is operating. The interface motes have the following capabilities: 1. Receive data from data collection motes; 2. Output the received information to the external system; 3. Trigger message if status of external system has changed; 4. Announce presence to other WSHAN members;

Figure 2: Host main menu

5. Send a periodic signal to host to indicate the status of external system;

For the testbeds a simplified version of the host application is used. The application has three main tasks: 1) Listen for environmental data; 2) Listen for external system status updates; 3) Broadcast IEEE Address to other members of WSHAN.

6. Listen for messages from host. Once an interface mote is deployed, it will listen for datagrams. When a datagram is received from a collector mote the interface mote will verify that the correct message type is included. If the message type is correct, the interface mote will forward the data to the external system. In addition, the interface will listen for the broadcast from host. After receiving a broadcast message from the host, the interface mote will communicate to the host via uni-cast radiogram connection and report the status of the external system in regular intervals.

3..4

4.

Testbeds and Experimental Results

This section documents the configuration and experimental results of the six testbeds. The following calibrated instruments are used to verify the accuracy of the data collected by the WSHAN testbeds. 1. EXTECH 401036 Light Meter;

Data Logging and User Interface on Host

2. FLUKE 115 True RMS Multimeter; The main tasks of the host is acting as the interface between the occupant of the house and the WSHAN. In addition, the host will log data at regular intervals and keep a log of events encountered by the WSHAN. The full version of the host will provide a main menu as shown in Fig.2. The buttons along the top show the status of the external systems connected to the WSHAN. The tree directory on the left side allows the user to access each room or type of environmental data from all collector motes in the WSHAN. The three buttons along the bottom allow the user to either turn off the HAA, unlock the front door or access the system tools. The host logs the temperature, light level, battery capacity, alarm trigger and carbon monoxide. The full version of the host application has the following additional features:

3. EOMEGA RH 101 Temperature Humidity Meter.

4..1

Testbed 1: Accuracy of WSHAN, Internal Sensor

The first testbed verified the accuracy of the collected data. The configuration for this testbed requires two motes to collect environmental data. Each mote collects a different type of environmental data. For this testbed the temperature and light level are measured and sent via broadcast to the host and motes. It is also possible to move the motes to different parts of the house to establish the accuracy change when the distance to the host computer changes. Table 5 shows the accuracy of the light level measurements taken by the WSHAN in testbed 1 compared to the light meter. The light meter and the motes are placed next to each other during the test. Table 6 shows the accuracy of the temperature measurements taken by the WSHAN in testbed 1 compared to the temperature meter. Before taking the measurements both the mote and

1. Graphical user interface; 2. Incoming data storage; 3. Door unlock function; 4. System tools.

28

it is possible for a mote to communicate directly with the host. This distance between the main bedroom and study room is approximately 16 meters. Therefore, regardless of location within the apartment, no more than two hops are required to reach any other Sun SPOTs in the WSHAN.

instrument are placed in position to adjust to the current ambient temperature. Sample No. WSN(Lux) Instrument(Lux) Error(Lux) 1 400 417 +17 2 414 417 +3 3 396 417 +21 4 428 417 -11 5 416 417 +1 6 412 416 +4 7 410 417 +7 8 404 415 +11 9 402 415 +13 10 414 414 0

4..4

Sample No. WSN(◦ C) Instrument(◦ C) Error(◦ C) 1 27.5 28 -0.5 2 27.25 28 -0.75 3 27.5 28 -0.5 4 27.25 28 -0.75 5 27.5 28 -0.5 6 27.25 28 -0.75 7 27.25 28 -0.75 8 27.5 28 -0.5 9 27.25 28 -0.75 10 27.5 28 -0.5

4..5

Testbed 5: Multifunction Data Collection

Since the Sun SPOT has multiple sensors, it is practical for a mote to collect more than one type of data. Therefore, if a mote can collect and send more than one type of data, the receiving host or mote needs to distinguish between different types of environmental data. The code for the collector motes, interface motes and host are implemented by using identifiers. These identifiers indicate to the receivers what type of data is received. The results shows that at no time is any incorrect data received by the host or interface mote.

Table 6: Testbed 1: Temperature accuracy

Testbed 2: Accuracy of WSHAN, External Sensor

4..6 This testbed is only going to be executed if the accuracy of the internal sensors are not accurate enough for the WSHAN. In that case, an external level sensor will have to be developed and connected to the Sun SPOT in order to increase accuracy. Since the results for testbed 1 are accurate for the WSHAN, this testbed is not completed.

4..3

Impact of Noise Sources on

This testbed is to establish if other electronic devices operating in the industrial, scientific and medical band (ISM) frequency band has a negative impact on the performance of the WSHAN. Major equipments operating in ISM band are microwave ovens, wireless networks and cordless phones. To establish if these devices have an impact on the performance of the WSHAN, Sun SPOTs are placed adjacent to these devices when they are running. The environmental data collected is not changed during the test. The experimental results show that neither of the identified noise sources has an impact on the Sun SPOTs.

Table 5: Testbed 1: Light level accuracy

4..2

Testbed 4: WSHAN

Testbed 6: Receiving Delay

This testbed investigates the capability of receivers in the WSHAN. A number of physical and virtual motes send data at progressively shorter intervals to the host. The testbed investigates how much data could be received by a single member before delays in processing the data are noticeable. To establish how long it takes from sampling at the mote to when the data is received a small application is written for the host. The reference measurement shows that the delay is 2288 ms for one sample to be received by the host. Table 7 shows the delay for 10 samples. The sample time is set to 2000 ms. The table shows that no significant increase in delay is experienced when the sample time is reduced to 2 seconds. Table 8 shows the delay for 10 samples. The sample time is set to 1000 ms. Again the table shows that no increase in delay is experienced when the sample time is reduced to 1 second. Table 9 shows the delay for five samples each from

Testbed 3: Maximum Distances between WSHAN Members

This testbed expands the requirements for the previous testbeds. In this testbed the maximum possible distance between members of the WSHAN is investigated. One physical mote is needed to collect a specific environmental data and send the data to the host or motes. While collecting the data, the mote is moved throughout the house. After each relocation, it is verified that the data can still be received by the host. The host computer is located in the study room. Except the main bedroom,

29

Sample No. 1 2 3 4 5

Delay(ms) 2273 2382 2286 2300 2409

Sample No. 6 7 8 9 10

Delay(ms) 2406 2419 2527 2495 2537

all, despite the limitations of the development kit, a WSHAN is deployed and various testbeds are investigated. This paper is the first step to gain understanding of WSHANs, and the positive results obtained by the testbeds can be used as a foundation for future studies.

References

Table 7: Testbed 6: Time delay, 2 sec. between samples

Sample No. 1 2 3 4 5

Delay(ms) 2073 2087 2101 2225 2403

Sample No. 6 7 8 9 10

[1] A. C .W. Wong and A. T. P. So, “Building automation in the 21st century,” in Proc. International Conference on Advances in Power System Control, Operation and Management, Hongkong, China, Nov. 1997, pp. 819 – 824. [2] C. Reinisch, W. Kastner, G. Neugschwandtner, and W. Granzer, “Wireless technologies in home and building automation,” in Proc. IEEE International Conference on Industrial Informatics, Vienna, Austria, June 2007, pp. 93 – 98. [3] Jian she Jin, Jing Jin, Yong hui Wang, Ke Zhao, and Jia jun Hu, “Development of remote-controlled home automation system with wireless sensor network,” in Proc. IEEE International Symposium on Embedded Computing, Beijing, China, Oct. 2008, pp. 169 – 173. [4] Wikipedia, “Lonworks,” May 2010. [5] Wikipedia, “X10 (industry standard),” May 2010. [6] I. F. Akyildiz, Y. Sankarasubramaniam W. Su, and E. Cayirci, “Wireless sensor networks: a survey,” Computer Networks, vol. 38, pp. 393C422, Mar. 2002. [7] Sung-Hwa Hong, Byongguk Kim, and Doo-Seop Eom, “A base-station centric data gathering routing protocol in sensor networks useful in home automation applications,” IEEE Trans. Consum. Electron., vol. 53, pp. 945 – 951, Aug. 2007. [8] L.-J. Chen, T. Sun, and M. Gerla, “Modeling channel conflict probabilities between ieee 802.15 based wireless personal area networks,” in Proc. IEEE International Conference on Communications, Istanbul, Turkey, June 2006, pp. 343 – 348.

Delay(ms) 2253 2251 2265 2325 2339

Table 8: Testbed 6: Time delay, 1 sec. between samples

the two physical motes. The sample time is set to 1000 ms on both motes. The applications on both motes are started at the same time. The table shows that even after only five samples there is a significant delay from when the sample is taken to when it is received by the host. Therefore with an increase in motes in a WSHAN, delay may become significant if the sample time is not properly selected.

5.

Conclusion

The aim of the paper is to develop a simple WSHAN. Even though the development kit we use only includes two physical motes, it is possible to create a WSHAN with the available Sun SPOTs and virtual motes. The limited number of physical motes, however, prevent the deployment of a complete WSHAN. Six testbeds are selected to simulate realistic events within the WSHAN. Each testbed aims to verify a different aspect of a deployed WSHAN. Since WSHANs rely on the interaction of software, hardware and networking, a great number of projects and further tests can be conducted. Additional projects can therefore be defined to focus on any or all of these specific technical aspects. OverSample No. 1 2 3 4 5

Delay(ms) 2115 3145 4158 5173 6172

Sample No. 6 7 8 9 10

Delay(ms) 3115 4145 5158 6172 7171

Table 9: Testbed 6: Time delay, 1 sec. between samples, two motes

30