Journal of Ambient Intelligence and Smart Environments 4 (2012)...

Journal of Ambient Intelligence and Smart Environments 4 (2012) 1–25 1IOS Press

Building Energy-aware Smart Homesusing Web TechnologiesAndreas Kamilaris ∗, Andreas Pitsillides and Michalis YiallourosNetworks Research LaboratoryDepartment of Computer ScienceUniversity of Cyprus, Nicosia, Cyprus{kami, andreas.pitsillides}@cs.ucy.ac.cy, [email protected]

Abstract. New technological advancements allow the Internet to penetrate in embedded computing. IPv6 envisions to mergethe physical and the digital world, through the Internet. The Web of Things interconnects the expanding ecosystem of Internet-enabled embedded devices, by reusing well-accepted and understood Web principles. In this work, the principles of the Webof Things are employed for the development of a comprehensive system for home automation. By combining sensor deviceswith residential smart power outlets, the foundational pillars are built towards energy-aware smart homes that operate withWeb technologies. By designing an application framework for smart homes using request queues for communicating with homedevices, reliability and time efficiency are ensured while prioritized requests can be easily included to the system and multiplesimultaneous family members may be supported. A technical evaluation indicates that Web-enabled smart homes offer acceptableperformance while modern Web techniques can contribute in facilitating and optimizing smart home operations and deployment.Finally, it is demonstrated through various case studies that Web-based, energy-aware smart homes have the potential to provideflexible solutions to challenges such as energy awareness, energy conservation and the integration of future smart homes to thesmart grid of electricity.

Keywords: Smart Home, Web of Things, Wireless Sensor Networks, Smart Power Outlets, REST, Request Queues, Priorities,Energy Awareness, Social Competitions, Social Comparisons, Demand Response, Load Shedding.

Introduction

Technological advancements such as sensor net-works, short-range wireless communications and radio-frequency identification (RFID) are becoming largelycommon, allowing the Internet to penetrate in embed-ded computing. An Internet of Things (IoT) [15] is be-coming feasible, where everyday objects are uniquelyaddressable and interconnected.

Recent efforts for porting the IP stack on embeddeddevices [12,22] and the introduction of IPv6, whichprovides extremely large addressing capabilities, areexpected to facilitate the merging of the physical andthe digital world, through the Internet.

*Corresponding Author. E-mail: [email protected].

Building upon the notion of the IoT, the Web ofThings (WoT) [49,20] reuses well-defined Web tech-niques to interconnect this new generation of Internet-enabled physical devices. While the IoT focuses oninterconnecting heterogeneous devices at the networklayer, the WoT can be seen as a promising practice toachieve interoperability at the application layer. It isabout taking the Web as we know it and extending itso that anyone can plug devices into it.

Household appliances are also being affected by em-bedded technology. They are being equipped with em-bedded microcontrollers and wireless transceivers, of-fering communication capabilities and providing smartbehavior. These augmented appliances, when intercon-nected, may form wireless networks, extending resi-dences into smart home environments [3,21,32,33].

1876-1364/12/$17.00 c© 2012 – IOS Press and the authors. All rights reserved

2 A. Kamilaris et al. / Building Energy-aware Smart Homes using Web Technologies

Smart metering has also gained popularity lately.Residential smart meters are wireless devices that mea-sure in real-time the energy consumption of a housewhile smart power outlets may record the consumptionof various electrical appliances and control their oper-ation by switching them on/off. Smart homes becomethen energy-aware, permitting residents to analyze andmonitor their electricity footprint in detail. Accordingto scientific studies such as [10], timely electrical con-sumption feedback through smart metering has the po-tential to reduce electrical consumption by 5-15%.

Additionally, sensor devices that measure preciselyenvironmental phenomena (e.g. illumination, humid-ity, air quality) and physical conditions (e.g. noise, oc-cupancy, pressure) are incorporated in smart homes,extending their automation possibilities.

We believe that future generations of smart homeswill be massively equipped with networked householdappliances, smart power outlets, smart meters, sensorsand actuators. These devices will be much more per-vasive, integrated in our everyday lives and can evenbe highly mobile. Their management would require ahigh degree of flexibility.

In this work, the Web is proposed as the applicationlayer in future smart homes, because it is ubiquitousand it scales particularly well. An IP-based approachfor home automation can offer equivalent performancewith related traditional home automation standards,while concepts from the Web bring convenience to de-velopers and users [37,16,6].

We exploit the fact that wireless sensor networks(WSN) provide nowadays a reliable and extensible so-lution for real-world deployments in houses and we ex-ploit their wireless, networking capabilities to proposethe development of energy-aware smart homes, basedon embedded sensor technology. We focus on wirelesscommunications inside the home environment as theyconstitute a flexible, plug and play approach to accom-modate mobile, ad hoc networks of sensors and smartpower outlets. Their deployment does not require anymodifications in existing buildings.

In this paper, the innovation lies in the fact that aproof-of-concept system for home automation, builtusing Web technologies, is examined in a real settingthrough a realistic analysis and performance evalua-tion. By designing an application framework for smarthomes using request queues, practical issues are ad-dressed such as transmission failures, concurrent userpresence and priority handling. A technical evalua-tion indicates that an IPv6-based solution offers sat-isfactory results while Web technologies such as Web

caching and event-based Web messaging may enhancethe performance of smart home operations. This re-sponds to some concerns that the WoT would degradethe performance of pervasive real-life applications. Fi-nally, the Web behaviour of the smart home is demon-strated through various case studies, mainly related toelectrical energy awareness and conservation.

The rest of the paper is organized as follows. First,Section 1 provides the important related work in thefield and Section 2 describes the general architectureof the application framework and its extension intoa graphical Web application. Then, Section 3 inves-tigates important issues for integrating embedded de-vices to the Web and Section 4 lists the particular tech-nologies employed for enabling an energy-aware smarthome. Section 5 analyzes the behaviour of the requestqueue mechanism and fine-tunes them for better op-eration while Section 6 involves the technical evalua-tion, focusing on the performance of home devices interms of their response times and energy consumption.Afterwards, Section 7 demonstrates some ubiquitousenergy-related case studies, enabled by using the Webparadigm in smart homes. Finally, Section 8 discussesthe evaluation findings, proposing future work in thefield and Section 9 concludes this paper.

1. Related Work

In an idealized vision of a fully integrated smarthome, all the operations of a house can be efficientlycontrolled by a smart ubiquitous application. However,we are far from realizing this scenario. A main bar-rier is the proliferation of incompatible standards andprotocols used by various device manufacturers, whichmakes the smooth integration of appliances from dif-ferent vendors a very complex process.

To address heterogeneity of embedded devices, re-searchers have envisioned to leverage the existing Webinfrastructure as a scalable and ubiquitous platform,through which physical devices could seamlessly in-teract with each other. Towards this direction, oneof the first attempts was the Cooltown project [36],where each thing, place and person had an associatedWeb page with related information. Another was JXTA[47], an open network platform designed for peer-to-peer computing between resource-constrained devices.

Recent surveys [37,16,6] suggested that IP-basedsolutions constitute a viable alternative in home au-tomation. Big Web services (WS-*) [5] have been pro-posed as a basis to build an infrastructure for domes-tic networks [3]. WS-* are a set of complex standards

A. Kamilaris et al. / Building Energy-aware Smart Homes using Web Technologies 3

and specifications for enterprise application integra-tion. Priyantha et al. [41] have successfully used thesestandards to interact with sensor networks. However,the use of SOAP/XML for messaging is generally notvery energy-efficient in home environments. The workin [17] quantifies this in terms of time and energy.

REpresentational State Transfer (REST) [14] wasthen considered as an appropriate architectural stylefor constrained environments, as it is a lightweightarchitectural style that defines how to properly useHTTP as an application protocol. It advocates in pro-viding Web services modeled as resources, identifiedby Unique Resource Identifiers (URI). Resources canonly be manipulated by the methods specified in theHTTP standard (e.g. GET, PUT, POST, DELETE), un-der a uniform interface. A path towards the integrationof things into the Web through RESTful principles hasbeen proposed in [49], where physical objects are en-abled to the Web by design. This is one of the first pa-pers proposing a global WoT.

Constrained Application Protocol (CoAP) [45] is anIETF effort to develop a Web transfer protocol for usewith resource-limited physical devices, aiming to re-alize the REST architecture in constrained networks.Even though it claims to be a simple protocol with lowoverhead, it is yet another attempt for standardization,not complying to the open nature of the Web. Nonethe-less, it has promising features such as asynchronousmessage exchange and low header overhead.

pREST [11] defines a RESTful protocol to bring thesimplicity and holistic view of data and services on theWeb, to pervasive environments.

A comprehensive report describing the architectureof the WoT, based on REST, is provided in [20].Following the WoT concept, Yazar et al. [50] im-plement an IP-based sensor network system wherenodes communicate their measurements using REST-ful Web services. Similarly, Schor et al. [43] devel-oped a 6LoWPAN-enabled WSN, directly integratedinto the IPv6-based future Internet, where service dis-covery is based on Apple’s mDNS.

In previous work, we combined basic principles ofthe WoT in the area of smart homes [33,32], to developan application framework that enables multiple familymembers to interact concurrently with their home ap-pliances. The practice of using request queues to man-age simultaneous Web requests and address transmis-sion failures was motivated by Shamann [44], whichwas an early gateway system that enabled low-powerdevices to be part of wider networks.

Concerning smart metering, there are two prevalentapproaches for household energy monitoring and con-trol: whole-home and device-specific.

Whole-home approaches place smart meters wherethe home connects to the power grid. In [38], circuit-level power measurements separate aggregated datainto device-level estimates, with accuracy more than90%. ViridiScope [35] places inexpensive sensors nearelectrical appliances to estimate their power consump-tion with less than 10% error.

Device-specific techniques plug smart power out-lets in electrical appliances to manage their opera-tion. ACme [25] is an accurate AC metering networkthat uses wireless sensor motes equipped with en-ergy meters to provide energy measurements of electri-cal appliances. Energie Visible1 visualizes in real-timethe electrical consumption of appliances connected tosmart power outlets in a Web interface. EnergyLife[23] develops a mobile application to provide elec-tricity consumption feedback and conservation tips. In[24], users can utilize their mobile phones as magiclenses to view the energy consumption of their devicesjust by pointing on them with the phone’s camera.

The Gator Tech Smart House [21] proposed theidea of automatically controlling electrical appliancesbased on environmental information collected fromsensors. Using the same concept, iPower [51] adjustselectrical devices to automatically reduce unnecessaryenergy consumption by means of WSN.

In this paper, we extend our earlier implementationof a Web-based application framework [33,32], andexploit previous work in sensor-level Web enablement[43,50], to explore the possibilities offered by usingthe Web paradigm to develop a home ecosystem thatoffers enhanced capabilities and provides satisfactoryperformance, enabling the easy deployment of interac-tive pervasive Web applications for smart homes.

2. An Application Framework for Smart Homes

A lightweight, Web-oriented application frameworkproviding uniform access to heterogeneous embeddeddevices via standard HTTP calls was developed in[33]. The framework supports multiple Web clientsand the early evaluation efforts performed, indicatedthat response times from home devices were accept-able, even when multiple residents interacted concur-rently with their home environment.

1http://www.webofthings.com/energievisible/


Request Queue

Request Queue

Fig. 1. Application framework general architecture.

