Monitoring Energy Efﬁciency in Buildings with Wireless Sensor Networks: NRG-WiSe Building

on


Introduction
Over the last decades the economic growth has steadily increased the demand for energy, but "without a change in policy, the world is on a path for a rise in global temperature of up to 6 o C, with catastrophic consequences for our climate" International Energy Agency (2009). This is an important issue presented in the World Energy Outlook 2009 of the International Energy Agency (IEA) in which are treated a lot of reasons leading global energy development is unsustainable. This mentioned change in policy implies a world wide common position and a very high economic cost which will be offset by health and energy-security benefits, so it is worth the economic cost. For that reason in this regard have been made some efforts.
At present, the economic and financial crisis is producing the first fall in the global energy use since 1981. This fact, that could be seen as producing a positive effect on the future energy scenario, has in fact harmful consequences. As the IEA indicates International Energy Agency (2009), energy investment shows a decadent tendency during the last years, thus slowing the development of new efficient resources and technologies. This decrease is even more patent in renewable power generation, which is expected by the IEA to drop to 20%. Thus, the financial and economic crisis is threatening the achievement of medium term goals in energy consumption and emissions reduction.
Regardless this temporary situation, predictions indicate (International Energy Agency (2009)) that energy demand to be growing again in the Reference Scenario, reaching in 2030 a 40% higher than in 2007, assuming no changes in direction of the present policies. This increase is mainly due to non-OECD countries, in particular China and India, which will show a 53% raise in their energy consumption from 2007 to 2030.

