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

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.


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


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


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.


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


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


Cost range: €150


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


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


Cost range: €245-€300


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


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


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.


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.


of 30

Figure 2.2: CLARITY Centre

Figure 2.3: CLARITY Centre


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.


of 30

Figure 2.5: WSN on-site deployment


of 30

3. Wireless Sensor Network Database

3.1 Design

Figure 3.1: WSN DB structure


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.


of 30

3.2 Implementation

Figure 3.3: Database view on MySQL server


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


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:


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:


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:


Returns:

the list of outside wind angle Double values at the project location


of 30

AuditingMeasureList getTemperatureInside(AuditingMeasureInterval interval,

java.lang.String zoneId)

get the temperature inside the given zone (Degree Celsius)

Parameters:


zoneId - the Id of the zone to be evaluated

Returns:

the list of temperature Double values inside the given zone

AuditingMeasureList getHeatingSetPoints(AuditingMeasureInterval interval,


get the heating setpoints for the given zone (Degree Celsius)

Parameters:



Returns:

the list of heating setpoints Double values for the given zone

AuditingMeasureList getHeatingStatus(AuditingMeasureInterval interval,


get the heating status for the given zone (true = on, false = off)

Parameters:



Returns:

the list of heating status Boolean values for the given zone


of 30

AuditingMeasureList getCoolingSetPoints(AuditingMeasureInterval interval,


get the cooling setpoints for the given zone (Degree Celsius)

Parameters:



Returns:

the list of cooling setpoints Double values for the given zone

AuditingMeasureList getCoolingStatus(AuditingMeasureInterval interval,


get the cooling status for the given zone (true = on, false = off)

Parameters:



Returns:

the list of cooling status Boolean values for the given zone

AuditingMeasureList getVentilationSetPoints(AuditingMeasureInterval interval,


get the ventilation setpoints for the given zone (Degree Celsius)

Parameters:



Returns:

the list of ventilation setpoints Double values for the given zone


of 30

AuditingMeasureList getVentilationStatus(AuditingMeasureInterval interval,


get the ventilation status for the given zone (true = on, false = off)

Parameters:



Returns:

the list of ventilation status Boolean values for the given zone

AuditingMeasureList getHullDoorStatus(AuditingMeasureInterval interval,


get the status of building hull doors related to the given zone (true = at least one is open, false = all

are closed)

Parameters:



Returns:

thethe list of building hull doors status Boolean values for the given zone

AuditingMeasureList getWindowStatus(AuditingMeasureInterval interval,


get the status of windows related to the given zone (true = at least one is open, false = all are

closed)

Parameters:



Returns:


of 30

thethe list of windows status Boolean values for the given zone

AuditingMeasureList getBlindsStatus(AuditingMeasureInterval interval,


get the status of window blinds related to the given zone (true = open, false = closed)

Parameters:



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:


Returns:

the list of outside daylight intensity Double values

AuditingMeasureList getDayLightInside(AuditingMeasureInterval interval,


get the intensity of the daylight contribution to the given zone (Candela)

Parameters:



Returns:

the list of daylight contribution intensity Double values to the given zone


of 30

AuditingMeasureList getArtificialLightInside(AuditingMeasureInterval interval,


get the intensity of the inside artificial light intensity for the given zone (Candela)

Parameters:



Returns:

the list of inside artificial light intensity Double values for the given zone

AuditingMeasureList getPerceivedLightInside(AuditingMeasureInterval interval,


get the intensity of the inside perceived light intensity for the given zone (Candela)

Parameters:



Returns:

the list of inside perceived light intensity Double values for the given zone

AuditingMeasureList getLuminaireStatus(AuditingMeasureInterval interval,


get the status of lamps related to the given zone (true = on, false = off)

Parameters:



Returns:

the list of lamp status Boolean values for the given zone


of 30

AuditingMeasureList getOccupancyStatus(AuditingMeasureInterval interval,


get the occupancy status of the given zone (true = occupied, false = empty)

Parameters:



Returns:

the list of occupancy status Boolean values for the given zone

AuditingMeasureList getOccupancyCount(AuditingMeasureInterval interval,


get the occupancy count for the given zone (Integer)

Parameters:



Returns:

the list of occupancy count Integer values for the given zone

AuditingMeasureList getElectricityConsumptionLighting(AuditingMeasureInterval interval,


the electricity consumption for the lamps in the given zone (kWh)

Parameters:



Returns:

the list of electricity consumption Double values for the lamps in the given zone


of 30

AuditingMeasureList getElectricityConsumptionApplicances(AuditingMeasureInterval interval,


the electricity consumption for electric appliances (not lamps) in the given zone (kWh)

Parameters:



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:


Returns:

the list of electricity consumption Double values for HVAC

AuditingMeasureList getFossilConsumptionHeating(AuditingMeasureInterval interval)

the total volume of fossil consumption for Heating (m³)

Parameters:


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:


of 30


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,


get the temperature of the water coming from the heater unit (Degree Celsius)

Parameters:



Returns:

the list of temperature Double values for the water coming from the heater

AuditingMeasureList getWaterFlowHeater(AuditingMeasureInterval interval,


get the flow amount of water that goes through the heater(m³/h)

Parameters:



Returns:

the list of water flow Double values for the water going through the heater

AuditingMeasureList getWaterDistributionControlStrategy(AuditingMeasureInterval interval,


get the active control strategy set for the water distribution (String)

Parameters:


of 30



Returns:

the list of active control strategies (Strings) set for the water distribution

AuditingMeasureList getAirTemperatureHVACIn(AuditingMeasureInterval interval,


get the temperature of the air going into the HVAC unit (Degree Celsius)

Parameters:



Returns:

the list of temperature Double values for the air going into the HVAC unit

AuditingMeasureList getAirTemperatureHVACOut(AuditingMeasureInterval interval,


get the temperature of the air coming from the HVAC unit (Degree Celsius)

Parameters:



Returns:

the list of temperature Double values for the air coming from the HVAC unit

AuditingMeasureList getAirFlowHVAC(AuditingMeasureInterval interval,


get the flow amount of air that goes through the HVAC unit (m³/h)

Parameters:


of 30



Returns:

the list of air flow Double values for the air going through the HVAC unit

AuditingMeasureList getAirDistributionControlStrategy(AuditingMeasureInterval interval,


get the active control strategy set for the air distribution (String)

Parameters:



Returns:

the list of active control strategies (Strings) set for the air distribution


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.

enprove energy consumption prediction with building usage … · 2017. 4. 20. · enprove d5.1...

Documents