Figure 1 depicts the general architecture of thisframework. It follows a layered model and it is com-posed of three principal layers: Device Layer, whichis responsible for the management and control of em-bedded devices, Control Layer, which is the centralprocessing unit of the system and Presentation Layer,which generates dynamically a representation of theavailable devices and their corresponding services tothe Web, enabling the uniform interaction with themover a RESTful interface.

Each time a new device is discovered, a new threaddedicated to the physical device is created. A ResourceRegistry maintains the services offered by this deviceas well as information how to properly invoke them. ARequest Queue is also attached to each thread, to en-queue concurrent requests to it. Requests are stored ina First-In, First-Out (FIFO) manner and are transmittedsequentially to the device. Whenever the queue "sus-pects" that the request might have been lost, it retrans-mits it immediately. In this way, transmission failuresare masked effectively in minimum time. The mech-anism for sensing failed message transmissions is ex-plained in Section 5.

The Devices module holds a list of all available de-vices and their services, inside a Device Registry, facil-itating the Web representation of the smart home sta-tus. The Driver holds the technology-specific driversfor enabling communication with embedded devices,by sending/receiving requests to/from them. The Con-

trol Layer hosts the Core module, which runs in thebackground and maintains the system’s threads.

Finally, the Presentation Layer represents the accesspoint to the framework from the Web. A Web Serverallows real-time interaction between Web clients andtheir home environment. A REST Engine, imple-mented by means of Restlet2, ensures a RESTful sys-tem behaviour. Thanks to REST, Web clients can easilyexplore available devices and their services by clickinglinks, as they would browse Web pages.

The framework is implemented in Java because ofthe portability of the language, allowing the frameworkto run on virtually any device that has a Java VirtualMachine. It needs only 2.7 Mbytes for its full instal-lation hence it could be integrated inside almost anycomputing device of the house, even a router or themains smart meter.

2.1. Reasoning about REST

REST was adopted as the foundational architec-tural style for communicating both with Web clientsand physical devices. REST may be suitable for con-strained environments due to its simplicity and flexi-bility. It can guarantee interoperability and a smoothtransition from the Web to the home environment.

2http://www.restlet.org/


Fig. 2. The extended architecture of the Web-based smart home.

Undoubtedly, many standards offer interoperabilitybetween heterogeneous machines. Their main differ-ence from REST is that they include a rather com-plicated set of protocols and guidelines for interac-tion between devices, while REST suggests to usemerely the HTTP protocol and basic Web principles toaddress heterogeneity. A recent study [18] comparesREST with its main opponent, WS-*. The study sug-gests that REST is easier to learn and understand, morelightweight, flexible and scalable, better for heteroge-neous environments while WS-* has better securityfeatures, but is more complex to be used, being moreappropriate for business applications.

Extensible Messaging and Presence Protocol (XMPP)3

is an open XML-based communications technologythat could be applied, however it is heavy for use withembedded devices. JXTA is another alternative, but itis more of an overlay network, not directly related tothe Web. CoAP is a tailored implementation of RESTfor constrained environments, which could be consid-ered in the future when it becomes more mature.

2.2. A Graphical Web Application

HomeWeb [32] extended the architecture of the ap-plication framework to support a graphical Web appli-cation. The classical client-server model was followed,by placing the framework’s functionality on the serverside and the graphical application on the client side.The enhanced system can be observed in Figure 2.

The client application offers a Web-based, interac-tive graphical user interface (GUI) in AJAX, in orderto abstract the home automation procedure. It has been

3http://xmpp.org/

developed with Google Web Toolkit (GWT)4, which isa development toolkit for building interactive Web ap-plications. Graphs that illustrate sensory and electricalconsumption data are produced by means of GoogleChart Tools5. Client-server communication is based onHTTP calls. The application framework exposes its in-terface as a Web API, which is utilized by the client ap-plication to interact with the embedded devices of thesmart home. Response messages from the frameworkare encapsulated in open, well-known formats suchas JSON and XML. Using a Web API in the server-side offers abstraction and loose-coupling between theframework and the client application.

3. Web-enabling Home Devices

We speculate that Internet technology will becomethe future standard in home automation [37,16,6].IPv6-enabled WSN are becoming mature, with easyinstallation, low cost, wide connectivity and naturaluser interaction. IP convergence denotes that futuresmart home applications will benefit from enhancedquality, security, and interoperability.

Web integration of embedded devices can be per-formed either through embedding Web servers directlyon them or by employing gateways. Directly embed-ding Web servers is a recent development [43,50].Web-enabled embedded devices expose their servicesunder a RESTful interface, while communication isbased on HTTP calls. In the following subsections, wepresent different issues that appear when attempting toenable resource-constrained devices to the Web, andthe solutions we propose to address these issues.

3.1. Local Device Discovery

A crucial aspect in embedded computing involvesthe discovery of physical devices in some physical en-vironment. The adopted local device discovery pro-tocol was motivated from WS-Discovery6, which isa multicast discovery protocol that uses SOAP/XMLmessages to locate WS-* services on a local network.

This protocol was adapted for RESTful Web ser-vices by transmitting a single URL instead of a heavySOAP/XML payload in the multicast message. ThisURL points to a Web page, where the services offered

4https://developers.google.com/web-toolkit/5https://developers.google.com/chart/6http://docs.oasis-open.org/ws-dd/discovery/1.1/os/wsdd-

discovery-1.1-spec-os.html


by the device are described. The idea of associatingURLs with physical devices for describing their func-tionality was first mentioned in [36].

When an embedded device joins the IPv6 network, itannounces its existence through the multicast message.The application framework listens at the pre-specifiedmulticasting channel for incoming discovery requests.As soon as it receives a new request, it responds tothe newly found sensor device by an acknowledgmentmessage. Then, the framework creates a new thread,dedicated to this device, and updates the device reg-istry. When the device receives the acknowledgment,it begins to operate normally as an embedded Webserver, accepting requests from the framework.

Through this discovery protocol, a plug and play ap-proach for automatically including home devices in thesmart home is achieved. Less than a second is neededfrom the time some device is switched on, until it isdiscovered by the framework.

The proposed discovery protocol looks similar toMulticast DNS (mDNS) [7], however it is simpler andas reliable as mDNS. More complex protocols thatcould be adopted include DNS based Service Dis-covery (DNS-SD), Simple Service Discovery Protocol(SSDP) and Service Location Protocol (SLP).

3.2. Service Description

In general, embedded devices need to describe theirfunctionality in order to allow the invocation of theirservices by third parties. In our smart home scenario,home devices need to describe their services to the ap-plication framework, in order to enable seamless inter-action with family members through the Web. Servicedescription must be performed in a standardized, Web-based way, to increase the interoperability betweenheterogeneous devices and smart home solutions.

We adopted Web Application Description Language(WADL)7, which is an XML-based file format thatprovides a machine-readable description of HTTP-based Web applications. It can be seen as the REST-ful equivalent of Web Services Description Language(WSDL)8, which is the standard for describing SOAP-based WS-* services. WADL promotes applicationreuse, being a flexible way of describing Web services.

WADL was used to model the services (resources)provided by an embedded device and the relationshipsbetween them. Each physical device maintains its own

7http://wadl.java.net/8http://www.w3.org/TR/wsdl

WADL file in some URL, which could be specified bythe device manufacturer. Obviously, all home devicesof the same type may share the same WADL file. Adevice encapsulates the link to its WADL file in theURL that is transmitted to the framework in the localdevice discovery procedure (see Section 3.1).

As soon as the framework discovers a new device, itparses the discovery message transmitted by the deviceto find the URL that points to the associated WADLfile. By parsing the WADL file, the framework can beinformed about the services offered by the device, aswell about how to invoke them (e.g. URIs, parameters,return values). This information is then stored at theresource registry of each device thread.

Whenever a user wishes to interact with some de-vice, he only needs to follow the guidelines specifiedat its WADL file. In this way, automatic machine-to-machine (M2M) interaction may also be enabled.

Relevant languages for describing sensor informa-tion include Sensor Model Language (SensorML)9 andExtended Environments Markup Language (EEML)10.However, they mostly focus on describing sensorymeasurements and not on explaining how to invokesome particular service offered by a physical device.

3.3. Event-Based Messaging

Because home embedded devices operate as tinyWeb servers, interaction with them is based on pulltechnology, following the classical client-server model.This means that the application framework must askthe devices in frequent intervals about their measure-ments. This is not efficient in event-based scenarios,in which events are triggered only sporadically whensomething important happens e.g. detection of fire orthe opening of a door.

The RESTful Message System (RMS) [48] pro-poses a lightweight alternative for messaging, suitedfor embedded devices that monitor the home envi-ronment for events. It is a push technique, implyingthat communication is initiated by the physical devicesand not by the application framework. In our smarthome case, home devices (server) inform the frame-work (client) only when something important happens.RMS is applied to home devices by enhancing themwith a RESTful API that supports the eventing system.

Push technique is inspired from Web-based pub-lish/subscribe communication. In case the framework

9http://www.opengeospatial.org/standards/sensorml10http://www.eeml.org/


(subscriber) wants to receive notifications about anevent from a sensor device (publisher), it creates anew subscription by POSTing an HTTP request to thedevice. As soon as a new event is sensed, it will bePOSTed back to the subscriber at a callback URL,specified at the subscription message (see Section 6.3).Receiving events in real-time through user-definedcallbacks over HTTP, is the notion of Web hooks11.

3.4. Web Caching

Porting the IPv6 stack on sensor devices slightly in-creases their energy consumption and decreases theirperformance in terms of response times (see Section6.1). However, these issues may be minimized by ex-ploiting the HTTP caching feature. A Web cache is anintermediary between Web servers and clients, moni-toring incoming requests and saving copies of the re-sponses for itself. In case there are subsequent requestsfor the same URL, the cached response is harnessed,instead of asking the origin server for it again.

A lightweight Web cache is included on the applica-tion framework. In this case, Web servers are the sen-sor devices, Web clients are the residents of the smarthome and a gateway cache is installed on the frame-work. The caching mechanism may be used only forGET requests since these are requests that do not al-ter the state of some resource, according to the RESTspecifications. The cache uses the expiration model,which is a way for the server to say how long a re-quested resource stays fresh. Cache freshness time de-fines the validity of some historical sensory measure-ment, as measured by some embedded home device, inorder to employ the cache for satisfying some request,instead of querying the physical device again.

Therefore, whenever a client requests a GET ser-vice, offered by some specific device recently in-voked by another client, the result is automatically re-trieved from the cache. This is called a cache hit, sincethe measurement was successfully satisfied from thecaching mechanism. In case the cache did not containa fresh answer, this would be a cache miss.

The amount of time some measurement is consid-ered valid (fresh), depends on some user-defined pa-rameter. At the technical evaluation in Section 6.1, thisparameter is set to 10 seconds by default. Obviously,a larger amount of time implies more cache hits, how-ever, the results may not be as fresh. On the contrary,

11http://www.webhooks.org/

smaller cache validity times mean more fresh resultsbut also increased cache misses. The relationship be-tween cache freshness time and average response timesfrom home devices is evaluated in Section 6.1.

3.5. Other Issues

During the process of enabling home devices tothe Web, some other issues arising are: sharing ofdevices/services between family members, friends orcolleagues, achieved by harnessing online social net-working sites (see Section 7.3); global Web discoveryof sensor devices/services, facilitated by efforts suchas Dyser [39] and DNS-based discovery [30]; securityof appliances against misuse; and privacy of Web userswho share parts of their sensory data.

4. Embedded Devices inside the Smart Home