Energy efficiency in buildings
All this situation motivates the need for focus on the energy efficiency, a concept with increasing significance and that is playing an important role in current energy-saving scenario since encompass energy saving but keeping (or rising) levels of service, productivity, comfort, etc (depending on scope). Some definitions of energy efficiency in buildings can be found in Directive 2002/91/EC of the European Parliament and of the Council of 16 December 2002 on the energy performance of buildings (n.d.), Directive 2010/31/EU of the European Parliament and of the Council of 19 May 2010 on the energy performance of buildings (recast) (n.d.), Real Decreto 47/2007, de 19 de enero, por el que se aprueba el Procedimiento básico para la certificación de eficiencia energética de edificios de nueva construcción (n.d.) and Pérez Lombard et al. (2009), but all these can be summarized in: consuming less energy while providing equal or improved building services.
As it is apparent from many independent studies ('UNEP (2007), Directive 2010/31/EU of the European Parliament and of the Council of 19 May 2010 on the energy performance of buildings (recast) (n.d.) and Pérez Lombard et al. (2009)) the building sector is a key sector for sustainable development and is responsible of almost 40% of total energy consumption. Buildings include a huge set of variables related to energy consumption. Construction materials, HVAC systems, geographical location and orientation, and even use, maintenance and operation are important issues to be taken into account to reach important energy savings and emissions reductions. A great range of policies can be developed associated with any individual variable or the complete set taken as a whole.
One of these policies is the Directive 2010/31/EU of the European Parliament and of the Council of 19 May 2010 on the energy performance of buildings (recast) (n.d.), which aims to promote the energy efficiency in buildings. To implement this directive, an energy certification of buildings must be performed. However, at present there is no common or standardized procedure to come up with this certification. The EPBD states the foundation of the energy certification of new and existing buildings through a common methodology to be implemented by every Member State. Calculation must be performed in new buildings and in existing buildings that are subject to major renovation. These buildings must be energy certified to asses their performance in terms of their efficiency. In addition, the EPBD states the need to implement regular inspections of boilers and air-conditioning systems in buildings.
A theoretical research of Meyers et al. (2010), mainly based on Residential Energy Consumption Survey (RECS) from US Department of Energy (US Department of Energy (2001) and US Department of Energy (2005)) and applied to homes, shows that a great deal of energy is wasted in delivering services inefficiently to residents such as heating or cooling unoccupied spaces, overheating/undercooling for whole-house comfort, leakage current, and inefficient appliances. The result of their initial estimate is that over 39% of residential primary energy is wasted.
So,the economic cost of these in situ measurements may be high but it will be offset by a needed reduction of consumption of non-renewable sources of energy.

WSN and energy efficiency in buildings
Considering the importance of continuous monitoring of power energy parameters of buildings, WSN arise as a feasible solution to reach this continuous monitoring in order to evaluate inefficient energy consumption. However, the nature of the events that lead to energy inefficiency results, impacts on the scalability and performance of operation of the WSN. Taking this limitations into account, it is needed a proposal of a framework for the design and operation of a dense Wireless Sensor Network to detect the inefficient energy consumption in buildings and to gather enough data to improve current procedures to evaluate energy efficiency in buildings. This proposal can be more or less detailed depending on the accuracy level but it has to take into account aspects as important as topology, reliable communication, processing and algorithms of decision.
Energy Efficiency in Communications and Networks www.intechopen.com Jiang et al. (2009a) and Jiang et al. (2009b), WSN are used in order to analyze energy consumption in buildings. This is another approach very different from software engines for energy certification. In both works authors center attention on how to measure AC power consumption using a WSN and how to analyze all gathered measurements. Jiang et al. (2009b) describe the design, deployment, and experience with a Wireless Sensor Network for high-fidelity monitoring of electrical usage in buildings. A network of 38 mote-class AC meters, 6 light sensors, and 1 vibration sensor is used to determine and audit the energy envelope of an active laboratory. Meyers et al. (2010) do take into account energy use in unoccupied/occupied spaces showing that about 20% of energy is wasted . On the other hand, they consider that wireless sensors are ideal in monitoring as they are easier to install, maintain and replace than wired sensors. Besides, newer sensor technology is capable of performing its own processing without need for a central decision-making hub, opening up possibilities for ad hoc networks for self-organization and control home systems. de la Campa et al. (2011) propose a scalable framework for distributed detection of energetically inefficient events in buildings using a wireless sensor network. They use the detection of presence in spaces where those events are registered to accurately characterize the energy efficiency of any given building. The theoretical foundations of that work are the basis of the architecture presented here

Motivation of this work
The need for a common measurement and certification tool for the energy efficiency of buildings is apparent. The measurement tool should be flexible, easy to deploy and maintain and it should require little or no previous adaptation to the specific building being measured. Clearly WSNs are specially well suited for this purpose. However, the capability of such network to operate with little or no supervision is hampered by scalability issues, i.e. the huge number of measurement points to cover the relevant variables throughout the building can compromise the integrity of the data being transmitted. So careful design of the architecture of the wireless sensor network is needed in order to suit the need for reliable sensoring, communication, processing, storage and visualization of the parameters that allow the evaluation of the energy efficiency of a building. In this work we present the NRG-WiSe Building (Network Reliant GIS, Wireless Sensor Building) architecture, a purpose-built system for effective retrieval, processing and visualization of measurements of energy consumption-related parameters in a building.
This architecture is built to be scalable (its performance is not to be hampered by the number of sensor or gateway nodes)Not only we present the architecture but an effective implementation using commercial off-the-shelf equipment (wireless nodes and gateway-boards). However, the NRG-WiSe Building architecture is not limited to the use of such commercial equipment. It is a universal architecture and it can be used with a variety of already available hardware.

Structure of this work
In Section 2 we overview the general structure of the NRG-WiSe Building architecture, presenting the different modules and interfaces connecting them. In Section 3 we present the Sensing Module responsible of the interaction of the sensor and gateway nodes, along with Interfaces I1 (routing protocol) and I2 (interaction of the sensing module with the management module). In Section 4 we proceed to explain the Management Module which allows the (either periodic or event-driven) retrieval of sensed data as well as control of the sensor nodes. Interfaces I2 (description of the interaction with the sensor nodes), I3 (inter-gateway communications), I4 (management decisions), I5 (reception of order from the visualization module) and I6 (transmission of orders to the visualization module) as well as the interaction between interfaces are presented. In Section 5 we present the Visualization Module, responsible for the representation of retrieved data and interaction with the user. Interface I6 (periodic communication with the management module) is presented. Finally, in Section 6 we present the Conclusions and further work to be done. The system comprises three distinct modules: sensing, management and visualisation. In Figure 1 it is shown a general outline of the entire system. Devices that are observed are the three modules and the connections between them. These connections are represented by broken lines in the case of a wireless communication by straight if it is a communication via wired connection. Adjacent to each connection is the name given to the interface between two devices, such as all communications between devices that are used sensing module interface I1. In subsequent sections the three modules are explained in detail, along with the devices and interfaces in the system that make them up.

Sensing module
This module is responsible for collecting the data provided by sensors and transmitted to the next module, the management. The measured variables are: • Temperature. It uses an analog sensor provides a voltage proportional to the measured temperature. The relationship between temperature and output voltage is linear. • Brightness. In this case, choose a resistive sensor whose conductivity varies linearly as a function of the intensity of light received. • Presence. The aim is to detect the presence of people within the facility. We choose a PIR sensor (Passive Infra-Red) working in the spectrum of heat radiation of mammals. • Open/close passages. It uses a Hall effect sensor to detect the opening of doors and windows of the facility. This parameter, along with former, it is especially important for the safety of the building, since it allows to detect unauthorized intrusions.
These sensors are integrated into the system through the "Event Board" which provides the company Libelium Libelium (n.d.b). This board allows simultaneous connection of multiple sensors of different types. Because you can connect up to eight sensors on the board and that this project uses only four in the future may increase the rate monitored variables. The board connects to the events "Waspmote" manufactured by Libelium. This device consists of an ATmega1281 microcontroller and enables the connection of different communication modules. In this project we use the module 802.15.4 XBee-company Digi.I n Figure 2 it is shown the device used to sense with all its components: sensors, events board, communication module, XBee 802.15.4, battery, SD card and Waspmote device Libelium (n.d.a). Through the red dotted lines represent the connections are between the different elements. The complete system consists of multiple Waspmote with the same structure as that shown in Figure 2. All values measured at each Waspmote must reach the management module and to this end, we define the communications interface I1 between the different devices that make up this module. This interface has all the necessary messages to the routing protocol used, also defined during the development of this project. The interface I1 is used by Waspmote to communicate between them. This interface is used by the routing protocol used in this system and its main feature is that it is hierarchical. It defines three roles a Waspmote can take:

I1 interface. Routing protocol
• Main gateway. Devices that fulfill this role are at the top of the hierarchy and have direct communication with the management module. • Secondary gateway. In this case, the devices are gateways for other devices of equal or lower rank, but do not have a direct connection with the management module. To carry out its functionality needs to connect to another gateway, either principal or secondary. Ultimately, at least one secondary gateway must be connected to a main. • End node. Devices are the lowest in the hierarchy. For its operation you need a network with a gateway.
In Figure 3 you can see an outline of the hierarchy are devices with different roles in this module. Thereafter, the devices that connect to a gateway will be called "children" and gateways that accept the connection is known as "parents" of such children, following the nomenclature used in object-oriented programming. A secondary runway is both father (with respect to Waspmote that connect to it) and son (with respect to the gateway that connects with itself). Because Waspmote have a memory limitation, fix the maximum number children each gateway can have eight of each type, ie type eight children and eight children secondary runway type end node. However, eight children are secondary gateways can in turn have children of both types, making this fact does not imply any limitation for the entire system.
The interface messages have I1 are: •I MALIVE. Message sent by broadcast periodically by all devices, regardless of the role they have. In Figure 4 represents the structure of this type of message. The field Type uniquely identifies the package and the P represents the priority of this package, these two fields common to all packages. The flag G indicates whether the Waspmote in question is an end node (G=0 ) or a gateway (G=1 ). To differentiate between the two types of gateways using the flag A that indicates whether the main gateway (A=1 ) or secondary (A=0 ).
The flag R is used to indicate whether a device is searching for parent process (R=1 )or if it has completed this process, it is not necessary to be the Waspmote a main walkway (R =0 ). Finally, the flag F is enabled (F=1 ) indicates that a gateway can receive messages of type FLUSH. •G WREPLY. Message generated by a gateway that receives a message IMALIVE with the flag R=1 . He is sent by unicast to the device that caused the generation of this message. In Figure 5 can observe the structure of this type of package. •G WACK. Waspmote message sent by a father looking after having received at least one message of type GWREPLY. It is used to inform a specific gateway that from receipt of this message has a new son. The structure of this message is represented in Figure 6. •G WASSIGN. This type of message is used to change the role of an end-node device is a secondary gateway. He is sent by Waspmote unicast to the role that will change. In Figure 7 represents the structure of these messages. •G WACCEPT. Message sent in response to confirm receipt of a GWASSIGN and its structure is depicted in Figure 8. •B UNDLEREQ. This type of message is used to explicitly request any data Waspmote sensors. Its structure is shown in Figure 9. The field NMV is used to indicate the number of fields VIA MAC that follow. For its part, the fields VIA MAC are the way you have to keep this package to reach the device recipient of this message. This recipient is not included in the fields VIA MAC, but his ID is in the SENS MAC. Both the VIA MAC as SENS MAC is a unique identifier in the system Waspmote and are formed by the last three bytes of the MAC address of the communications module 802.15.4 XBee-each device. If a Waspmote receives this message and have to resend it takes care of removing the identifier VIA MAC upgrade package and the NMV. •B UNDLEREP. Main message of the system responsible for transmitting to the management system data collected from the sensors. In Figure 10 shows the scheme of this type of message. As for the fields has not yet explained, the PL indicates the number of bytes transmitted in this packet, including header. The flags indicated in capital letters refer to the last device that have gone through, while the flags indicated in lowercase letters refer to the device that generated this message. The six fields TS are the time stamp when the measurements have been traveling on this package. Fields TV [i] are only indicative of the type of sensor that has been measured, the value appears in the V [i] follows. For this message, each gateway that receives and forwards it adds a new field VIA MAC and updates the field NMV. •F LUSH. A message containing one or more messages of type BUNDLEREP complete.
Through these messages, a gateway that has had a temporary problem to her father is sending the messages Bundlerep has been stored on the SD card available to Waspmote. In Figure 11 represents the structure of this type of message. The field nb indicating the number of messages BUNDLEREP complete that are transmitted in this packet.  •G WDELETE. Message sent by a gateway when it receives a message type BUNDLEREP a device that is not his child. When a device receives this message (represented in Figure  12), restart the process of finding a father. Once known the structure of all the messages used, it is necessary to comment that they do not have the same priority when being sent and the time to be served by the Waspmote that it has received. Table 1 indicates the priority of each message, taking into account the priority 0 is the highest and the 3 is the lowest.

Interface I2. Management module communication
As in the previous case, for the use of the interface I2, we have defined a communication protocol. In Figure 1 shows that only certain Waspmote have communication with the management module. These Waspmote fulfill the role of main walkway and connected via the serial port of the aforementioned devices module. The messages are available for this interface are: •W GWASSIGN. This message has the same functionality as the message GWASSIGN THE INTERFACE I1, ie, changing the role of Waspmote recipient. In this case the device becomes the main gateway. Its structure is identical to the message of type GWASSIGN and can be seen in Figure 13. •W GWACCEPT. In this case, as in the previous one, this type of message has the same functionality as the namesake of his in the interface I1, but its structure (see Figure 14) changes slightly. The two new fields are the last two bytes of the address own MAC and used to create unique identifiers in the management module. •W BUNDLEREQ. This message has the same functionality and the message structure of type BUNDLEREQ. When a Waspmote receive such messages and is not directed to itself simply forwarded by the interface I1. The message structure is shown in Figure 15. •W BUNDLEREP. Again, it has the same functionality and structure (see Figure 16) that the message of type BUNDLEREP. In this case the primary gateway is simple bridge between the interface interface I1 and I2. •W FLUSH. The representation of this type of message is done in Figure 17 and we can see that is almost identical to the structure of the messages FLUSH. This difference is due to the standardization of nomenclature, since the messages BUNDLEREP and WBUNDLEREP are identical. Also identical are the messages FLUSH and WFLUSH.
Following the similarities with the interface I1, the messages presented in the above lines do not have the same priority when being sent to the management system or the time to be served by the Waspmote. It should be mentioned that the interface messages I2 share priority structures with interface messages I1. Therefore, if a message is processed with  higher priority, regardless of the interface to which it belongs . Table 2 indicates the priority of each message. Table 2. Message priority in Interface I2.

Interaction between interfaces
In order to improve understanding of the logic are the devices that make this module, flow charts represent the following three types of Waspmote in Figures 18, 19 and 20. Specifically, the first of them represents a flow diagram which fulfils the role Waspmote end node in the second case shows the role of the secondary runway and, finally, the third represents the case of main gateway role. For a better understanding is necessary to explain the symbology of flowsheets represented. First, the rectangles represent different actions. There are two colors, yellow identifies the actions related to the interface I1, while blue is used for actions related to the interface I2. The circles are used to indicate "points" in the code the program does output to multiple actions. The red hexagon labeled "Stop" means the changing role of the Waspmote other, thus changing the flow chart to follow when possible actions to take. In terms of transitions between actions using arrows. A is attached "Periodic" and use the blue to indicate that the actions are performed periodically.

Management module
The management module is the standard software that transforms the raw data from the sensing hardware to software page for the presentation of the display module. Following the View-Controller programming model but applied to a complex system, the management Fig. 18. Flow chart of a node with end node role. Fig. 19. Flow chart of a node with secondary gateway role. module itself would be the system controller, which does not exempt himself from having his own data presentation software for the administrator the network.
The management module objectives are: • Perform monitoring and management of the network intercom ALIX Engines (n.d.) boards together by SNMP. • Store information collected by the sensor network that connects ALIX to each plate. • Establish and launch alarms required by the user from the display module.
• Send commands acting on the sensor network. • To receive, interpret and manage the orders of the display module.
• Submit the information display module to be represented.  The management module architecture is shown in Figure 21. It consists of the following elements: • Apache Web server. The web portal is the system chosen for the interaction of the network administrator. For a network administrator, the management server already contains everything you need to detect network problems before they occur or have occurred, and perform preventive maintenance and corrective. For this reason, information from the network management server does not need to be integrated into the display module, which is oriented to the visualization of data sensing. Since the interaction between network administrator and server management is done from a web interface, Apache is the foundation of the web portal administration. • Nagios Server network management. Mounted on the Nagios Nagios (n.d.) server Apache allows to separate the management of the backbone that supports the sensor network for managing sensing information, enabling you to plan upgrades and maintenance of the network in advance, so affecting as little as possible to services it provides. In a broad sense, it can be considered to the display module as a plugin to integrate monitoring and management of buildings in Nagios, but the separation is so great, that formally it is not. Management information is viewed by network specialist with disabilities who display the information on what is happening in a building, while the process of acquiring information and responding to alerts is similar. That is why Nagios is used not only for network management, but also to make the process of data acquisition and control alerts. To understand this better, we could say that you could use Nagios to represent the information associated with the operation of the sensing hardware, what settings have IEEE802.15.4 IEEE (n.d.b) Digi radios, or what speed is set the serial port between ALIX and Waspmote. The professional who will go to the website for this information will keep in mind that should foresee bottlenecks in the network, or interference associated with the use of certain frequencies in wireless transmission, but when it comes to room temperature, measured with the hardware , the network administrator who can not say how they are performing heat transfer between rooms or how to interpret the values ??present in each room. Apart from monitoring the technical components that make up the system from the point of view of the protocols, servers, applications and network infrastructure, Nagios is also responsible for alerting the values ??stored in their databases, which includes alerts the values ??measured by the sensing module. • Nagios Plugins intercom with display module. In this system, two plugins are built on Nagios. The mission of these plugins is interfacing with the display module and, in fact, each plugin corresponds to a system interface (I5 and I6). The plugin for receipt of orders of the display module, which implements the interface I5, takes place, controlled by XML-RPC Foundation (n.d.a) requests: -Communication with OpenLayers Openlayers (n.d.) and Open Flash Chart Chart (n.d.), receiving such requests for information and translating them to messages snmpget.
-The establishment of internal alerts in Nagios.
-The message generation snmpset to the ALIX boards, in order to translate these messages into the sensor network. The plugin for communication of information to the display module, which implements the interface I6, sends them through XML-RPC response, the requested data to Nagios to represent the maps and graphs that allow the display of information sensing . • ALIX Serial Port communication daemon. This daemon, which runs on the operating system boards ALIX (voyage distribution of GNU/Linux for embedded systems) Voyage (n.d.). It performs three functions which are essential for communication between the management module and the sensing module: it manages and operates the serial port on the ALIX boards, to enable communication between ALIX and Waspmote gateway.
it interprets the commands received from the sensor network, translating them into SNMP messages.
it interprets the messages received from the server SNMP management protocol messages translating a network of sensors. • Daemon SNMPTRAP message reception. In the management server, resides a demon in charge of listening to any type messages generated from SNMPTRAP ALIX boards. The meaning of these messages is that the sensor network and the plates themselves ALIX can send urgent messages or associated with events that can not wait to be consulted by snmpget.
• Database MySQL sensing buffering. In order to distribute the management traffic properly and that its intensity can be controlled from the management server with all the information from non-urgent ALIX boards is stored in an intermediate database that acts as a buffer, waiting for snmpget message management server can be answered with this information, and deleted from the database. • Private MIB (Management Information Base) sensing. The introduction of the sensor network as an element to manage, requires the creation of a private MIB IETF (n.d.a), which implements the new items you want to monitor or manage. Because you can not enter directly managing sensor motes, since it would oblige them to implement SNMP protocol (and there are devices with processing power and limited storage), their management is done indirectly directed by ALIX boards. Thus, the sensing information MIB is implemented in ALIX boards, and is known by the management server. When you need to retrieve information in a sensor network, the management server asks for your object in the MIB to the ALIX board, and this is a gateway to the sensor network, and translate that request to the protocol of the sensor network if it does not already have the required information in its buffer.

Interface I2. Sensing module communications
For communication with the sensing module, the management module interface uses I2. This interface is implemented from the management side of the module by a demon living in the ALIX board, which is the communication daemon ALIX serial port, as explained in the previous section.

Interface I3. Inter-gateway communications
Communication between ALIX boards is performed using the system interconnection model TCP / IP, and involves essentially the following protocols: • IEEE802.11a IEEE (n.d.a), to the extent of quality of service (QoS footnote Quality of Service) 802.11e IEEE (n.d.a). This is the network layer protocol stack and is responsible for carrying information between 2 machines. IEEE802.11a is a wireless communication protocol and uses OFDM modulation to provide bit rates of 54Mbps at the physical level, which often result in at rates up to 28Mbps IP with optimal transmission conditions. The working frequency band of 5GHz is, and therefore generally exempt from most of the interference from other devices inside a building (which used to be located in the 2.4 GHz). • IP. For communication between ALIX, and the rest of the system, Internet Protocol Version 4 is in use, because it is the most widespread protocol interred in virtually all types of computer networks worldwide. • OLSR (Optimized Link State Routing). For the auto-routing between ALIX boards used OLSR IETF (n.d.b) with ETX metric to look at the specifics of routing over wireless networks, where sometimes a greater number of network hops does not imply a worse way, if the conditions of the links are better than the path of least number of hops between.

Interface I4. Management decisions
Communication between ALIX and the management server is based on the same protocols as the interface I3, but with the addition of also using network management protocol SNMP (Simple Network Management Protocol). To query SNMP MIB need to exist to define the objects that has to ask, and similarly, there needs to exist side management agents managed elements to implement the form in which has to recover the value of each object queried. For ALIX boards, the standard MIB information on the various components of the system and the network between ALIX (CPU load, available memory, signal level on the links, etc), add the definition a MIB own recovery sensing information. This MIB resides in the ALIX boards and the management server, and is implemented by ALIX boards.
Specifically, SNMP messages used in the inter-ALIX -Nagios are: • snmpget -Used to retrieve the newspaper sensing data have been properly stored temporarily in a MySQL MySQL (n.d.) database on ALIX boards. • SNMPresponse -The ALIX boards used to return the values ??requested by the management server. • snmpset -are sent from the management server ALIX boards, and serve both to alter values ??set in the various elements managed ALIX boards, to implement actuators of the sensor network. Can also be used to set up alerts monitored by sensors. • SNMPTRAP -SNMP messages are sent from ALIX boards to inform, without prior request from the management server, urgent information associated with events. Usually used for transmitting high priority messages and sensors whose values ??are not important, but the events that arise from the transition of its states. For example, in the case of Hall effect sensors, it makes more sense to report on the opening or closing a window or door, to report periodically to the window or door is open or closed. Server-side management, a demon is responsible for hearing such messages and integrate the information received it with the rest of the information management platform.

Interface I5. Reception of orders from visualization module
In the management server there is a plugin developed to meet the receive orders from the display module, usually expressly ordered by end-users of the system. Communication between management and display modules is performed using the protocol for remote procedure call XML-RPC. Specifically, the interface I5, queries involving XML-RPC that are made from the display module. However, this plugin is detailed further in the next section.

Interface I6. Sending information towards visualization module
To respond to XML-RPC queries made?by the display module, also implemented a Nagios plugin that performs the necessary tasks in the interface I6. The main task is to gather the information management server to respond to XML-RPC queries to generate the answers to those queries, and send them to the parts of the display module that required information through the interface I5 . In the next section provides more detail of this Nagios plugin.

Interaction between interfaces
In Figure 22 it is shown the message exchange that occurs in the management module when there are periodic measurements.
We can summarize the sequence as follows: network management server and Nagios. Remain there until the server ask for that information management. 4. The management server periodically collects information via snmpget requests. 5. The management agent ALIX board, upon receiving a request snmpget, look at the private MIB of sensors, and notes that to retrieve the requested information, you have to access the database sensing buffering, so making the query to the database. 6. The DB responds with the requested data. 7. Since the data will be sent to Nagios, are deleted from the DB of ALIX. 8. The management agent responds to snmpget with information from the DB in an SNMP response. 9. Nagios stores the information received at its own DB. 10. (optional). If any of the values ??exceeds some threshold, the administrator is alerted.
In Figure 23 it is shown the message exchange that occurs when an event occurs in the sensor network. The sequence is as follows: 1. An event occurs (for example, a door is opened), and this translates to a message that reaches WBundleRep ALIX board. 2. The communication daemon ALIX serial port recognizes the message as an event that must be transmitted immediately and not stored in the intermediate buffer, so it generates a message to the server SNMPTRAP Nagios. 3. The snmptrapd daemon, which manages the reception of SNMPTRAP messages on UDP port 162, it receives the trap and resends it to Nagios, which makes storage in its own DB. 4. If applicable, it generates an alert to the administrator.

Visualization module
The Visualization module has two main objectives: • Provide information to the user. • Manage the interaction system ↔ user.
To complement this functionality, the module must retrieve information from the sensing module, processed by the management module, and provide additional processing to provide the user with useful information. Therefore, sensing and communication between users is not done directly but always through the management module.
The display module architecture is detailed in Figure 24. For the presentation of information, given that the scenario is the energy efficiency in buildings, uses two visualization schemes: • A map-based display vector layers navigable semitransparent overlays. Thus, the user has real time and at a single glance, general information on all variables measured in the building shown on the same plane ( Figure 25). • A graphics-based visualization. With this display you can analyze historical sensor on each node, making comparisons between various graphics, easily detecting events in the securities, as well as the establishment of specific alerts when values ??are generated above or below certain thresholds ( Figure 26). To function, the display module makes use of:  Apache (n.d.). The web information is presented as this is the route that offers more independence from the user terminal and the rest of the system. It has a web server as a gateway to the system of maps WFS (Web Feature Server) and WMS (Web Map Server) defined by the OGC (Open Geospatial Consortium) OpenGIS (n.d.), as well as other web server (which may optionally be the same) that serves the interaction interface with the user. It is therefore of the first layer, which manages software involved in the system (HTTP communication). • Drupal CMS (Content Management System) . On the Apache server that serves the graphical interface, install the Drupal Drupal (n.d.) CMS, which facilitates the creation of the interface. Due to its size and broad support from the community of free software, allows in the future to extend its functionality. The content management system brings to the construction of the web portal of information around what is not displaying maps or charts. Manages issues of different nature and importance of graphic design ranging from the portal (font, structure, headers and footers, links, etc.) to manage access rights to information (roles), authentication, connection to databases, and so on. By way of analogy, we might say that while Apache would be the foundation and the building facade, Drupal is the circuitry, the air conditioning system, alarm, lighting, plumbing and everything that makes a building can provide generic services without going into detail on what type of service provided by the building. • Mapserver map server. Using Apache to support geographic information subsystem, is constituted as Mapserver Foundation (n.d.b) WMS and WFS, distributing the graphical interface maps and plans on which information is represented. Figure 27 shows the internal architecture of Mapserver. Mapserver as WMS and WFS uses the information stored as raster and vector data to compose a final image that maps customer service. Raster data are satellite maps and aerial photos free, which serve as base layer above them, capture dynamic information graphically. Vector data are an ordered set of points, lines and polygons that occur in layers on raster images. Thus, from an appropriate zoom level map on a building, it will overlap the layer that represents the plane of the top floor of the building, with the option to enable or disable semitransparent layers that represent information associated with this floor. For example, if you want to graphically represent the temperature in the rooms on the top floor of a building, a raster layer is a layer superimposed lines and polygons representing the plane of the floor of the building, and on this, be presented another layer of semitransparent polygons whose color will vary depending on temperature values ??being measured in each room instantly. When the user increases the zoom sufficiently, the layers that represent the information on the top floor disappear and appear to represent the penultimate floor, and so on up through all the floors. • Client Openlayers maps. Integrated as a module in Drupal, for viewing the maps, mapping the client uses WMC (Web Map Client) Openlayers, which generally consists of a JavaScript library that facilitates the integration of maps and layers loaded from different sources into a web page.
In the display of maps of the information could be used only Mapserver, but to integrate the functionality of Mapserver on a website that offers many more services than the representation of maps using OpenLayers. Openlayers provides maps in addition to the navigability and the layer of user interaction. For example, is responsible for the Time Travel " tool"that occurs in the software. This tool enables " time travel"back on the map representing the graphical information not only of what is sensing in real time in the building, but to represent the state of the building at any moment ago he was being sensed. The management module is stored all this information, and therefore Openlayers is responsible for providing the user with an interface as simple as a scroll bar, which, however, translated into the appropriate messages between the management module and the display to to recover the information associated with a particular time of historic building and is represented in vector layers superimposed on the map Mapserver. Openlayers is also responsible for the " Filters"tool on the maps, which allows the application to graphical information represented filters that make it more specific, such as vector layers represent colors that show only the temperature of those rooms on not detected the presence and the luminosity exceeds a certain threshold (to detect, for example, lights on unnecessarily). By managing the translation of user gestures to messages in the system, Openlayers also be responsible for the shutdown command of these lights on in vain. • Open Flash Chart Interactive Graphics. Charts configured within Drupal module allows the user to interact with the graphics, view historical comparisons and identify alarms in the system. To view system information using a different paradigm different from the representation of data, the system supports graphical visualization thanks to Open Flash Chart. Its functionality is equivalent to Openlayers, in the sense that it allows actions like this, but to present information differently, the system adapts better to the type of user. While there is more intuitive actions performed on a map of the building, such as monitoring the condition of the building, others may find it easier to see them on graphs. For example, the equivalent of " Tool Time"in the travel map display is the X axis of the graphs, since the values ??are plotted versus time, and this makes while with " Time Travel "is easy to see global temperature transitions of a building and the heat flows that occur throughout the day on a graph is easily detected high, low, medium and value comparisons. Open Flash Chart is communicated through the same API that the plugin Openlayers management server that receives orders visualization software.

Interface I5. User-sensor interaction
Interface I5 is responsible for generating the corresponding messages in the management modules and sensing when a user determines the performance of an action or instant retrieval of information. It is one of the two interfaces that connect the management module to the display module and involves a management plugin Nagios server, which receives the user's request, and the library OpenLayers, or the Open Flash Chart software on the side display module, who are mandated generate the user's request. When a user interacts with a map served by Openlayers, and this interaction requires retrieval of information or sending message to the management module or the sensing module automatically generates the request to the plugin management module, and also occurs when the interaction is via a graphical served by Open Flash Chart.
You may order several actions by any of the modes: • Instant retrieval of data. It results in an application to the management module to a snmpget ALIX boards and recovery of the last values measured for each sensor. This is a direct interaction between user and management module, as in response to user action, several messages are exchanged between the display and management modules.
In practice it is a refresh button to display the images used to test at a time when network problems arise. If the soda works, it means that the whole chain of intermediate software layer protocols and are doing their jobs. Additionally, it also gives the user knowledge about the latency of the entire system. • Performance. The elements are controlled by actuators connected to the sensors may be activated or deactivated user's express request. This interaction is direct between user and sensor (or actuator), since in response to user action, a number of messages generated in the display module, management module cross and reach the sensing module. Figure 28 represents the chain of messages that occurs in the system when a user decides to send a message of action. The sequence would be the following: 1. The user requests an action through the Drupal CMS, using a chart or map for it (or Open Flash Chart Openlayers). 2. Using XML-RPC request, Openlayers or Open Flash Chart requests the plugin that implements the interface I5 acting. 3. Nagios generates a snmpset message with information from the actuator to activate the sensor location of your partner, who travels to the ALIX board, where the sensing MIB translates the command to snmpset ACTION devil sends his port control series to reach the gateway Waspmote is connected. 4. The ACTION message travels across the network of sensors to the actuator, producing the requested action. Fig. 28. Chain of messages that occurs in the system when a user send an action message.
There are three modes of operation: switching. Based on relays or digital switches, is on or off of the elements on which you want to act. An example might be the ignition of an engine, or the lights without the possibility of graduating the intensity of light. It can be done from the motes sensors used in the project (Waspmote) using plates Libelium distributed by the company for that purpose (Prototyping Boards).
-The analog performance. Granularity based on variable outputs, accurately regulates the voltage delivered to the element on which it acts. An example would be to set the intensity of light from a luminaire with the possibility of graduating the intensity of light emitted. It can be done from the motes -The performance schedule. For more complex elements such as air conditioning, where there are many variables beyond the set on or off a device, or regulation of the intensity of current or voltage at one point, the system foresees the creation of plugins in the management software to interact with them. Thus, the display module present a common API (Application Programming Interface) action would implement different modules programmed in software management mode drivers for performance against each type of complex. • Setting Alarms. You may want to measure thresholds are exceeded alarms when higher or lower. Alarms can generate informational messages to the user, or may have associated actions. The alarm information on the user side leave the decision about what action to take, while the performance alarms generate automatic messages to the sensing module and activate / deactivate an actuator without further user intervention. Alarms can be set at two different levels: managed by the sensor alarms. These alarms have only the information of the sensor, and are generated by it. Its use reduces the network load when not needed more information than can provide a sensor itself, distributing the processing load of the alarms. As an example, imagine a Hall effect sensor on a door. Because all the information about the opening of the door is contained in the sensor itself does not make sense to generate unnecessary messages between modules. Additionally, because the door opening is a discrete event (the door goes from open to closed state or vice versa) does not make sense to report the status of the door or window, but rather the transition, and therefore the self-reporting state transition is itself an event alarm.
alarms managed by the management module. These alarms can rely on the information from all sensors. They sense when it is necessary to obtain more than one sensor to generate an alarm. For example, we could determine that because of the location of various sensors in a room temperature results in different measurements, despite being the same room, since the temperature is not uniform throughout the room. However, because the air conditioning system is unique in acting on the system must take into account all measurements (either by establishing an average, weighted differently each measure, etc). In this situation, the alarm must be established by the management module, which knows all sensor measurements.

Interface I6. Periodic communication with management module
The management module periodically collects information from both ALIX boards and the network between them (SNMPgets) as a sensing module (protocol of the sensor network). This information has to be sent to the user interface, and for this task implements the interface I8, which interconnects the management and display modules.
Just like the interface I5 asynchronously receives user commands from the management and/or sensing modules. The interface I6 synchronously returns the information reported by the sensors whose measurement range is periodic, as well as asynchronous communications for events and alarms, or refresh the user requested information.
The fate of the information from the management software can be one of the following (or both): • The vector database that generates the map of Mapserver. To display the map according to the configuration required by the user. • Charts Drupal module. To display a chart with the information required. Figure 29 shows the message exchange that occurs when a user requests information from management module, and how the interface I6 involved in the process. The sequence would be the following: 1. The user opens a chart or map, agreeing with it, through Apache + Drupal, Open Flash Chart or OpenLayers.
2. Open Flash Chart or Openlayers automatically generated XML-RPC request to the plugin I5 of Nagios. 3. Nagios recovers from database data, which then delivered to your plugin I6. 4. Depending on who requested the information, the plugin I6 sends the response XML-RPC or Openlayers Open Flash Char. 5. Drupal via Apache shows the user the chart or map.

Conclusions and future work
We have addressed the problem of developing an architecture for Wireless Sensor Networks which are to be efficient and scalable in the purpose of gathering energy efficiency information in buildings. We have presented a complete description of the NRG-WiSe Building. Although the problem has been addressed recently by other researchers, to the best of the knowledge of the authors, no complete description of such an architecture has been proposed until the present work. With readily available hardware and software tools we have built a functioning architecture for a wireless sensor network that retrieves and presents energy efficiency events in buildings, allows interaction of the user with both the data and the sensor nodes and which performance is not hurt by the number of nodes in the building.
At present, a first instance of the proposed network with over a hundred sensor nodes, each one purporting four different sensors (temperature, light, presence and passage control), is being deployed in Fuenlabrada Campus of the Rey Juan Carlos University. Extensive testing of such network is to take place in order to experimentally validate the architecture presented here, thus providing an invaluable tool, both accurate and easily deployable, for characterization of the energy efficiency of buildings. The topic of "Energy Efficiency in Communications and Networks" attracts growing attention due to economical and environmental reasons. The amount of power consumed by information and communication technologies (ICT) is rapidly increasing, as well as the energy bill of service providers. According to a number of studies, ICT alone is responsible for a percentage which varies from 2% to 10% of the world power consumption. Thus, driving rising cost and sustainability concerns about the energy footprint of the IT infrastructure. Energyefficiency is an aspect that until recently was only considered for battery driven devices. Today we see energyefficiency becoming a pervasive issue that will need to be considered in all technology areas from device technology to systems management. This book is seeking to provide a compilation of novel research contributions on hardware design, architectures, protocols and algorithms that will improve the energy efficiency of communication devices and networks and lead to a more energy proportional technology infrastructure.