EnPROVE Energy consumption prediction with building usage … · 2017. 4. 20. · EnPROVE D5.1...
Transcript of EnPROVE Energy consumption prediction with building usage … · 2017. 4. 20. · EnPROVE D5.1...
FP7-ICT-2009-4-248061
EnPROVE
Energy consumption prediction with building usage measurements for software-based decision support
Instrument: Small or medium-scale focused research project
Thematic Priority: Theme 3 – Information and Communication Technologies
D5.1 WIRELESS SENSOR NETWORK
Due date of deliverable: 31.12.2011
Actual submission date: 30.12.2011
Start date of project: 01.02.2010 Duration: 36 months
Organisation name of lead contractor for this deliverable: CLARITY
Dissemination level: PU
Revision 1.0
EnPROVE D5.1 Wireless Sensor Network
Page 2 of 30
Executive Summary
The objective of EnPROVE is to develop a software model for predicting the energy consumption of a
specific building, with different scenarios implementing energy-efficiency technologies and control
solutions based on actual measured performance and usage data of the building itself. One of the key
hypotheses is that by having adequate data gathered on how a building is used and how it performs, it
is possible to build accurate and specific energy consumption models relevant for prediction of
alternative scenarios.
To achieve this, a reliable and functional Wireless Sensor Network will be designed, implemented, and
deployed in order to measure, acquire and collect selected data on the actual building performance and
usage. This document D5.1 Wireless Sensor Network will address the achievement results completed
in D4.3 and provide an overview and description of what have been achieved in accordance with T5.1
BAU-WSN implementation and T5.2 Buidling performance & usage database. More specifically, it will
focus on the deployment of the implemented Wireless Sensor Network, and on the database designed
and implemented for storage of data collection.
Firstly, we describe the hardware components that have been selected and purchased for network
deployment, which includes multiple types of wireless sensors and EnPROVE gateways. The wireless
sensors are configured and deployed to measure and collect performance usage data such as light,
temperature, humidiy, presence, and electricity. An EnPROVE box is selected and deployed in order for
sensor configuration and data gathering. The current network deployment at CLARITY premise is
demonstrated, where a total number of 35 CLARITY sensors and 23 CSTB sensors are deployed to
measure and acquire building usage data including light level, temperature, people presence and
electricity. These parameters are measured, collected and reported to the EnPROVE gateway.
Second, we focus on the description of the database designed and implemented for the deployed
wireless sensor network. Following the achievements in D4.3, we implement the designed database by
using MySQL, an open-source database management tool to store the collected data. The MySQL
database is then setup, configured and installed on the EnPROVE gateway. More, we implement the
data APIs in Java into the platform to facilitate the data query request from EPDSS. These are the
interface to the auditing result database accessed by the EPDSS.
The Deliverable D5.1 Wireless Sensor Network takes place by the end of M23 while it should be
demonstrated as a prototype, comprising all hardware and software components implemented as a
platform to acquire and collect data on the actual building and performance usage. Thus, we
summarize in this document these contributions in order to give better overview and understanding of
what have been achieved to T5.1 BAU-WSN implementation and T5.2 Buidling performance & usage
database.
EnPROVE D5.1 Wireless Sensor Network
Page 3 of 30
Abbreviations
BAU Building Usage and Performance Auditing
D Deliverable
e.g. exempli gratia = for example
EC European Commission
etc. et cetera
i.e. id est = that is to say
ICT Information and Communications Technologies
EnPROVE Energy consumption prediction with building usage measurements for software-based decision support
EPDSS EnPROVE prediction and decision support engine
M Month
MS Milestone
QoS Quality of Service
RTD Research and Technological Development
S&T Scientific & Technological
STREP Small or medium-scale focused research project
w.r.t. With respect to
WP Work package
WSN Wireless Sensor Network
EnPROVE D5.1 Wireless Sensor Network
Page 4 of 30
Contents
1. Introduction .............................................................................................................................. 5
2. Deployment of Wireless Sensor Network ................................................................................. 6
2.1 Wireless sensor component .............................................................................................. 6
2.1.1 Brightness and lights usage ....................................................................................... 6
2.1.2 Presence detection .................................................................................................... 7
2.1.3 Doors, windows and blinds usage .............................................................................. 8
2.1.4 Electricity consumption .............................................................................................. 8
2.1.5 Temperature .............................................................................................................. 9
2.2 EnPROVE Gateway .......................................................................................................... 9
2.2.1 HAL Specifications ................................................................................................... 10
2.2.2 Application Components .......................................................................................... 10
2.2.3 Communication with the remote EnPROVE platform ............................................... 11
2.2.4 Hardware ................................................................................................................. 11
2.3 Network Deployment....................................................................................................... 11
2.3.1 Location ................................................................................................................... 11
2.3.2 Deployment map ...................................................................................................... 13
3. Wireless Sensor Network Database ....................................................................................... 15
3.1 Design ............................................................................................................................ 15
3.2 Implementation ............................................................................................................... 17
4. Conclusion ............................................................................................................................. 30
EnPROVE D5.1 Wireless Sensor Network
Page 5 of 30
1. Introduction
The Deliverable D5.1 Wireless Sensor Network, as being implemented as a platform, will be
formed of all hardware and software components needed to acquire and collect data on the actual
building performance and usage, including sensor component deployment, data collection,
management tools. It will include the database to store all data collected by the WSN on the actual
performance and usage of the building.
Despite the nature of Deliverable D5.1, which should be in the form of Prototype, we summarize
hereby our contributions on the achievement results that conform to the Work Package 5.1 BAU-
WSN implementation and Work Package 5.2 Buidling performance & usage database, which
include
Deployment of Wireless Sensor Network
Wireless Sensor Network Database
In the first part of this document, Deployment of Wireless Sensor Network, we focus on the
deployment of various wireless sensor nodes selected and purchased. These sensors are off-the-
shelves available directly from the market, easy and flexible to be configured, installed, and
deployed. An EnPROVE box is also installed as a gateway to hold the raw data gathered by two
sets of installed wireless sensors.
The second part, Wireless Sensor Network Database, deals with the design and implementation of
database for Wireless Sensor Network. The database structure is presented and explained, while
the implementation is realized with MySQL, an open-source database management tool. A serie of
data APIs are also presented and implemented in Java language, in order to facilitate data query
request from EPDSS system.
EnPROVE D5.1 Wireless Sensor Network
Page 6 of 30
2. Deployment of Wireless Sensor Network
2.1 Wireless sensor component
We present in this section the wireless sensors selected for network deployment to acquire and
collect data on building performance and usage. These sensor are off-the-shelves available from
the market and can be grouped into two categories. The first group comprise TelosB sensors,
which are using 6LowPAN protocol - BLIP and programmed and operated by TinyOS, an open
source embedded operating system. The other group comprises CSTB sensors, which are using
X2D wireless protocol, battery powered while developed and supported by CSTB. Both types of
sensor network are deployed simultaneously in order for performance verification on-site, where
network reliability and robustness are evaluated.
2.1.1 Brightness and lights usage
TelosB Mote
Company: Crossbow Product: TELOSB
Description:
Crossbow’s TelosB mote is an open source platform designed to enable state of the art WSN functionality.
Usage domain:
Light sensor, temperature sensor, and humidity sensor,
Usage Scenario:
The sensor detects ambient brightness is enough for optimum lighting conditions, it reports the sensor readings back to the BAU.
Input: Environment brightness, Environment Humidity
Output: Electronic signals which can be wireless transmitted
Cost range: €80 - €100
EnPROVE D5.1 Wireless Sensor Network
Page 7 of 30
Overhead lighting sensor
Company: CSTB Product: CSTBox-LUS
Description:
Wireless light usage sensor (CSTB–made)
Xbee radio module – ISM band (2.4GHz)
Protocol 802.15.4
Usage domain:
Lights state Off/On detection
Input: Light usage
Output: Electronic wireless signals
2.1.2 Presence detection
CM4000
SE1000
Company: Advantic Product: CM4000
Description:
Advantic’s CM4000 is a clone of the Mica2 that offers the same functionality. The SE1000 sensor board offers sensor upgradability to the CM4000
Usage domain:
PIR sensor, Audio sensor
Usage Scenario:
The PIR sensor senses movement. The sensor reports this movement back to the BAU.
Microphone and Sound sensors detect noise over a certain threshold. The sensor reports to the BAU about this noise for possible presence detection.
Input: PIR, Microphone
Output: Electronic signals which can be wireless transmitted
Cost range: €150
EnPROVE D5.1 Wireless Sensor Network
Page 8 of 30
2.1.3 Doors, windows and blinds usage
Door / window opening sensor
Company: DELTA DORE Product: MINI COX
Description:
Wireless sensor for detecting the opening as well as closing of doors and windows. Directly sticks to the door or windows
Usage domain:
Doors, windows usage
Input: Human activity on windows or doors’ closing and opening status
Output: Electronic wireless signals
Cost range: 38 €
2.1.4 Electricity consumption
Single Phase Electricity Monitor
Company: Episensor Product: Single Phase Electricity Meter
Description:
This monitor is a highly accurate, wireless three phase electricity monitor.
Usage domain:
Electricity monitoring
Usage Scenario:
The meter monitors electricity usage which can then be used to determine if electricity was being used while there was no people present
Input: Electricity
Output: Electronic signals which can be wireless transmitted
Cost range: €245-€300
EnPROVE D5.1 Wireless Sensor Network
Page 9 of 30
2.1.5 Temperature
Temperature sensor
Company: DELTA DORE Product: DD 6300036
Description:
Wireless indoor/outdoor digital thermometer
Usage domain:
Air temperature measurements
Input: Air temperature
Output: Electronic wireless signals
Cost range: 80 €
2.2 EnPROVE Gateway
Using a dedicated gateway is compulsory for a reliable transmission and reporting system. This
section specifies the requirements regarding the implementation of the EnPROVE WSN Box. The
box is presented under the following domains and is illustrated in Figure 2.1:
Hardware Abstraction Layer,
Application Components,
Communication with the remote EnPROVE platform,
Hardware.
Figure 2.1: General Specification EnPROVE Box
EnPROVE D5.1 Wireless Sensor Network
Page 10 of 30
2.2.1 HAL Specifications
The HAL (Hardware Abstraction Layer) is an abstraction layer implemented in software, between
the physical hardware of the EnPROVE Box and the software that will run on the box. Its main
function is to mask the differences in hardware from the overall operating system. In essence it is
the drivers that allow the hardware to communication with the software. With regard to the
EnPROVE box there are three parts to this.
Wireless network interface modules,
Drivers,
Translation Module.
The wireless network interface modules are the modules that communicate with the actual WSN
and also with the remote EnPROVE platform if the box is connecting to it through a wireless
connection. The box will support several different module types to accommodate the different
communication protocols used by the sensor nodes themselves (XBee 802.15.4, ZigBee, etc).
With regard to the communication with the WSN itself, the box is only interested in receiving data
that has been collected by the wireless sensor nodes.
For each set of protocols used in the WSN, a driver is needed to understand this protocol. For
example, a driver will be required for communication using ZigBee and a separate driver will be
required for communication using XBee 802.15.4.
A translation module is a software component that takes the raw data being received from the
WSN and translates it into a predefined data structured also know as a digital event. These events
are then stored in an events cloud until the software applications can consume them.
2.2.2 Application Components
Application components consume the events from the events could previously described. They
correlate the event information in real time and generate a higher level data structure ready to be
transmitted to the EnPROVE platform. Currently the actual processes preformed to generate this
higher level data structure are not yet defined because they depend on EPDSS input data
requirements.
To enable flexibility within the software process, we will rely on a framework called OSGi. This
framework will enable the software to change over time and it will allow us to add or remove
modules as the platform evolves. It allows the EnPROVE box to do this without ever needing to
restart other services or the box itself. OSGi has been extensively discussed in Deliverable 2.3 and
does not require further exploration.
EnPROVE D5.1 Wireless Sensor Network
Page 11 of 30
2.2.3 Communication with the remote EnPROVE platform
As illustrated in Figure 2.1 there may be multiple EnPROVE boxes communicating with the
EnPROVE platform simultaneously. Each box is required to have a connection to the internet to be
able to function as a gateway between the WSN and the EnPROVE platform.
The communication between an EnPROVE Box and the global EnPROVE System Platform is web-
services based (using http/htpps web protocols). It means that some services are exposed on the
Web by the EnPROVE System Platform - through a communication interface facade - and can be
invoked by any registered EnPROVE Box. The communication is univocal from the boxes to the
global system.
Before calling any exposed web-service, a box must be registered within the EnPROVE System,
that is to say a table of allowed boxes is maintained inside the EnPROVE System (table of boxes’
MAC addresses, for instance) to indicate which boxes can perform a service call. Any request from
an unregistered client is rejected. A manager application is required to perform this registration
(add/remove a box from the system).
As information is transmitted from the EnPROVE box to the EnPROVE platform the box will
encapsulate the high level events into EnPROVE events. A web-service is invoked to transmit
these events either separately or combined.
2.2.4 Hardware
We have previously described an system that must also be independent of hardware
implementation to achieve its goals. For this reason the EnPROVE box is implemented with the
following characteristics:
OS: Linux
Framework: OSGi
Implementation language: Java
Persistent support (to hold the “events-cloud”): SQL database.
2.3 Network Deployment
2.3.1 Location
Wireless sensor network is deployed at UCD CLARITY centre, which resides in the ground floor of
a 4-storey building, which is located on the UCD campus. The premise comprises several types of
area that are shown in Figure 2.2, i.e. Open office, individual office, tea station, corridors, and
boardroom.
EnPROVE D5.1 Wireless Sensor Network
Page 12 of 30
Figure 2.2: CLARITY Centre
Figure 2.3: CLARITY Centre
EnPROVE D5.1 Wireless Sensor Network
Page 13 of 30
2.3.2 Deployment map
Figure 2.4: WSN Deployment Map
Figure 2.5 demonstrates several parts of ongoing data collection by using the Wireless Sensor
Network deployed at CLARITY premise in Ireland. The current testbed comprises luminance,
presence, and temperature sensor nodes. We deploy these sensor nodes at several positions such
as corridor, individual office, write-up area and meeting room, to measure light usage, temperature
level, and people presence. As shown in the figure, a light sensor is enclosed by a paper cover
while being attached on a window in order to measure the outside luminance. Moreover, we can
observe several presence sensors have been put in proximity to desk in order to detect people
presence.
Overall, a total number of 35 CLARITY sensors and 23 CSTB sensors are deployed to acquire and
collect building performance usage raw data. These deployed sensor are capable of detecting
peple presence, indoor/outdoor level, indoor/outdoor temperature, lighting electricity comsumption,
door/window status, while reporting the collected data to the EnPROVE gateway.
EnPROVE D5.1 Wireless Sensor Network
Page 14 of 30
Figure 2.5: WSN on-site deployment
EnPROVE D5.1 Wireless Sensor Network
Page 15 of 30
3. Wireless Sensor Network Database
3.1 Design
Figure 3.1: WSN DB structure
EnPROVE D5.1 Wireless Sensor Network
Page 16 of 30
We present the database structure of the WSN as well as the relationships between the data. It
illustrates the WSN database structure that is divided into two parts. Firstly, a section of the WSN
database resides on each individual gateway installed. This gateway database contains
information relating to the local site only and includes raw data collected, device/sensor specifics
and device/gateway location information. Secondly, a complete structure of the database resides in
Figure 3.2 on the Building Performance & Usage Server (BAU Server). This is the remote server
that contains a copy of all information from all EnPROVE sites and gateways including raw data
from all gateways and non-WSN related tables (e.g. Building Data, Users).
Figure 3.2: System Architecture
Beginning from the user table, each user can be assigned to a site that allows them access to site-
specific data. Each site can have building data associated with it that can be added if building data
is not available from CAD drawings or FM models during the initial phases. Each site can be
divided into several zones and can have different zone types. From these zones, gateways and
sensor devices can be installed and associated to the zones. A sensor device can communicate
through a number of different wireless protocols. A sensor device can carry a number of sensors.
For example, a CM4000 sensor mote can have attached a temperature, light and contact sensor to
the one device. Each sensor will have a measure type associated with it. Alerts can also be set for
each individual sensor. For example, if a temperate sensor has not reported a reading in 24 hours,
then alert the Auditing Contractor. All sensor events are recorded in the events table. These can
include actual sensor readings or alerts about individual sensors.
We design the database structure for WSN by using the Visual Paradigm for UML, a free database
design tool with support of entity relationship diagram and UML class diagram generation.
EnPROVE D5.1 Wireless Sensor Network
Page 17 of 30
3.2 Implementation
Figure 3.3: Database view on MySQL server
EnPROVE D5.1 Wireless Sensor Network
Page 18 of 30
We select MySQL database management tool to implement our designed database structure for
WSN. Figure 3.3 illustrates the table implementation shown in MySQL Server, while a piece of
query of ongoing data collection is shown in Figure 3.4.
Figure 3.4: WSN Raw Data
More, we also implement data APIs in Java into the platform to facilitate the data query request
from EPDSS. These are the interface to the auditing result database accessed by the EPDSS. All
functions return lists of auditing measure values (AuditingMeasureList). The first value is the value
measured at start time, the last value is the value measured at end time. Intermediate values follow
the start time measure in measurement frequency time intervals, therefore there can be a smaller
time intervals between the last two values than the given frequency time span. A returned value of
null means that the measurements are not available for the specified context (time, zone).
EnPROVE D5.1 Wireless Sensor Network
Page 19 of 30
AuditingMeasureList getSolarRadiationOutside(AuditingMeasureInterval interval)
get the solar radiation at the project location (kW/m²)
Parameters:
interval - the measurement interval (start, end, measurement frequency)
Returns:
the list of solar radiation Double values at the project location
AuditingMeasureList getTemperatureOutside(AuditingMeasureInterval interval)
get the outside temperature at the project location (Degree Celsius)
Parameters:
interval - the measurement interval (start, end, measurement frequency)
Returns:
the list of outside temperature Double values at the project location
AuditingMeasureList getWindSpeed(AuditingMeasureInterval interval)
get the outside wind speed at the project location (m/s)
Parameters:
interval - the measurement interval (start, end, measurement frequency)
Returns:
the list of outside wind speed Double values at the project location
AuditingMeasureList getWindDirection(AuditingMeasureInterval interval)
get the outside wind direction at the project location (angle degrees relative to North)
Parameters:
interval - the measurement interval (start, end, measurement frequency)
Returns:
the list of outside wind angle Double values at the project location
EnPROVE D5.1 Wireless Sensor Network
Page 20 of 30
AuditingMeasureList getTemperatureInside(AuditingMeasureInterval interval,
java.lang.String zoneId)
get the temperature inside the given zone (Degree Celsius)
Parameters:
interval - the measurement interval (start, end, measurement frequency)
zoneId - the Id of the zone to be evaluated
Returns:
the list of temperature Double values inside the given zone
AuditingMeasureList getHeatingSetPoints(AuditingMeasureInterval interval,
java.lang.String zoneId)
get the heating setpoints for the given zone (Degree Celsius)
Parameters:
interval - the measurement interval (start, end, measurement frequency)
zoneId - the Id of the zone to be evaluated
Returns:
the list of heating setpoints Double values for the given zone
AuditingMeasureList getHeatingStatus(AuditingMeasureInterval interval,
java.lang.String zoneId)
get the heating status for the given zone (true = on, false = off)
Parameters:
interval - the measurement interval (start, end, measurement frequency)
zoneId - the Id of the zone to be evaluated
Returns:
the list of heating status Boolean values for the given zone
EnPROVE D5.1 Wireless Sensor Network
Page 21 of 30
AuditingMeasureList getCoolingSetPoints(AuditingMeasureInterval interval,
java.lang.String zoneId)
get the cooling setpoints for the given zone (Degree Celsius)
Parameters:
interval - the measurement interval (start, end, measurement frequency)
zoneId - the Id of the zone to be evaluated
Returns:
the list of cooling setpoints Double values for the given zone
AuditingMeasureList getCoolingStatus(AuditingMeasureInterval interval,
java.lang.String zoneId)
get the cooling status for the given zone (true = on, false = off)
Parameters:
interval - the measurement interval (start, end, measurement frequency)
zoneId - the Id of the zone to be evaluated
Returns:
the list of cooling status Boolean values for the given zone
AuditingMeasureList getVentilationSetPoints(AuditingMeasureInterval interval,
java.lang.String zoneId)
get the ventilation setpoints for the given zone (Degree Celsius)
Parameters:
interval - the measurement interval (start, end, measurement frequency)
zoneId - the Id of the zone to be evaluated
Returns:
the list of ventilation setpoints Double values for the given zone
EnPROVE D5.1 Wireless Sensor Network
Page 22 of 30
AuditingMeasureList getVentilationStatus(AuditingMeasureInterval interval,
java.lang.String zoneId)
get the ventilation status for the given zone (true = on, false = off)
Parameters:
interval - the measurement interval (start, end, measurement frequency)
zoneId - the Id of the zone to be evaluated
Returns:
the list of ventilation status Boolean values for the given zone
AuditingMeasureList getHullDoorStatus(AuditingMeasureInterval interval,
java.lang.String zoneId)
get the status of building hull doors related to the given zone (true = at least one is open, false = all
are closed)
Parameters:
interval - the measurement interval (start, end, measurement frequency)
zoneId - the Id of the zone to be evaluated
Returns:
thethe list of building hull doors status Boolean values for the given zone
AuditingMeasureList getWindowStatus(AuditingMeasureInterval interval,
java.lang.String zoneId)
get the status of windows related to the given zone (true = at least one is open, false = all are
closed)
Parameters:
interval - the measurement interval (start, end, measurement frequency)
zoneId - the Id of the zone to be evaluated
Returns:
EnPROVE D5.1 Wireless Sensor Network
Page 23 of 30
thethe list of windows status Boolean values for the given zone
AuditingMeasureList getBlindsStatus(AuditingMeasureInterval interval,
java.lang.String zoneId)
get the status of window blinds related to the given zone (true = open, false = closed)
Parameters:
interval - the measurement interval (start, end, measurement frequency)
zoneId - the Id of the zone to be evaluated
Returns:
the list of window blinds status Boolean values for the given zone
AuditingMeasureListgetDayLightOutside(AuditingMeasureInterval interval)
get the intensity of the outside daylight (Candela)
Parameters:
interval - the measurement interval (start, end, measurement frequency)
Returns:
the list of outside daylight intensity Double values
AuditingMeasureList getDayLightInside(AuditingMeasureInterval interval,
java.lang.String zoneId)
get the intensity of the daylight contribution to the given zone (Candela)
Parameters:
interval - the measurement interval (start, end, measurement frequency)
zoneId - the Id of the zone to be evaluated
Returns:
the list of daylight contribution intensity Double values to the given zone
EnPROVE D5.1 Wireless Sensor Network
Page 24 of 30
AuditingMeasureList getArtificialLightInside(AuditingMeasureInterval interval,
java.lang.String zoneId)
get the intensity of the inside artificial light intensity for the given zone (Candela)
Parameters:
interval - the measurement interval (start, end, measurement frequency)
zoneId - the Id of the zone to be evaluated
Returns:
the list of inside artificial light intensity Double values for the given zone
AuditingMeasureList getPerceivedLightInside(AuditingMeasureInterval interval,
java.lang.String zoneId)
get the intensity of the inside perceived light intensity for the given zone (Candela)
Parameters:
interval - the measurement interval (start, end, measurement frequency)
zoneId - the Id of the zone to be evaluated
Returns:
the list of inside perceived light intensity Double values for the given zone
AuditingMeasureList getLuminaireStatus(AuditingMeasureInterval interval,
java.lang.String zoneId)
get the status of lamps related to the given zone (true = on, false = off)
Parameters:
interval - the measurement interval (start, end, measurement frequency)
zoneId - the Id of the zone to be evaluated
Returns:
the list of lamp status Boolean values for the given zone
EnPROVE D5.1 Wireless Sensor Network
Page 25 of 30
AuditingMeasureList getOccupancyStatus(AuditingMeasureInterval interval,
java.lang.String zoneId)
get the occupancy status of the given zone (true = occupied, false = empty)
Parameters:
interval - the measurement interval (start, end, measurement frequency)
zoneId - the Id of the zone to be evaluated
Returns:
the list of occupancy status Boolean values for the given zone
AuditingMeasureList getOccupancyCount(AuditingMeasureInterval interval,
java.lang.String zoneId)
get the occupancy count for the given zone (Integer)
Parameters:
interval - the measurement interval (start, end, measurement frequency)
zoneId - the Id of the zone to be evaluated
Returns:
the list of occupancy count Integer values for the given zone
AuditingMeasureList getElectricityConsumptionLighting(AuditingMeasureInterval interval,
java.lang.String zoneId)
the electricity consumption for the lamps in the given zone (kWh)
Parameters:
interval - the measurement interval (start, end, measurement frequency)
zoneId - the Id of the zone to be evaluated
Returns:
the list of electricity consumption Double values for the lamps in the given zone
EnPROVE D5.1 Wireless Sensor Network
Page 26 of 30
AuditingMeasureList getElectricityConsumptionApplicances(AuditingMeasureInterval interval,
java.lang.String zoneId)
the electricity consumption for electric appliances (not lamps) in the given zone (kWh)
Parameters:
interval - the measurement interval (start, end, measurement frequency)
zoneId - the Id of the zone to be evaluated
Returns:
the list of electricity consumption Double values for appliances in the given zone
AuditingMeasureList getElectricityConsumptionHVAC(AuditingMeasureInterval interval)
the total electricity consumption for HVAC
Parameters:
interval - the measurement interval (start, end, measurement frequency)
Returns:
the list of electricity consumption Double values for HVAC
AuditingMeasureList getFossilConsumptionHeating(AuditingMeasureInterval interval)
the total volume of fossil consumption for Heating (m³)
Parameters:
interval - the measurement interval (start, end, measurement frequency)
Returns:
the list of fossil consumption Double values for Heating
AuditingMeasureList getWaterTemperatureHeaterIn(AuditingMeasureInterval interval,
java.lang.String unitId)
get the temperature of the water going into the heater unit (Degree Celsius)
Parameters:
EnPROVE D5.1 Wireless Sensor Network
Page 27 of 30
interval - the measurement interval (start, end, measurement frequency)
unitId - the Id of the monitored unit
Returns:
the list of temperature Double values for the water going into the heater
AuditingMeasureList getWaterTemperatureHeaterOut(AuditingMeasureInterval interval,
java.lang.String unitId)
get the temperature of the water coming from the heater unit (Degree Celsius)
Parameters:
interval - the measurement interval (start, end, measurement frequency)
unitId - the Id of the monitored unit
Returns:
the list of temperature Double values for the water coming from the heater
AuditingMeasureList getWaterFlowHeater(AuditingMeasureInterval interval,
java.lang.String unitId)
get the flow amount of water that goes through the heater(m³/h)
Parameters:
interval - the measurement interval (start, end, measurement frequency)
unitId - the Id of the monitored unit
Returns:
the list of water flow Double values for the water going through the heater
AuditingMeasureList getWaterDistributionControlStrategy(AuditingMeasureInterval interval,
java.lang.String unitId)
get the active control strategy set for the water distribution (String)
Parameters:
EnPROVE D5.1 Wireless Sensor Network
Page 28 of 30
interval - the measurement interval (start, end, measurement frequency)
unitId - the Id of the monitored unit
Returns:
the list of active control strategies (Strings) set for the water distribution
AuditingMeasureList getAirTemperatureHVACIn(AuditingMeasureInterval interval,
java.lang.String unitId)
get the temperature of the air going into the HVAC unit (Degree Celsius)
Parameters:
interval - the measurement interval (start, end, measurement frequency)
unitId - the Id of the monitored unit
Returns:
the list of temperature Double values for the air going into the HVAC unit
AuditingMeasureList getAirTemperatureHVACOut(AuditingMeasureInterval interval,
java.lang.String unitId)
get the temperature of the air coming from the HVAC unit (Degree Celsius)
Parameters:
interval - the measurement interval (start, end, measurement frequency)
unitId - the Id of the monitored unit
Returns:
the list of temperature Double values for the air coming from the HVAC unit
AuditingMeasureList getAirFlowHVAC(AuditingMeasureInterval interval,
java.lang.String unitId)
get the flow amount of air that goes through the HVAC unit (m³/h)
Parameters:
EnPROVE D5.1 Wireless Sensor Network
Page 29 of 30
interval - the measurement interval (start, end, measurement frequency)
unitId - the Id of the monitored unit
Returns:
the list of air flow Double values for the air going through the HVAC unit
AuditingMeasureList getAirDistributionControlStrategy(AuditingMeasureInterval interval,
java.lang.String unitId)
get the active control strategy set for the air distribution (String)
Parameters:
interval - the measurement interval (start, end, measurement frequency)
unitId - the Id of the monitored unit
Returns:
the list of active control strategies (Strings) set for the air distribution
EnPROVE D5.1 Wireless Sensor Network
Page 30 of 30
4. Conclusion
This document, D5.1 Wireless Sensor Network, summarizes the accomplishment achieved in
accordance with the Work Package 5.1 BAU-WSN implementation and Work Package 5.2 Buidling
performance & usage database, which include the deployment of Wireless Sensor Network, and
the wireless sensor network database designed and implemented for data storage.
The first section deals with the deployment process, where a total number 35 CLARITY sensors
and 23 CSTB sensors capable of measuring light, presence, temperature and electricity
measurement, have been deployed at CLARITY premise in Dublin, Ireland. These sensors are
installed and configured via the deployed EnPROVE gateway, which is capable of gathering the
data measurement, and bridges the local sensors and the remote EnPROVE server. The
deployment map illustrustrates the current status of the deployed wireless sensors, providing a
more informative and expressive understanding of the deployment efforts.
The second section shows the database designed and implemented for wireless sensor network.
The design is conducted via Visual Paradigm for UML, a free database design tool with support of
entity relationship diagram and UML class diagram generation. The implementation is realized via
MySQL, an open-source database management tool, on the EnPROVE gateway. A serie of data
APIs are also presented and implemented in Java language, and integrataed with the EnPROVE
platform in order to facilitate data query request from EPDSS system.
In conclusion, D5.1 Wireless Sensor Network takes place by the end of M23, despite the nature of
being a prototype, which should be demonstrated on-site as a reliable and functional system. Thus,
we provide this document with the achievement accomplished with respect to WP 5.1 BAU-WSN
implementation and WP 5.2 Buidling performance & usage database. The deployment at CLARITY
premise is accomplished with the ongoing data collection. The scope of this document is
summarized to give an overview of the functional and deployed wireless sensor network, which in
subsequence, should prepare the nature of the entire BAU-WSN that is going to be connected with
the EPDSS via the implemented data APIs during the integration. Our next step will be to
investigate and improve system reliability and usability in order to contribute to the milestone M26
by provding all hardware and software parts to the EnPROVE platform.