In this section, the particular embedded deviceswhich have been used in our proof-of-concept smarthome environment are listed. Two different types ofdevices have been included: Telosb sensor motes, forsensing the environmental conditions inside the smarthome and Ploggs, which are smart power outlets forcontrolling electrical appliances and sensing their elec-trical consumption.

4.1. Sensor Motes

Telosb sensor motes [40] are equipped with a250kbps, 2.4GHz, IEEE802.15.412-compliant Chip-con CC2420 Radio, integrated onboard antenna and a8MHz TI MSP430 microcontroller with 10 kB RAM.These motes integrate by default temperature, humid-ity and illumination sensors, but can also support othersensors (e.g. noise, pollution). We programmed thesensors using TinyOS 2.x13, which is an operatingsystem designed for low-power wireless devices. Bymeans of Blip14, which is an implementation of the6LoWPAN stack for TinyOS, we exposed the defaultsensing capabilities of the motes as RESTful Web ser-vices, transforming them into embedded Web servers.This REST-based modeling of the services offeredby the Telosb sensor motes is provided in the first4 rows of Table 1. 6LoWPAN [13] is an adaptionlayer that allows efficient IPv6 communication over

12http://www.ieee802.org/15/pub/TG4.html13http://www.tinyos.net/14http://smote.cs.berkeley.edu:8000/tracenv/wiki/blip


No. Device Resource Description MIME Verb Parameters1 Telosb Temperature Measurement in Celcius text/plain GET -

2 Telosb Humidity Percentage of humidity text/plain GET -

3 Telosb Light Set RGB LEDs on sensor board text/plain PUT color (char)

4 Telosb Illumination Illumination levels in Lux text/plain GET -

5 Plogg Electricity Instant consumption in Watts JSON GET -

6 Plogg Switch Switches an appliance on/off text/plain PUT mode (String)Table 1

RESTful services offered by Web-enabled embedded home devices.

the IEEE 802.15.4 standard. Through 6LoWPAN, anIPv6-enabled multi-hop WSN was formed, consistingof Telosb motes.

Thus, by deploying these devices around the smarthome, the environmental conditions inside the housecould be sensed in real-time, while the multi-hoptopology would enable the wireless propagation of themeasurements from remote sensors to the base station.

4.2. Smart Power Outlets

Ploggs15 are smart power outlets that can sensethe electrical consumption of electrical appliances. APlogg can be attached to any electrical appliance ordevice that uses a standard mains socket plug. Itshardware is based on Ember’s EM357 ZigBee wire-less technology and Teridian’s 6511 metering chip.Through the ZigBee chip, Ploggs can create a wire-less multi-hop energy metering network inside a smarthome. They can transmit with high accuracy energyconsumption measurements in a user-defined interval,with 1 minute as the default value. Furthermore, theyallow the control of a connected electrical applianceremotely, by switching it on/off. Since Ploggs are pro-grammed with a non-programmable firmware, theycan not be enabled directly to the Web. Thus, they wereenabled indirectly, through the application framework,by developing Java drivers to communicate with themthrough a REST interface. Their RESTful Web ser-vices are displayed in the last 2 rows of Table 1.

Nonetheless, we estimate that future generations ofsmart meters could actually run a full Web server on-board, thus enabling direct, non-mediated interactionwith other peers in the same WSN, such as sensor de-vices, forming a single Web-based multi-hop network.ACme [25] is an early effort towards this vision.

15http://www.prnewswire.co.uk/news-releases/consumer-products-retail-latest-news/plogg-the-configurable-zigbee-smart-plug-155674645.html

0

1

2

3

4

5

6

7

8

Re

qu

est

Qu

eu

e S

ize

Time

lambda=1

lambda=2

Fig. 3. Load at the request queue of some sensor device.

5. Analyzing Request Queues for Enhancing thePerformance of Smart Home Operations

The application framework associates each homedevice with a request queue, for supporting simultane-ous family members sending concurrently HTTP re-quests to them. The queues are responsible for for-warding requests to the devices sequentially, in a first-come, first-serve basis. As soon as a response arrives,the corresponding request is removed and the next re-quest is forwarded to the head of the queue.

Incoming requests must wait in the queue for theirturn to be executed. Figure 3 shows a snapshot of therequest queue load, during a typical framework’s op-eration, for two different scenarios of arrival rates λ,of requests per second. These request rates have beenselected to stress test the system. As the arrival rate ofrequests increases, the size of the queue is increased aswell. This size may be up to 2, when λ = 1 and upto 7, when λ = 2. The waiting time at the queue canbe a significant source of delay, as depicted in Figure 4for the case when λ = 2. Requests need to wait a fewseconds when the size of the queue is more than 2.

During the framework’s operation, in case sometransmitted request/response message is lost, the queuewaits some given amount of time and then it retrans-mits the message. This interval is crucial for the sys-tem’s performance, since fast retransmissions wouldincrease the service rate of the requests. However, re-transmissions that happen too early may encounter the


0

500

1000

1500

2000

2500

3000

3500

4000

0 2 4 6 8

Wait

ing

T

ime (

ms)

Request Queue Load

Fig. 4. Waiting times of the requests at the request queue.

likely event that the original request message had al-ready been served, but the response has not arrivedback yet. Such premature timeouts could cause unnec-essary additional loading that increases collisions in aloaded system, thus leading to system inefficiencies.

Thus, fine-tuning the request queue retransmissioninterval is important for the framework’s operation. Inthe following subsections, the main focus is to analyzethe queue behaviour, and properly set the value of thisinterval. From now on, we would refer to the requestqueue retransmission interval parameter as α.

We need to mention that, during this analysis, weassume that home devices and their services have beenalready discovered by the framework. Thus, the mi-nor delay associated with discovering the devices andparsing their associated WADL files for understandingtheir functionality is not included in the experiments.This is also the case for the experiments in Section 6.

5.1. Emulating a Smart Home Scenario

In order to analyze the request queues, realistic traf-fic from Web clients who represent family memberswas created. Home residents are modeled as softwareagents who reside on the same computer as the appli-cation framework. Therefore, network delay is negli-gible. Using Restlet, a unique TCP socket is assignedto each agent. The arrival rate of family members atthe framework is modeled by an exponential distribu-tion. The exponential distribution is preferred to sim-ulate real-world applications that deal with the occur-rence of events, such as the arrival of customers at abank. The parameter λ denotes the arrival rate of theclients. For example, when λ = 2, this means that onaverage 2 family members arrive at the framework ev-ery second. The operations of each agent include therandom selection of a home device, as well as the ran-dom invocation of one of its RESTful Web services.

5.2. Searching for an Efficient Request QueueRetransmission Interval

The experimental setup for analyzing the queue be-haviour involves 2 sensor motes in a single-hop startopology, 5 meters distance from the base station andfrom each other. A small number of devices was se-lected, as the aim was to observe the queues when hav-ing considerable load. The application framework hasbeen installed on a laptop (Intel Core Duo 2.2 GHz).

Before proceeding to the first experiment, we needto identify the different time-related metrics used in theanalysis procedure:

– Average Request-Response Time or ResponseTime. The average time needed from the creationof a request by a Web client to the arrival of theresponse, transmitted by a sensor device.

– Round Trip Time (RTT). The average amount oftime from the wireless transmission of a requestuntil the arrival of the response.

– Waiting Time q. The amount of time a requestwaits at the queue for its turn.

Obviously, in the case of no transmission failures:

Response T ime = q +RTT (1)

In case transmission failures occur, the average re-sponse time increases according to the equation:

Response T ime = q+RTT+α·pf ·(1− pnf1− pf

)(2)

where pf is the probability of transmission failures andn is the maximum number of retransmission attempts.The RTT of each sensor mote participating in the ex-perimental setup may be derived through sampling.

0

100

200

300

400

500

Less 500 510 520 530 540 550 560 More

Occ

ure

nce

s

RTT Time

Fig. 5. Histogram of RTT times of a sensor mote in one-hop distance.

For instance, Figure 5 presents the histogram ofsome sensor device deployed in one-hop distance fromthe base station. In this case, the average RTT time inthe one-hop communication with the mote is 530 ms


with a standard deviation around 70. Having this inmind, if α < RTT , numerous useless retransmissionswould happen, deteriorating the overall system perfor-mance. This can be observed in Figure 6. Hence, weonly examine values of α ≥ RTT .

0

100

200

300

400

500

600

40 80 120 160 200 240 280 320 360 400 440 480 520 560 600

Retr

an

sm

issio

n A

ttem

pts

(%

)

Request Queue Retransmission Interval

Average RTT Value

Fig. 6. Retransmission attempts in lower values of the request queueretransmission interval.

The first experiment studies the effect of transmis-sion failures on the request queues, using λ = 1. Bydefault, the transmission failures in our smart home de-ployment are around 5%, so we emulated additionalfailures by manually dropping packets at the drivermodule. Figure 7 presents the response times in rela-tion to the retransmission interval α, considering vari-ous percentages of failed transmissions.

0

200

400

600

800

1000

1200

1400

1600

1800

2000

500 600 700 800 900 1000 1100 1200 1300

Res

po

ns

e T

ime (

ms)


20% Transmission Failures




Fig. 7. The effect of transmission failures on the request queues.

As transmission failures increase, response timesare also increased, but not at an alarming rate. In allscenarios, α = 600 ms yields the best response times.As the parameter α increases, response times are in-creased as well. The graph slopes become larger as thepercentage of failures grows. This fact denotes that thefast retransmission feature of the request queue mecha-nism becomes more significant when transmission fail-ures exist in the home environment.

We note that when α is less than 600 ms, the sys-tem does not operate correctly. As displayed in Figure6, the percentage of retransmission attempts -in rela-

tion to the total number of client requests- grows ex-ponentially as α decreases, since the queue incorrectlybelieves that the request messages keep failing. In thespecial case when α = RTT , false retransmission at-tempts reach 18%. Continuous retransmissions causesensor motes to malfunction, reduce their battery life-time and increase the overall loading of the system.

The next experiment examines the interval α in var-ied workload. In this and the next experiments, the de-fault case of 5% transmission failures is used. This isrealistic for typical home environments. The results ofthis experiment are displayed in Figure 8.

0

500

1000

1500

2000

2500

3000

500 600 700 800 900 1000 1100

Resp

on

se T

ime (

ms)


lambda=0.5

lambda=1.0

lambda=1.5

lambda=2.0

Fig. 8. The effect of varied workload on the request queues.

Low traffic implies less retransmissions. Thus, theinfluence of the queue in the overall system perfor-mance is small. However, as the traffic increases, theretransmission interval α becomes more important, es-pecially when λ = 2. Also in this experiment, the mostappropriate value for α, as expected, is about 600 ms.

Considering RTT times of 530 ms, with a stan-dard deviation equal to 70, we claim that the appro-priate value of α in our specific experimental setup,equals the RTT time plus its standard deviation value.To check whether this assumption is correct, we per-formed the last experiment, which investigates the in-fluence of the RTT time on the request queue, as shownin Figure 9 for λ = 1. To increase the RTT time,we programmed the TinyOS application which was in-stalled on the sensor devices to wait an extra delay be-fore transmitting a response back to the framework.

As the RTT delay increases, a good choice of thevalue for α equals the RTT time plus the standard devi-ation. Therefore, we recommend that the α value mustbe set according to the following equation:

α = RTT + c · St. Deviation (3)

where the parameter c allows the system to choosebeing more or less cautious. In a static deployment ofdevices, similar to our emulated experimental setup, c


0

500

1000

1500

2000

2500

3000

3500

4000

600 700 750 800 900 10001100120013001400150016001700

Resp

on

se T

ime (

ms)


No Delay

150 ms Extra Delay

300 ms Extra Delay

600 ms Extra Delay

900 ms Extra Delay

Fig. 9. The effect of RTT on the request queue. The times indicatedare for emulated additional delays over and above the average RTTtime (of average 530 ms).

could be equal to 1. Of course, RTT times and standarddeviation values are learned from the device thread af-ter observing the physical device for some amount oftime. Therefore, the best approach is to set initially αto a larger value, leaving a "safe margin" to avoid pro-ducing continuous retransmissions. During the deviceoperation, the value of α may be fine-tuned accord-ingly, by considering the observed RTT times.

5.3. Potential Benefits of Using Request Queues

By using request queues at the application frame-work for managing the communication with home de-vices, numerous benefits can be identified.

As mentioned before, transmission failures may beeffectively masked. As soon as a failure is "suspected"by the queue, the request is immediately retransmittedto the device. This fast retransmission mechanism de-creases response times, especially when messages arelost frequently due to transmission errors.

Furthermore, multiple residents may interact simul-taneously with their home environment. Even thoughtheir requests could be delayed in increased traffic con-ditions, it is guaranteed that they would eventually besatisfied. Section 6.1 evaluates response times in pres-ence of high traffic from numerous tenants.

Moreover, the stability condition of each requestqueue may be roughly estimated by observing the ar-rival rate of incoming requests λ. To achieve stability,it must be ensured that service time is less than theinter-arrival time, i.e. RTT < 1

λ . In our earlier ex-periments (with RTT = 530 ms), this implies thatλc = 1.88 for each sensor mote, i.e. λ must be alwayssmaller that λc to avoid overloading the queues.

Another possibility to effectively serve increasingtraffic would be to use load balancing. An equivalentexample from real life concerns a queue at a bank,

which employs a number of employees to serve ef-ficiently its customers. In this case, a load balancermodule could be placed on the framework between thedriver module and the device threads (assuming multi-ple devices could serve the requests), to balance the re-quests between home devices, ensuring less responsetimes and extending the battery lifetime of the devices.

In addition, the use of request queues may supportprioritized requests. Priorities might be important insome scenarios, e.g. to switch off immediately faultyelectrical appliances to avoid possibility of fire. High-priority requests could be executed first, while requestwith lower priority would wait longer at the queue.This capability is demonstrated in Section 6.2.

An interesting aspect is the capability of predict-ing the average response times, offering some per-formance indications to tenants and third-party smarthome applications.

The use of request queues enables the detailed anal-ysis of the system by employing queuing theory. Queu-ing theory could answer more complicated questionssuch as the mean number of customers in the systemor the mean waiting times. It could also estimate theprobability of the request queue to be in a certain state.

Finally, since our experimental setup focuses ona static deployment of embedded devices inside thehome area, the parameter c in Equation 3 is set equal to1, because the average RTT times of the sensor motesare constant. However, in a dynamic scenario with mo-bile devices and fast changing topologies, c shouldtake larger values, to adapt more easily to the possiblyhighly varying RTT times of the embedded devices.

6. Technical Evaluation

Three scenarios are used to test the house ecosys-tem. In the first, the existence of a large family is as-sumed, interacting concurrently with the home envi-ronment. In the second, a scenario with prioritized re-quests is considered, highlighting an important featureof harnessing request queues in smart home middle-ware. Finally, the third scenario investigates an event-based case, which is common for home automation.

These three experiments aim to examine the smarthome system from various perspectives. These per-spectives cover: a request-response scenario with hightraffic; a scenario in which requests need to be classi-fied using priorities; and a case where events are gen-erated only sporadically and the framework must beimmediately notified as soon as they are triggered.


The technical evaluation focuses on sensor devices,as they are expected to operate under constrained re-sources, accepting numerous requests due to their con-tinuous monitoring operation. The performance of sen-sor motes reflects the performance of any Web-enabledhome device, including smart power outlets.

Generally, smart power outlets do not demand highperformance as their primary task is to inform the sys-tem in pre-defined, relatively slow intervals about theenergy consumption of electrical appliances. They arealso harnessed for controlling individual appliances,but this operation is expected to happen sporadically(see Sections 7.2, 7.4 and 7.5). Nonetheless, the multi-hop performance of the wireless network of power out-lets is examined in Section 7.4, under a demand re-sponse setup within a virtual smart grid. Through thisstudy, the functionality of the smart outlets, in regardto the electrical appliances they control, will be tested.

Figure 10 depicts the system infrastructure thatwould be used in the following experiments, deployedin a one-bedroom home. The application frameworkhas been installed on a laptop (Intel Core Duo 2.2GHz). In the next tests, the focus is on the followingfour performance metrics:

– Waiting Time at the request queues.– Average Response Time.– Cache Hits, i.e. the serving of a request through

the Web caching mechanism, instead of transmit-ting the request to the physical home device.

– Energy Consumption, i.e. the power consumed bythe sensor devices during their operation, mea-sured in Joules.

Living Room

Kitchen

Bathroom

Bedroom

Laundry Room

Application Framework for Smart Homes

(Base Station)

5 meters

Fig. 10. Experimental setup during technical evaluation.

For better comparisons, we also programmed thesensor motes without 6LoWPAN support, using thenative programming model of TinyOS, still followingREST. Thus, we developed simulated REST, which isa light, simulated version of REST without the IPv6overhead. Simulated REST is more efficient, becauseit uses the default messaging stack of TinyOS withoutthe IPv6 burden. From now on, the 6LoWPAN-basedWSN is referred to as 6LoWPAN REST and the versionwithout the IPv6 support as simulated REST.

An important configuration parameter influencingthe measurement results is the transmission powerused by the sensor motes. We set the transmissionpower at -25 dBm, to allow a 5-meters transmissionrange and facilitate a multi-hop operation of the WSNinside the house. Another important aspect concernsthe sizes of the messages involved in the interactionsbetween the sensor motes and the framework. The sizeof the 6LoWPAN messages is 128 bytes, while themessages at simulated REST have size 80 bytes.

6.1. Request-Response Interaction

This scenario includes multiple virtual residents, in-teracting with the IPv6-enabled sensor devices of theirsmart home through the Web, in a request-responsepattern. The emulation described in Section 5.1 is alsofollowed in this case.

6.1.1. A Single-Hop TopologyDuring the evaluation efforts in [32], 4 IPv6-enabled

sensor motes were employed, deployed in a star topol-ogy. A small number of sensors was selected, in or-der to test the system in a demanding case, measuringaverage request-response times in different workloads.

The results showed that less than 700 ms wereenough for satisfying the requests, even in the most ex-treme cases. Simulated REST proved to be more ef-ficient than 6LoWPAN REST. However, when Webcaching was employed (see Section 3.4), using only10 seconds freshness time, 6LoWPAN REST exe-cuted faster than simulated REST in workloads that ex-ceeded an arrival rate λ = 1.16. In this case, the effi-ciency of 6LoWPAN REST depended on the percent-age of cache hits at each test.

6.1.2. A Multi-Hop TopologyIn most cases, single-hop topologies do not cover

typical smart homes as the indoor range of a sensormote is 20-30 meters. Hence, this paper tests the ex-ecution times of the Web-based WSN also in a multi-hop scenario. The 4 sensor motes considered in the


single-hop case were now placed as leaf nodes in athree-hop distance from the base station, in a 2-3-4topology, as shown in Figure 10. This topology was se-lected to stress the operation of the WSN under heavyworkload. All sensor motes had 5 meters distance fromtheir parent node. Various tests were performed with λranging from 0.2 to 2. Each test ran for 5 minutes.

The results can be observed in Figure 11. The av-erage response times are less than a second, even inthe highest-traffic scenario. The multi-hop environ-ment causes additional delays of around 170-200 msfor 6LoWPAN REST and 110-140 ms for simulatedREST, compared to the single-hop tests. Similar to thesingle-hop scenario, 6LoWPAN REST with 10 sec-onds cache freshness time executes faster than simu-lated REST, when λ > 0.8. This happens in lower traf-fic conditions compared to the single-hop case, whereλ needed to reach 1.16. A possible explanation is thatthe additional delays caused by the multi-hop environ-ment make the caching mechanism more significant.

0

100

200

300

400

500

600

700

800

900

1000

0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2

lambda

Ave

rage

Res

pons

e Ti

me

(ms)

6LoWPAN RESTSimulated REST6LoWPAN REST (with 10s Caching)

Fig. 11. Response times of the WSN.

Figure 12 shows the percentage of cache hits, in cor-relation to the arrival rate λ. Increased traffic producesa larger percentage of cache hits. As the cache hits in-crease, response time is effectively decreased. This factindicates high scalability of the system. Numerous si-multaneous Web requests can be handled only in a fewhundreds of milliseconds. Comparing with the single-hop case, we conclude that cache hits do not depend onthe sensor topology, being rather based on the work-load and on the behavior of home residents at each test.

Cache hits are directly related to the freshness timeof the cache. There is a trade-off in using a larger fresh-ness time because even though the cache hits are in-creased and the overall response times are reduced, thecached sensory measurements become older. A moreprecise relationship between the cache freshness timeand the response times may be perceived by view-ing Figure 13. Apparently, as the freshness time in-

0

10

20

30

40

50

60

70

0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2

lambda

Cac

he H

its (%

)

Cache Hits (1 Hop)Cache Hits (3 Hops)

Fig. 12. Cache success based on number of requests per minute.

0

50

100

150

200

250

300

350

400

450

10 15 20 25 30 35 40 45 50 55 60

Avera

ge R

esp

on

se T

ime (

ms)

Cache Freshness Time (sec)

lambda=1

lambda=1.5

lambda=2

Fig. 13. Response times in relation to the cache freshness time.

creases, the average response time is effectively de-creased. This happens since the percentage of cachehits increases, and the framework serves the requeststhrough the caching mechanism instead of queryingthe physical home devices, which may be located mul-tiple hops away from the base station. When increas-ing the default value of 10 seconds freshness time by5-30 seconds, the request time is linearly reduced witha large gradient. Further increases of the freshness timecause only small further reductions to the responsetime. Similar patterns hold for all the three tests usingdifferent arrival rates.

6.1.3. Energy Performance of Sensor DevicesIn this test, the energy performance of 6LoWPAN

REST in comparison to simulated REST was studied,by employing the Avrora simulator [46]. Since Avrorasimulates programs written for AVR microcontrollers,the TinyOS sensor application was tailored to run onMicaz motes. The power profiles of both mote typesare listed in [40]. We focused on the 4 leaf nodes ofthe three-hop scenario. Those are the sensors that sat-isfied the Web requests from home residents. The sametests were ran, assuming 5 meters node distance and5 minutes execution time. The energy consumption ofone of the leaf sensor motes is displayed in Figure 14.The graph is for a single sensor but similar results have


1.00

1.50

2.00

2.50

3.00

3.50

4.00

4.50

0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2

lambda

Ener

gy C

onsu

mpt

ion

(J)

6LoWPAN RESTSimulated REST6LoWPAN REST (with 10s caching)

Fig. 14. Energy performance of the WSN.

been obtained for the other leaf sensors. The simula-tion results for intermediate sensor motes in the three-hop topology follow a similar pattern.

Observing the figure, the difference in energy con-sumption between 6LoWPAN REST and simulatedREST is small, around 2-12%. This variance hap-pens due to the probabilistic selection of sensor motesby the residents. 6LoWPAN REST consumes slightlymore energy due to the small overhead of packet size at6LoWPAN. This small difference in energy consump-tion validates the statement that an IP-based stack forWSN does not necessarily consume more energy [22].Both in 6LoWPAN REST and simulated REST, theconsumption increases almost linearly.

When 6LoWPAN REST employs caching with 10seconds freshness time, it becomes much more energy-efficient in comparison to either 6LoWPAN REST orsimulated REST, in workloads with λ > 0.4. This ef-ficiency reaches 50% under heavy workloads. Underlight traffic, efficiency is still considerable, fluctuat-ing between 15-25%. 6LoWPAN REST with cachingscales well as the number of requests increases.

We need to note that the results depend greatly onthe transmission power setting. At some power set-tings, receiving (or idle listening) may consume morethan transmitting. The link layer of the sensor nodesdoes not use any duty cycling, but it is always listen-ing by default. The fact that sleep modes were not con-sidered explains the rather increased values of energyconsumption in the tests.

6.2. Support of Prioritized Requests

Priorities are considered in cases when an order ofimportance or urgency needs to be maintained. Typicalcategories of priorities may be low, normal and high.High-priority requests are the most important, whilelow-priority requests the least significant.

0

2000

4000

6000

8000

10000

12000

0 1 2 3 4 5 6 7 8 9 10 11

Wait

ing

Tim

e (

ms)

Request Queue Load

Normal-Priority Requests

Low-Priority Requests

High-Priority Requests

Fig. 15. Waiting times for requests with different priorities.

In smart home applications, using prioritized re-quests may be beneficial when some urgent operationneeds to be performed as fast as possible. This oper-ation may involve triggering the alarm when a thiefbreaks into the house or switching off an electric ap-pliance that consumes excessive amounts of energy.

The request queues may be easily transformed intopriority queues by converting the queues into priorityheaps. A key characteristic of binary heaps is that theykeep at the head of their binary tree the request that hasthe highest priority. The algorithm we used for defin-ing priorities is described in Algorithm 1.

Algorithm 1 An algorithm for setting prioritized re-quests in the smart home.

1: Assign a priority to each request (low, normal orhigh).

2: Each prioritized request is translated into an inte-ger value by the application framework, accordingto the following formula: low=1, normal=5 andhigh=10.

3: The priority heap selects for execution the requestwith the highest priority number.

4: To avoid starvation of low-priority requests, thepriorities of all waiting requests are increased by1 at every round, i.e. at a successful execution ofsome request.

To test the priority queuing mechanism of the ap-plication framework, 2 sensor devices in a star topol-ogy were considered, with 5 meters distance from thebase station and from each other. Figure 15 showsthe response times of the prioritized requests accord-ing to the current size of the heap when each requestappeared. This emulation was performed by settingλ = 3, including 10% high-priority requests, 10% low-priority and the rest with normal priority.

High-priority requests are executed first, with wait-ing times less than 2 seconds, even when the heap has


Priority Min. Heap Load Max. Heap Load Avg. Heap Load St. Dev.Low 1 12 5.40 3.808

Normal 1 9 3.24 2.421

High 1 3 1.44 1.003Table 2

Priority heap load conditions at the different priority categories.

a size equal to 9. On the contrary, low-priority requestsneed significantly more time, reaching 10 seconds insome cases. Table 2 shows the load conditions of thepriority heap at each priority category. As expected,high-priority requests remain the least time in the heap,between 1-3 rounds. Low-priority requests stay in av-erage 5 rounds in the heap, while requests with nor-mal priority fluctuate between low- and high-priorityrequests. Algorithm 1 may be easily extended to sup-port more layers of priorities.

Offering support for priorities is not a native fea-ture of the Web, even though it may be supported inthe future. However, priorities can still be employedinternally by the application framework, e.g. to favourthe requests coming from specific family members orthose marked by the users as more important in somerule-based smart home application, similar to the onein Section 7.2.

6.3. Handling Event-Based Messaging

To test the proposed push technique for event-basedWeb messaging (see Section 3.3), a scenario was cre-ated in which sensor motes informed the applicationframework as soon as the levels of illumination fellbelow a certain threshold. The application frameworkwas configured to POST a subscription HTTP requestto the motes (publishers) that offered illumination ser-vices and supported RMS. Whenever the percentageof light in some room was significantly reduced, thisevent was POSTed back to the framework (subscriber)at a specified callback URL.

These events were forced to be triggered by man-ually turning the lights on/off. Considering the three-hop scenario in Figure 10 with 5 meters node distance,around 400-440 ms were needed from the time thelights were turned off, until the notification about theevent reached the framework from a leaf node. Obvi-ously, in a pull-based scenario, event notification couldlast seconds or even minutes, depending on the pollingfrequency of the application framework.

The Avrora simulator was used to compare the en-ergy consumption of 6LoWPAN REST when RMS

0

50

100

150

200

250

300

350

400

450

500

0 2 4 6 8 10

Time (Hours)En

ergy

Con

sum

ptio

n (J

)

6LoWPAN RMS (Push)6LoWPAN (Pull)BlinkOscilloscope

Fig. 16. Push Vs pull energy performance.

was employed (push technique) and when the frame-work periodically polled the sensor motes for newly-sensed events (pull technique). The triggering of a fallin illumination levels was simulated to occur once ev-ery 5 minutes. Therefore, the motes supporting RMSinformed the framework once every 5 minutes aboutthese events while, in the pull case, the framework wasforced to ask the sensors every 30 seconds about a pos-sible new event.

Figure 16 presents the results of the simulation, forsome hours of operation. To provide a better overallpicture, the simulation results for Blink and Oscillo-scope16 are also displayed. From the figure, it seemsthat 6LoWPAN REST with RMS consumes consider-ably less energy than when the classic pull techniqueis utilized. This difference is around 23%. Comparingwith Blink and Oscilloscope, the energy consumptionin the 6LoWPAN cases is 3-4 times less. This happensbecause blinking the LEDs of the sensor motes is veryenergy-demanding. More precisely, blinking the LEDsis responsible for 60-75% of the total energy consumedby the motes during their operation.

16Blink and Oscilloscope are two well-known TinyOS applica-tions. Blink is a simple application that blinks the 3 mote LEDs. Ittests that the boot sequence and timers are working properly. Thethree LEDs blink at 1Hz, 2Hz, and 4Hz. Oscilloscope is a simpledata-collection demo. It periodically samples the default sensor with4Hz sampling rate and broadcasts a message over the radio every 10readings, blinking at the same time the green LED of the mote.


In general, the simulation measurements are linear.In real life this would not be true, as the battery wouldslowly discharge over time [34]. Thus, the suppliedvoltage would decrease, as well would decrease theconsumed current and the consumed energy. Unfortu-nately, the Avrora simulator does not take into accountbattery discharging. However, for 10 hours simulationtime, the voltage drop can be considered negligible.

Assuming that sensor motes operate with two typ-ical AA batteries, they can consume in total around18,72 kJ. According to the simulation results, sensorswith 6LoWPAN REST and RMS would be able tooperate for 2 months and 23 days, while 6LoWPANREST without RMS only for 2 months and 3 days. Un-der this assumption, sensors with Blink would operatefor 17 days and 9 hours while sensors with Oscillo-scope application for 20 days and 2 hours.

Through RMS push technique, smaller delays andbetter energy conservation are achieved, as we avoidpolling the motes with continuous request messages.In any case, these calculations can not be realistic sincethe link layer of the sensor nodes does not use any dutycycling for saving energy during sleep times. Though,the findings are useful for comparison purposes.

7. The Web as a Platform for facing Challenges inbuilding Energy-Aware Smart Homes

By using Web technologies, smart home applica-tions can exploit their flexible operational environmentto provide solutions to challenges related to electri-cal energy awareness and conservation. In the follow-ing subsections, various case studies are considered inwhich it is demonstrated how the Web-based behaviorof energy-aware smart homes can be exploited to de-velop Web-based green applications that target homeenvironments. At each scenario, the functionality ofthe application framework is augmented to support theapplication-specific requirements.

7.1. Energy Awareness

By understanding the electricity footprint they con-sume, residents are able to make intelligent choicesabout energy [10]. Through detailed energy monitor-ing, electricity-wasting actions can be avoided andenergy-inefficient devices can be managed better or bereplaced. The application framework was adapted toallow residents to view their electricity footprint viaa Web interface (see Section 2.2). Through the Web,

Fig. 17. Detailed electrical consumption distribution.

they can remotely switch off electrical appliances, ifthey forgot them on when they hastily left the house.

Residents can associate the energy consumption oftheir electrical appliances with the actual tariffs fromtheir electric utilities, translating kilowatt hours (kWh)into money. In such a way, users are not confused withdifficult to understand measurement units.

Historical data about energy and costs are aggre-gated into graphs that present useful remarks about theyearly, monthly and weekly consumption in the wholehouse or per appliance. By comparing their actual elec-tricity footprint with previous ones, citizens can beaware in real-time if their actions are energy- and cost-efficient. By determining the impact of their actions ina timely fashion, they can evolve a more sustainablebehavior. Figure 17 presents a typical snapshot of thesmart home application, in which the distribution ofthe energy consumption and the costs of the electricalappliances in a house are presented in a pie chart.

7.2. Energy-Efficient Smart Rules

Energy conservation is a big issue in the world withtremendous environmental, social and political impli-cations. Buildings consume around 70% of the totalelectrical energy consumed globally [1].

When the resident receives timely information of theenvironmental context of his home (e.g. temperature,light, motion), together with real-time details aboutthe consumption of his electrical devices, he can takeclever decisions to control their operation in an auto-mated and energy-efficient way. Offering to a residentthe means to actively take part in energy-saving ini-tiatives could help him to substantially decrease hisoverall electrical consumption [42]. Each person has


Fig. 18. An example of a physical mashup at the mashup editor.

unique behavioral patterns and the potential to config-ure his home energy usage effectively to suit his needs.

Since the application framework exposes sensor de-vices and electrical appliances as Web resources ac-cessed through HTTP calls, they can be manipulatedin the same way as any other Web resource. They caneven form Web mashups, which are Web-based ap-plications built by combining existing Web resources.When Web mashups exploit real-world services of-fered by physical devices, they are extended into phys-ical mashups [19], combining physical services usingthe same tools and techniques of classic Web mashups.

Following the physical mashup example, a graphicalmashup editor is developed, through which a residentcan create his own energy-efficient smart rules to au-tomate his house in just a few clicks, using operationssuch as greater than, if/then, and/or, etc. He can com-bine environmental sensory measurements with ser-vices offered from his electrical appliances, such assensing in real-time their consumption and switchingthem on/off. Each habitant maintains his own profile,being able to view, edit and delete his mashups.

A snapshot of the mashup editor is provided in Fig-ure 18, which demonstrates an example of a mashup.It is assumed that a resident has the bad habit to turnoff the lights when he goes to sleep but to forget thetelevision and the DVD player on. As soon as a sen-sor device placed in the living room senses reducedillumination late at night, then the television and theDVD player are automatically turned off. By creatingthis mashup, this resident can avert this habit, whichcosts him energy and money. More advanced mashupscould also reveal undesirable events such as electricityleakage or unexpectedly high temperatures, and coun-termeasures can be automatically taken, such as to turnoff immediately faulty appliances.

Home appliances, when exposed as Web resources,can be combined seamlessly with content and servicesprovided through the Web. The mashup editor supportsthe blending of home devices with Web resources. For

instance, the user can employ a weather forecast ser-vice, provided by a reliable organization through theWeb (e.g. World Weather Online, Yahoo Weather), toadjust the temperature of his house in a future time. Incase the outside temperature is predicted to substan-tially increase after some hours, the user can exploitthis information to turn off the electric heating auto-matically before this increase happens.

7.3. Sharing Home Devices through Online SocialNetworking

Social networking sites (SNS) have penetrated deeplyin our lives, enabling collaboration and sharing onthe Web. Two-thirds of the world’s Internet popula-tion visit social networking or blogging sites, account-ing for almost 10% of all Internet time [2]. Currently,Facebook is the world’s most popular SNS with morethan 900 million active users.

As the application framework exposes its function-ality as a RESTful API, it is easy to develop a phys-ical mashup that involves the household appliancesof a smart home in a social networking application.The Web 2.0 technologies provided by Facebook maybe utilized to transform the interaction with the smarthome into a shared, social experience [28]. Figure 19is a snapshot of My Social Home Facebook applica-tion, in which the environmental conditions and the in-stant energy consumption of the electrical appliancesinside the house are graphically listed. The owner ofthe house can share his home devices with his friendsor his family easily, just by adding them in a Facebookgroup, created specifically for delegating them access.Only authenticated users in Facebook, who are autho-rized by the home owner to be members of that group,can fully manipulate the application.

Users can subscribe to events, triggered when theenvironmental conditions inside the house exceedsome threshold. For example, a small increase in theenergy consumption of the fridge could trigger anevent warning that the fridge door has been left open.In such cases, group members can be notified throughthe notification mechanisms provided by the FacebookAPI (a status update, a Wall post, a note or an email).

In general, the practice of creating smart home ap-plications with a social context, promotes sharing ofphysical devices/services between tenants. Such appli-cations could increase the awareness of the residentsabout their home environment, helping them to acquiremore sustainable behaviors. SNS users could find it


Fig. 19. A snapshot of "My Social Home" Facebook application.

easier to accept and use such applications, as they be-come blended with their overall online experience.

7.4. Exploiting the Demand Response Program of theSmart Grid

Future high energy demands cannot be accommo-dated by current electricity grids. More rational uti-lization of electrical energy is needed and this can beachieved only when electric utilities are fully aware inreal-time about the electrical consumption and the de-mands of their customers. The grid becomes intelligentwhen it manages to deliver electricity from suppliersto consumers using two-way digital communicationsand a smart metering system. A smart grid17 is a net-work of networks that has come to describe the futureelectricity grid, enhanced with Information and Com-munication Technology (ICT), applied to generation,delivery and consumption of electric power.

Future smart homes need to be compliant with thesmart grid. A significant feature of the grid is demandresponse (DR), for managing customers’ consumptionpricing according to supply conditions, allowing usersto cut their energy bills by scheduling low-priority de-vices to harness energy only when it is cheapest. Dy-namic tariffs can be received in real-time through theWeb, when utilities provide Web API to automaticallydisseminate tariffs to the homes of the consumers.

A task scheduling mechanism was developed on topof the graphical Web application for smart homes, andadapted to DR from electric utilities [29]. Followingthe physical mashup paradigm, residents could pro-gram actions to be executed in low-tariff hours, for ex-

17http://smartgrid.ieee.org/ieee-smart-grid

0

0.5

1

1.5

2

2.5

3

1 2 3 4 5

Tim

e (

se

co

nd

s)

Washing Machine Distance (Hops)

Plogg Switch-On Service

Plogg Switch-Off Service

Fig. 20. Response times in switching on/off the washing machine.

ample to perform the washing when the tariff is 10%less than its normal price.

The tenant may define a maximum amount of wait-ing time, in case tariff does not fall below the specifiedlimit in that time window, to start the task right after.He can also set the execution of a task to be performedin morning, afternoon or night time. Finally, he mayspecify the task duration, switching the correspondingelectrical appliance off when the task completes.

Ploggs, in this case, are utilized for controlling theoperation of schedulable devices, which are devicesthat are supposed to accomplish some specific task buttheir operation is not momentarily urgent and can bepostponed for a future time (e.g. washing machine,clothes dryer, dishwasher).

We considered a typical real-life scenario to exam-ine the feasibility of supporting DR and to assess theperformance of the smart power outlets, in terms of re-sponse time. Most washing machines allow a user todefine a preferred operation mode and start the wash-ing in a future time. Such a washing machine was pro-grammed through the task scheduling mechanism, tostart the washing when the tariff from the electric util-ity is 5% less than its normal price.

Since our country does not yet support the smartgrid, its operation was simulated through the Web bydeveloping a Web server that models DR functional-ity. A RESTful Web service was included, in order toinform customers in real-time about a utility’s currenttariffs using RSS Web feeds. The execution time ofthis task was tested when placing the washing machineand its corresponding Plogg in different hops from theframework. Figure 20 illustrates the results of this ex-periment. The network of smart power outlets needsapproximately 0.8-1.6 seconds to switch on the elec-trical device, which is an acceptable amount of time.Switching off the device after it has performed its task,requires 1.2-2.7 seconds. This delay is caused by thefirmware and hardware of Plogg devices.


This proof-of-concept deployment indicates the fea-sibility of supporting smart grid applications such asDR in energy-aware smart homes that operate usingWeb technologies, with satisfactory performance.

7.5. Using Load Shedding for Frequency Stability ofthe Smart Grid

Load shedding [9] is an action taken to prevent fre-quency abnormal operation and is the last resort tomaintain frequency stability of the electrical grid. Con-tingency scenarios could include the non-scheduledoutage of a generation unit or a main transformer. Inthis case, the non-served load previously served by thegenerator that currently experiences an outage needs tobe allocated to other online units. However, the onlinegenerators may not be able to accommodate/undertakethe extra load because they are already highly loaded.

In order to avoid an under-frequency abnormal oper-ation of the power system, the operator will be forcedto apply a low-frequency demand control action, re-moving intentionally loads from service to prevent thetotal collapse of the system due to cascading events.This procedure lasts until the frequency magnitude re-covers at the desired levels, when the rest of the onlineunits are able to fully compensate the non-served load.

A key feature of the future smart grid would be se-lective load shedding that could be performed in a dis-tributed manner, feasible when the grid is capable ofdirectly controlling domestic loads, by communicatingwith energy-aware smart homes in real-time. Also inthis case, the Web is considered a flexible and interop-erable platform to achieve this communication.

As mentioned in Section 2, the functionality of aWeb-enabled smart home may be exposed as a WebAPI. Therefore, smart grid controllers would interactwith the house through the functions specified by thisAPI. A simple Web API for smart homes, targetedto enable remote management and control by electricutilities is presented in Table 3.

The electric utility monitors the frequency of thepower system in near real time. In case of a critical fre-quency variation, control messages are issued from theutility control center to the grid controllers, to reducepower consumption. Then, the controllers would usethe Web API of smart homes in a best-effort manner,asking houses to reduce their consumption based ontheir current electrical demand and the grid condition.

To demonstrate this potential application of thesmart grid, an emulated scenario of selective loadshedding has been implemented [31], employing 3 res-

Fig. 21. The experimental setup used in load shedding [31].

idential units in which the application framework forsmart homes has been deployed, along with 4-5 Ploggsat each house, associated with various electrical ap-pliances of the house, preferably schedulable devices.The experimental setup is displayed in Figure 21.

A smart grid controller was simulated on Simulink,and its main task was to maintain the stability of thesystem by determining the optimal amount of elec-tric load that should be shed to achieve frequency sta-bility. We assume that the grid experiences a sudden,non-scheduled increase in load. This increase has beenmodeled as a step function change in demand. As a re-sult, the frequency of the power system starts to declinecontinuously. Three different cases are considered:

1. No load shedding takes place.2. Load shedding is performed following the con-

ventional practice that is applied by the vast ma-jority of power system operators worldwide.

3. Intelligent selective load shedding is performed.

In the first case, the frequency decline is just mon-itored without taking any action. In the second case,circuit breakers are activated, shedding load based onan approximate rule of thumb, which indicates thatthe connected load magnitude should be decreased lin-early in relation to the frequency decline.

Finally, in the third case, an intelligent algorithm de-termines when load shedding should be performed andthe amount of load that should be shed. The three dif-ferent phases of this algorithm can be observed in Fig-ure 21. At first, the grid controller monitors the electri-cal consumption of all the houses by issuing an HTTPGET electricity command to each smart home, in regu-lar time intervals of 100 ms. At some time, it decides toperform load shedding to maintain the frequency sta-bility of the system. Hence, it decides to issue HTTP


No. Resource URL REST Verb MIME (Return) Type Parameter (Type)1 HouseName/electricity GET JSON -

2 HouseName/reduceconsumption POST text/plain reduction (Integer)

3 HouseName/increaseconsumption POST text/plain maxincrease (Integer)Table 3

Sample Web API of a Web-enabled energy-aware smart home for interaction with electric utilities at the smart grid.

Fig. 22. Load shedding using different practices.

POST reduceconsumption commands to smart homesB and C to reduce their instant consumption by 500and 800 Watts respectively. Smart Home B respondsto this command by switching off the dishwasher andsmart home C by switching off the electric iron. Theseare schedulable devices whose operation may be post-poned for a future time. Then, when the system is sta-bilized again, the controller issues POST increasecon-sumption commands to smart homes B and C, allowingthem to increase their consumption by 600 and 1000Watts respectively.

Figure 22 depicts the performance of the three dif-ferent schemes in regard to the time response of thefrequency variation. When no load shedding is applied,the frequency declines exceeding the permitted limits(of +/- 3 Hz), causing under-frequency abnormal oper-ation. In this case, the power grid experiences instabil-ity and cascading events will possibly follow, causinga total blackout. In the second case, when conventionalpractices regarding load shedding are performed, thefrequency exceeds the desired levels for 4 seconds andneeds 35 seconds in total in order to "absorb" the dis-turbance. After this critical time, frequency oscilla-tions still exist, being reduced with a small step. In thiscase, a set of customers would experience a total out-age causing major discomfort to them.

Finally, when an intelligent selective load sheddingalgorithm is applied, the frequency remains at the de-sired levels during the whole emulation time. It recov-ers fast in the first 35 seconds of the emulation and to-tally absorbs the disturbance after 50 seconds. Moreinformation about this experiment are available in [31].

Our findings indicate that this application can con-tribute towards a more robust power grid that controls

Fig. 23. System infrastructure at the social competition.

frequency oscillations more effectively and efficiently,preventing power system instabilities and total outagesof utility services, minimizing unexpected outages andcustomer discomfort.

7.6. Energy Conservation through SocialCompetitions in Blocks of Flats

In general, residents are willing and capable toadapt their behavior to energy-saving lifestyles if giventhe necessary feedback, support, and incentives. Es-pecially the influence of the community by means ofcomparisons with other people’s consumptions, hasthe potential to drive residents towards a more persis-tent behavioral change [8]. Social norms can motivatepeople to question their behavior, if they discover itis not "normal" [4]. Residents may learn from theirneighbors and receive encouragement and support.

To motivate people become more aware about en-ergy and reduce their electrical consumption, a socialcompetition between neighboring flats in large resi-dential blocks was created. Ploggs equipped with ex-ternal current transformers for loads up to 100 Amperewere employed, for acquiring the consumption of eachflat in real-time. A Plogg was attached to the mains me-ter of every flat, communicating wirelessly in frequentintervals (every minute) the electricity data in JSONformat to the application framework. The applicationframework was responsible to parse the electricity-related data, extract the important information and for-


Sheet1 Chart 1

Page 1

0

20

40

60

80

100

120

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

Day of Month

Ener

gy C

onsu

mpt

ion

(kW

h)

6

8

10

12

14

16

18

20

Temperature (C

)

Energy ConsumptionTemperature

-1

4

9

14

19

24

0

50

100

150

200

250

300

350

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

Te

mp

era

ture

(C)

En

erg

y C

on

su

mp

tio

n (

kW

h)

Day of Month

Energy Consumption

Temperature

Fig. 24. Electrical consumption of the blocks during the competition, the suburban block (left) and the urban block (right)

0

100

200

300

400

500

600

700

101 102 103 202 302 303

En

erg

y C

on

su

mp

tio

n (

kW

h)

Day of Month

Previous Month

This Month

0

200

400

600

800

1000

1200

1400

1600

101 102 103 104 105 106 107 201 202 203 204 205 206 207 301 302 303 304 305 306

En

erg

y C

on

su

mp

tio

n (

kW

h)

Day of Month

Previous Month This Month

Fig. 25. Electrical consumption of the flats during the competition, the suburban flats (left) and the urban flats (right)

ward them to a Web server and an online database. Thesystem infrastructure is illustrated in Figure 23.

Residents could get informed in real-time abouttheir overall ranking in the competition, according totheir electricity footprint. They could also view theirhistorical electrical consumption at the previous daysof the competition, as well the overall electricity con-sumed by the block. The winning flat would be the flatthat reduced most effectively its electrical consump-tion in the one-month competition. The award to thewinning flat was a real-time energy monitor.

Our case study included two blocks of flats. The firstis at a suburb, with 6 flats participating and the secondin an urban area, having 20 flats. The duration of thecompetition was one month for each block, performedin winter period. The total energy performance of thetwo blocks, as a summation of the electrical consump-tion of all the participating flats, is depicted in Fig-ure 24 on a daily basis. Temperature is strongly corre-lated to the energy consumption of the buildings. Thisis clear evidence that a considerable percentage of con-sumed electricity is utilized for heating.

Because of the high dependencies to temperature,"safe" conclusions about the energy savings due to thecompetition can not be extracted. However, by com-paring the first two weeks of the study with the lasttwo, the energy consumption in the last two weeks isreduced by 260 kWh or 26% at the suburban block andby 1091 kWh or 33% for the urban block.

Figure 25 presents the electricity footprint of eachflat during the competition, as well as that of the previ-ous month (acquired from their electricity bills). Mostof the flats have reduced effectively their consumption.The average reduction of energy is 11.90% at the sub-urban block and 27.74% in the urban case.

These findings suggest that the practice of givingawards and social incentives to residents may be effec-tive in initiatives concerning environmental awareness.More details about this study are provided in [26].

7.7. Energy Awareness through Social Comparisons

Tenants cannot easily assimilate quantitatively howmuch energy they consume in their residence. They donot possess the proper metrics to "quantify" their to-


Fig. 26. A snapshot of Social Electricity Facebook application.

tal consumption. This happens because each area, cityor country has different tariffs and varied weather andphysical conditions. A promising way to perceive theirconsumed energy is to compare it with the amount con-sumed by relatives, friends and neighbors [27].

Social Electricity18 is an award-winning19 Facebookapplication that allows people to compare their elec-tricity footprint with their friends or even their neigh-borhood, village or town, to determine if their ownconsumption is low, average or high. By understandingthe "semantics" of consumed energy, residents wouldthen be more responsible to reduce their overall con-sumption. A snapshot of Social Electricity applicationcan be observed in Figure 26, showing a comparisonof electrical consumption between friends, tagged onthe map of Cyprus where they live.

To acquire electricity-related data, we collaboratedwith the Electricity Authority of Cyprus (EAC), whichis the only utility in Cyprus. EAC delegated us withanonymous access to the sensory measurements of allthe electricity meters, which are deployed in the resi-dential buildings of Cyprus. Respecting the privacy ofCypriot citizens, the electricity measurements were ag-gregated at a street level (address, postal code, city), to

18https://apps.facebook.com/socialelectricity/19Social Electricity has been awarded the first prize in the

2nd Green ICT Application Challenge, organized by the Inter-national Telecommunication Union (ITU). http://www.itu.int/ITU-T/climatechange/greenict/201206/index.html

avoid the guessing of the consumption at some specificresidence.

Social Electricity promotes sharing of people’s elec-tricity consumption figures with their friends at a streetlevel, transforming the procedure of saving energyinto a social game. Residents are encouraged to in-sert their monthly electrical consumption, and com-pare it with their local neighborhood or their friends.Moreover, useful statistics are provided about the mostenergy-efficient streets, villages, areas and cities nearthe user’s location, helping people to acquire "regionawareness", inspired to take actions to help the localcommunity maintain a better ranking in the future.

Furthermore, statistics are given concerning the ar-eas with the least/most energy consumption in thewhole of Cyprus. Users may also observe the electricalconsumption of their street in previous months or inthe same month in previous years, and compare it withthe present street consumption. They can perform thishistorical comparison also in relation to their Facebookfriends, to observe their friends’ street energy behaviorand compare it with the behavior of their street.

A preliminary evaluation involved 72 undergraduatestudents, who were asked to use Social Electricity fora week. 70% of the students reported that the applica-tion helped them become more aware about the energythey consume. Around 18% admitted they had a highelectricity bill and they promised to consume energymore rationally in the future. Overall, these initial find-


ings were encouraging to proceed with a deploymentaround the whole of Cyprus, with the support of EAC.

This deployment started in August, 2012. In lessthan a month, more than 500 Cypriots used the socialapplication while its idea was promoted through all themain media of the country. In cooperation with EAC,our main goals are to monitor the energy behavior ofthe Cypriot society to consider whether this approachhas contributed in increasing the energy awareness ofCypriot citizens, and how much it has influenced themto save energy and money.

8. Discussion and Future Work

Our work constitutes a promising practice for en-abling flexible, plug and play smart home applica-tions, by following Web principles. Our approach fa-cilitates home automation procedure and is character-ized by high interoperability. Application developmentbecomes easy, by harnessing well-known and under-stood Web technologies.

A technical evaluation indicates that, by followingthe Web model, acceptable performance of householdembedded devices can be achieved, in terms of re-sponse times and energy consumption.

In detail, the evaluation efforts show that IPv6 canbe well applied on sensor motes. Especially whencombined with Web caching, 6LoWPAN can even out-perform (identical) applications that utilize the nativemessaging stack of embedded operating systems suchas TinyOS. Event-based (push) Web messaging, aswell as Web caching, can be applied for preserving thebattery lifetime of sensor devices, while offering fasternotifications in case events are triggered.

By enhancing smart home middleware with requestqueues that are responsible for managing the commu-nication with home devices, numerous benefits maybe obtained, such as masking transmission failures,handling efficiently and reliably numerous concurrentWeb clients and supporting priorities. Hence, betterperformance in terms of waiting and response times,scalability and reliability is ensured.

We claim that by means of the energy-related smarthome applications presented in Section 7, our smarthome system can contribute in saving energy, but aloneit would not be capable of effectively reducing theoverall electricity consumption.

We stress the fact that we do not propose a new tech-nology for advanced automation, nor an effective, opti-mized method for energy conservation. Our focus is toshow how easy and elegant home automation becomes,

when employing Web techniques. We recognize thathome residents are not expected to have the expertiseto design energy-efficient strategies, even though theiractive involvement in energy-saving initiatives can en-gage them in sustainable lifestyles [42].

Nonetheless, our system can be utilized as a flexi-ble platform, on top of which more advanced practicesfor energy-efficient home automation can be devel-oped. Classical optimization techniques, or even ma-chine learning techniques such as for example neuralnetworks could be applied for the creation of advancedenergy-saving schemes, on top of a reliable, interoper-able and efficient physical ecosystem.

Given the residents’ difficulty with current, com-monly available home automation systems, a completehuman-computer interaction (HCI) design and study ofthe system’s usability is necessary. For example, userswould likely find it complicated to specify rules basedon sensor measurements (see Section 7.2). It would bebetter if they could just specify comfort levels, whilethe system would adjust the low-level parameters.

Definitely, a great challenge for future smart homesis also security. As a first step, an authentication mech-anism was developed allowing only authenticated fam-ily members to connect to the application framework.Security in home environments is a large topic and ex-tended Web-based schemes need to be developed thatinvolve end-to-end security mechanisms that guaran-tee authentication, data integrity and confidentiality,from the home devices to the Web and vice-versa.

Finally, further analysis of the request queue mech-anism is required, in order to enhance the performanceof smart home operations and increase the reliability ofthe house. The potential benefits of employing requestqueues, listed in Section 5.3 need to be studied andevaluated experimentally. For example, features suchas load balancing and estimation of current responsetimes, needed for satisfying tenants’ requests, wouldbe considered. In addition, aspects from queuing the-ory could be employed for answering more compli-cated questions about the system’s behaviour whileEquation 3 could be adapted to support also mobilehome devices and dynamic environments.

Summing up, four main areas of future work in-clude: further analysis of the request queue mecha-nism; optimization and control theoretic or even ma-chine learning techniques, which would orchestrate theoperation of home devices towards green functional-ity; HCI to increase the usability of the graphical Webapplications for smart homes; and Web practices to en-sure security in future home environments.


9. Conclusion

In this paper, a Web-based application frameworkwas presented, which may constitute a foundationalpillar towards a comprehensive energy-aware smarthome that operates using Web principles. Sensor de-vices and smart power outlets were enabled to the Weband combined together, in order to offer the means to-wards automating the home environment. The uniquedesign of the framework, employing request queues forhandling the interaction of tenants with their home de-vices, enhances the overall performance of the system,offering reliability and better response times. The sup-port of prioritized requests may be also important infuture smart home deployments, when urgent requestsmust be executed as soon as possible.

Overall, a flexible application-level solution forhome automation is proposed, based on combiningexisting Web technologies and reliable, well-studiedWeb techniques. We demonstrated that effective smarthome applications can be easily created by using Webtechnologies, to encounter technological and societalchallenges such as energy awareness and conservation.

Our technical evaluation indicates that the Web ofThings can be successfully applied to smart homes.Enhanced Web techniques such as HTTP caching andevent-based Web messaging can contribute in increas-ing the performance and scalability of smart home ap-plications, reducing the power consumption of sensordevices, preserving their battery lifetime.

Concluding, we believe that the future in home au-tomation is towards the Internet. Web technologieshave the potential to become the future standards insmart home environments, towards an interoperableand sustainable world.

References

[1] Communication from the European Commission. Energy Effi-ciency: Delivering the 20% target. November 2008. EuropaPress Release.

[2] Nielsen Online Report: Global Faces and Net-worked Places, March 2009. Online at:http://blog.nielsen.com/nielsenwire/global/social-networking-new-global-footprint/.

[3] M. Aiello. The role of web services at home. In Proceed-ings of the International Conference on Web Service-basedSystems and Applications (WEBSA), page 164, Guadeloupe,French Caribbean, February 2006. IEEE.

[4] H. Allcott. Social norms and energy conservation. Journal ofPublic Economics, 95(9-10):1082–1095, October 2011.

[5] G. Alonso, F. Casati, H. Kuno, and V. Machiraju. Web Services:Concepts, Architectures. Springer, 2004.

[6] A. Aragues, I. Martinez, P. Del Valle, P. Munoz, J. Escayola,and J. Trigo. Trends in entertainment, home automation ande-health: Toward cross-domain integration. IEEE Communica-tions Magazine, 50(6):160–167, June 2012.

[7] S. Cheshire and M. Krochmal. Multicast DNS, December2011. IETF Draft, draft-cheshire-dnsext-multicastdns.txt.

[8] R. B. Cialdini. Influence: science and practice. Allyn andBacon, 2001.

[9] D. Craciun, S. Ichim, and Y. Besanger. A new soft loadshedding: Power system stability with contribution from con-sumers. In Proceedings of PES PowerTech, pages 1–6,Bucharest, Romania, July 2009. IEEE.

[10] S. Darby. The effectiveness of feedback on energy consump-tion - A review for defra of the literature on metering, billingand direct displays. Environmental Change Institute, Univer-sity of Oxford, 2006.

[11] W. Drytkiewicz, I. Radusch, S. Arbanowski, and R. Popescu-Zeletin. pREST: a REST-based protocol for pervasive systems.In Proceedings of the First International Conference on Mo-bile Ad-hoc and Sensor Systems (MASS), pages 340–348, FortLauderdale, Florida, USA, October 2004. IEEE.

[12] A. Dunkels, T. Voigt, and J. Alonso. Making TCP/IP Viablefor Wireless Sensor Networks. In Proceedings of the First Eu-ropean Workshop on Wireless Sensor Networks (EWSN), work-in-progress session, Berlin, Germany, January 2004.

[13] N. K. et al. IPv6 over Low-Power Wireless Personal Area Net-works (6LoWPANs): Overview, Assumptions, Problem State-ment, and Goals, August 2007. RFC 4919.

[14] R. T. Fielding. Architectural Styles and the Design of Network-based Software Architectures. PhD thesis, University of Cali-fornia, Irvine, California, 2000.

[15] N. Gershenfeld, R. Krikorian, and D. Cohen. The Internet ofThings. Scientific American, 291(4):76–81, October 2004.

[16] C. Gomez and J. Paradells. Wireless home automation net-works: A survey of architectures and technologies. IEEE Com-munications Magazine, 48(6):92–101, 2010.

[17] C. Groba and S. Clarke. Web services on embedded systems - aperformance study. In First International Workshop on the Webof Things (WoT), at PerCom 2010, pages 726–731, Mannheim,Germany, March 2010. IEEE.

[18] D. Guinard, I. Ion, and S. Mayer. In Search of an Internet ofThings Service Architecture: REST or WS-*? A Developer-sâAZ Perspective. In Proceedings of the Eighth InternationalICST Conference on Mobile and Ubiquitous Systems (Mobiq-uitous), Copenhagen, Denmark, December 2011.

[19] D. Guinard and V. Trifa. Towards the Web of Things: WebMashups for Embedded Devices. In Workshop on Mashups,Enterprise Mashups and Lightweight Composition on the Web(MEM), at WWW 2009, Madrid, Spain, April 2009.

[20] D. Guinard, V. Trifa, and E. Wilde. Architecting a MashableOpen World Wide Web of Things. Technical Report No. 663,Dept. of Computer Science, ETH Zurich, February 2010.

[21] S. Helal, W. Mann, H. El-Zabadani, J. King, Y. Kaddoura, andE. Jansen. The Gator Tech Smart House: A ProgrammablePervasive Space. Computer, 38(3):50–60, March 2005.

[22] J. W. Hui and D. E. Culler. IP is dead, long live IP for wirelesssensor networks. In Proceedings of the Sixth Conference onNetworked Embedded Sensor Systems (SenSys), pages 15–28,Raleigh, NC, USA, November 2008. ACM.

[23] G. Jacucci, A. Spagnolli, L. Gamberini, A. Chalambalakis,and C. Bjorkskog. Designing Effective feedback of Electricity


Consumption for Mobile User Interfaces. PsychNology Jour-nal, 7(3):265–289, 2009.

[24] M. Jahn, M. Jentsch, C. R. Prause, F. Pramudianto, and A. A.-A. andRen ÌAReiners. The Energy Aware Smart Home. Pro-ceedings of the Fifth International Conference on Future Infor-mation Technology (FutureTech), pages 1–8, May 2010.

[25] X. Jiang, S. Dawson-Haggerty, P. Dutta, and D. Culler. Designand implementation of a high-fidelity AC metering network. InProceedings of the Eighth International Conference on Infor-mation Processing in Sensor Networks (IPSN), pages 253–264,Washington, DC, USA, April 2009. ACM/IEEE.

[26] A. Kamilaris, G. Kitromilides, and A. Pitsillides. Energy con-servation through social competitions in blocks of flats. InProceedings of the First International Conference on SmartGrids and Green IT Systems (SMARTGREENS), Porto, Portu-gal, April 2012.

[27] A. Kamilaris, D. Papadiomidous, and A. Pitsillides. LessonsLearned from Online Social Networking of Physical Things. InProceedings of the Sixth International Conference on Broad-band and Wireless Computing, Communication and Applica-tions (BWCCA), Barcelona, Spain, October 2011.

[28] A. Kamilaris and A. Pitsillides. Social Networking of theSmart Home. In Proceedings of the 21st Annual IEEE Interna-tional Symposium on Personal,Indoor and Mobile Radio Com-munications (PIMRC), Istanbul, Turkey, September 2010.

[29] A. Kamilaris and A. Pitsillides. Exploiting Demand Responsein Web-based Energy-aware Smart Homes. In Proceedingsof the First International Conference on Smart Grids, GreenCommunications and IT Energy-aware Technologies (Energy),Venice, Italy, May 2011.

[30] A. Kamilaris and A. Pitsillides. Using DNS for Global Dis-covery of Environmental Services. In Proceedings of theEighth International Conference on Web Information Systemsand Technologies (WEBIST), Porto, Portugal, April 2012.

[31] A. Kamilaris, Y. Tofis, C. Bekara, A. Pitsillides, and E. Kyri-akides. Integrating Web-Enabled Energy-Aware Smart Homesto the Smart Grid. International Journal On Advances in Intel-ligent Systems, 5(1 and 2):15–31, July 2012.

[32] A. Kamilaris, V. Trifa, and A. Pitsillides. HomeWeb: An Appli-cation Framework for Web-based Smart Homes. In Proceed-ings of the 18th International Conference on Telecommunica-tions (ICT), Ayia Napa, Cyprus, May 2011.

[33] A. Kamilaris, V. Trifa, and A. Pitsillides. The Smart Homemeets the Web of Things. International Journal of Ad Hoc andUbiquitous Computing (IJAHUC), Special issue on The SmartDigital Home, 7(3):145–154, 2011.

[34] F. Kerasiotis, A. Prayati, C. Antonopoulos, C. Koulamas, andG. Papadopoulos. Battery Lifetime Prediction Model for aWSN Platform. In Proceedings of the Fourth InternationalConference on Sensor Technologies and Applications (SEN-SORCOMM), pages 525–530, Mestre, Italy, July 2010. CPS.

[35] Y. Kim, T. Schmid, Z. M. Charbiwala, and M. B. Srivas-tava. ViridiScope: design and implementation of a fine grainedpower monitoring system for homes. In Proceedings of the11th International Conference on Ubiquitous Computing (Ubi-comp), pages 245–254, Orlando, Florida, USA, September2009. ACM.

[36] T. Kindberg, J. Barton, J. Morgan, G. Becker, D. Caswell, andP. Debaty. People, places, things: web presence for the realworld. Mobile Networks and Applications, 7(5):365–376, Oc-tober 2002.

[37] M. Kovatsch, M. Weiss, and D. Guinard. Embedding InternetTechnology for Home Automation. In Proceedings of the 15thConference on Emerging Technologies and Factory Automa-tion (ETFA), Bilbao, Spain, September 2010. IEEE.

[38] A. Marchiori and Q. Han. Using Circuit-Level Power Mea-surements in Household Energy Management Systems. InFirst Workshop On Embedded Sensing Systems For Energy-Efficiency In Buildings (BuildSys), Berkeley, California, USA,November 2009. ACM.

[39] B. Ostermaier, K. Roemer, F. Mattern, and M. Fahrmair. AReal-Time Search Engine for the Web of Things. In Proceed-ings of the Second International Conference on the Internet ofThings (IoT), Tokyo, Japan, December 2010.

[40] J. Polastre, R. Szewczyk, and D. Culler. Telos: enabling ultra-low power wireless research. In Proceedings of the Fourth In-ternational Symposium on Information Processing in SensorNetworks (IPSN), Los Angeles, California, USA, April 2005.IEEE Press.

[41] N. B. Priyantha, A. Kansal, M. Goraczko, and F. Zhao. Tinyweb services: design and implementation of interoperable andevolvable sensor networks. In Proceedings of the Sixth Con-ference on Embedded Network Sensor Systems (SenSys), pages253–266, Raleigh, NC, USA, November 2008. ACM.

[42] W. F. V. Raaij and T. M. M. Verhallen. A behavioral modelof residential energy use. Journal of Economic Psychology,3(1):39–63, 1983.

[43] L. Schor, P. Sommer, and R. Wattenhofer. Towards a Zero-Configuration Wireless Sensor Network Architecture for SmartBuildings. In First Workshop On Embedded Sensing SystemsFor Energy-Efficiency In Buildings (BuildSys), Berkeley, Cali-fornia, USA, November 2009. ACM.

[44] P. Schramm, E. Naroska, P. Resch, J. Platte, and H. Linde. Aservice gateway for networked sensor systems. IEEE PervasiveComputing, 3(1):66–74, January 2004.

[45] Z. Shelby, K. Hartke, C. Bormann, and B. Frank. ConstrainedApplication Protocol (CoAP), March 2012. IETF Draft, draft-ietf-core-coap-09.

[46] B. L. Titzer, D. K. Lee, and J. Palsberg. Avrora: scalable sensornetwork simulation with precise timing. In Proceedings of theFourth International Symposium on Information Processing inSensor Networks (IPSN), Los Angeles, California, USA, April2005. IEEE Press.

[47] B. Traversat, M. Abdelaziz, D. Doolin, M. Duigou, J.-C.Hugly, and E. Pouyoul. Project JXTA-C: enabling a Web ofthings. Big Island, Hawaii, USA, January 2003. IEEE Com-puter Society.

[48] V. Trifa, D. Guinard, V. Davidovski, A. Kamilaris, andI. Delchev. Web messaging for open and scalable distributedsensing applications. In Proceedings of the 10th InternationalConference on Web Engineering (ICWE), pages 129–143, Vi-enna, Austria, July 2010. Springer Verlag.

[49] E. Wilde. Putting things to REST. Technical Report UCBiSchool Report 2007-015, School of Information, UC Berke-ley, November 2007.

[50] D. Yazar and A. Dunkels. Efficient Application Integrationin IP-based Sensor Networks. In First Workshop On Em-bedded Sensing Systems For Energy-Efficiency In Buildings(BuildSys), Berkeley, California, November 2009. ACM.

[51] L. Yeh, Y. Wang, and Y. Tseng. iPower: an energy conservationsystem for intelligent buildings by wireless sensor networks.International Journal of Sensor Networks, 5(1):1–10, 2009.

Journal of Ambient Intelligence and Smart Environments 4 (2012)...

Documents

Transcript of Journal of Ambient Intelligence and Smart Environments 4 (2012)...