Introducing the Web-of-Things in Building Automation

A Gateway for KNX Installations

ome Bovet

1,2

and Jean Hennebert

2,3

LTCI, Telecom ParisTech, Paris, France

CoSI, University of Applied Sciences of Western Switzerland, Fribourg, Switzerland

DIUF, University of Fribourg, Fribourg, Switzerland

Keywords:

Smart Buildings, Web-of-Things, RESTful, KNX, Building Automation, Gateway.

Abstract:

Due to increasing energy costs and the importance of the comfort, smart buildings tend to democratize both

in new and renovated constructions, based on management systems relying on dedicated networks. Network

heterogeneity leads to complex building management systems having to implement all the protocols of the

building networks, resulting in low system integration and heavy maintenance efforts. Those building net-

works offer no common standardized application layer to build applications. To remedy this, we propose in

this paper to leverage on the Web-of-Things (WoT) framework, using well-known technologies like HTTP

and RESTful APIs. We outline the implementation of a gateway using the principles of the WoT to expose

capabilities of the KNX building network as Web services, allowing a fast integration in management systems.

1 INTRODUCTION

In recent years, building management systems (BMS)

have become very common in various types of build-

ings, such as ofﬁces, as manufactures or even pri-

vate households. They rely on a variety of sensors

and actuators composing together a whole dedicated

building network. At origin, the heating control of a

building was very simple, only composed of global

thermostats, or distributed in every room, targeting

a threshold temperature value. Motivated by raising

energy costs and by the importance of the comfort,

more complicated strategies have since then been de-

veloped. Modern BMS include many kinds of sens-

ing and actuating devices, managing the HVAC (Heat-

ing, Ventilation and Air Conditioning), the lighting,

the open and closing of doors, windows and blinds

control, and security access systems. Buildings have

become ”smart” and are now real information sys-

tems using dedicated building management networks

for communication, as for example KNX, BACnet, or

LonWorks. KNX is actually the most used network

in Europe. One can ﬁnd almost every kind of de-

vice compatible with this network that offers differ-

ent types of physical connections like Ethernet, RF,

power line, or more widespread the twisted pair (Kon-

nexAssociation, 2004).

Unfortunately, such building management net-

works do not offer a standardised way to interact with

devices connected to them from an application point

of view. Due to this, it becomes difﬁcult to build

BMS combining multiple networks. This situation

can be found in buildings where the network should

evolve with new devices that are not compatible with

the actual one, or where extending the wiring is not

feasible because of physical constraints (Bovet and

Hennebert, 2012). This is leading to heterogeneous

building management networks as visible in ﬁgure 1.

While it exists gateways encapsulating the speciﬁc

telegrams of the building management network in IP

packets, there is actually no standard at the applica-

tion level, resulting in the BMS having to understand

and to implement every network protocol.

Figure 1: Network heterogeneity in smart buildings.

Web services are nowadays widespread in hetero-

geneous information systems (IS). They beneﬁt from

the facts of being platform independent, and of using

Bovet G. and Hennebert J..

Introducing the Web-of-Things in Building Automation - A Gateway for KNX Installations.

DOI: 10.5220/0004425500990106

In Proceedings of the 10th International Conference on Informatics in Control, Automation and Robotics (ICINCO-2013), pages 99-106

ISBN: 978-989-8565-70-9

 2013 SCITEPRESS (Science and Technology Publications, Lda.)

well-known standards for data exchange that ensure

the interoperability, as it is the case for SOAP. Un-

fortunately the SOAP protocol is not well suited for

accessing sensors and actuators considered as things,

because of the large overhead of XML and the com-

plexity of the service description language WSDL. On

the other hand, the emerging Web-of-Things frame-

work (WoT), offers new ways for accessing things in a

resource oriented architecture (ROA) (Guinard et al.,

2011), which are more suited for BMS.

In this paper, we present the implementation of

a gateway allowing access to devices connected to a

KNX network in a Web-of-Things manner. By tak-

ing advantage of the bests practices of the WoT, we

guarantee a fast integration of KNX in every control

system. In addition to this, we put importance on the

fact that our gateway must be simple to use, low-cost

and easily integrable in an existing environment.

This paper is organised as follows. The next sec-

tion refers and summarizes related work. In Sect.

3, we provide an overview of the Web-of-Things

paradigm. Its application to the KNX network is dis-

cussed in Sect. 4. Sect. 5 describes the implementa-

tion of the gateway. Performance tests in a real build-

ing are shown in Sect. 6. Sect. 7 concludes our paper

and provides insights on further research.

2 RELATED WORK

One of the early projects considering people, places

and things as Web resources is Cooltown (Kindberg

and al., 2002). This project introduced a new inter-

action approach by using HTTP GET and POST re-

quests to manipulate things. Then, with the progress

made in embedded systems by offering more comput-

ing power on smaller devices, it was possible to inte-

grate Web servers on sensors and actuators. So-called

mashups were introduced in the WebPlug framework

relying on the Web-of-Things paradigm, where sen-

sors and actuators play a central role (Ostermaier

et al., 2010).

Problems related to performance and memory

usage on things leveraging on Web services were

quickly discovered. Although the SOAP protocol

contributing in a standardization aspect between Web

services and being largely adopted on the Web, it is

not suited for constrained environments (Groba and

Clarke, 2011). More adapted to things, RESTful

APIs represent a clear alternative to this drawback,

with an increased adoption by many IS, particularly

in the ﬁelds of Internet-of-Things (IoT) and WoT (Ai-

jaz et al., 2009) (Hamad et al., 2010).

Trying to ease the development of applications

using KNX devices has been explored in different

works. A ﬁrst attempt was realized with the BCU

SDK (Kastner et al., 2005), which consists of a script

generating C++ classes representing devices capabil-

ities. A more Web oriented approach has been real-

ized in (Neugschwandtner et al., 2007). It exposes

KNX functionalities as Web services by using the

oBIX (Open Building Information Exchange) stan-

dard, which is a special XML schema for representing

building data and operations. Unfortunately, oBIX is

not at all widespread over IS and BMS probably be-

cause of its complex XML schema. In addition to

this, the proposed implementation does not allow an

easy integration of the gateway in an existing environ-

ment, requiring a huge conﬁguration effort for large

networks. Our approach tackles these limitations by

taking advantage of the WoT’s simplicity and by be-

ing highly integrable in existing KNX infrastructures.

3 THE WoT FRAMEWORK

The Web-of-Things based on well-accepted standards

of the Web, ﬁlls the gap left by the Internet-of-Things

regarding the application layer (Guinard, 2011). In-

deed, the IoT only touches on the IP connectivity

of everyday objects, resolving problems linked to

the Internet access and network topologies. In or-

der to homogenize the access on things representing

resources, the technologies of the Web as URL rep-

resentations for identifying resources, RESTful APIs

and the HTTP protocol represent a good approach

because of being strongly standardized and already

widespread. In this chapter we will provide insights

of the main concepts building the WoT.

3.1 Resource Identiﬁcation

In the WoT, every capability or property of a device is

considered as a resource. As for example, a temper-

ature sensor could return the measured value both in

Celsius and in Fahrenheit. This would give us two

resources that can be read. More precisely, some

resources can allow multiple operations as read and

write. So, we ﬁrst need to be able to identify and ad-

dress those resources in a simple way before we can

interact with them. This is realized by using URLs in

the same way as for identifying Web pages on servers.

An advantage of this approach is in its hierarchi-

cal way to organize resources reﬂecting the physical

world. This principle is shown in ﬁgure 2. For access-

ing the Celsius temperature value, one would use fol-

lowing URL: http://<DOMAIN>:<PORT>/generic-

nodes/1/sensors/temperature/celsius.

ICINCO2013-10thInternationalConferenceonInformaticsinControl,AutomationandRobotics

100

/genericNodes

/{genericNodes-n}

/sensors /actuators

/temperature /light /sensor ... /leds /actuator ...

/a /b/farhrenheit /celsius

Figure 2: Resource hierarchy example of an abstract node.

The domain part of the URL also allows to be hier-

archically structured to match a virtual abstract struc-

ture or a real physical organization. URLs can give

insights on the location of devices inside a building

organization by decomposing it in sub-domains ac-

cording to buildings, ﬂoors and rooms.

3.2 RESTful APIs

RESTful APIs are really the communication and ap-

plication layers in the WoT by leveraging the HTTP

protocol. Unlike SOAP, HTTP is used as applica-

tion protocol and not only for transport. REST has

several advantages over SOAP by having less over-

head and being resource oriented, which ﬁts naturally

with physical objects. With the WoT paradigm, ev-

ery object or thing is embedding a Web server ex-

posing an API for acting with its sensing, actuating

and conﬁguration capabilities. Those services are lo-

cated through the URLs as explained previously. The

interaction with the resources is achieved by send-

ing HTTP requests containing a so-called HTTP verb

that can be one as follows: GET, POST, PUT and

DELETE. These verbs reﬂect actions that can be per-

formed on resources. The GET is for retrieving in-

formation, POST to modify information, PUT to add

information, and DELETE for removing information

on a resource. The GET and POST verbs are in the

context of WoT the most used ones. For example, one

will use the GET verb to read a sensor’s value, and

the POST one for actuating a relay.

A HTTP communication always consists of a re-

quest to a speciﬁc resource and a response, this for

any kind of operation. HTTP responses contain in

the header a code value expressing errors, exceptions

and successes. Each code has a well-known meaning

listed in the HTTP 1.1 speciﬁcations.

3.3 Events Notiﬁcations

In many scenarios some systems want to be informed

as soon as something happen on a monitored resource.

Instead of using a polling technique that is resource

consuming, the WoT relies on callbacks. In an event-

based system, the ﬁrst step is the registration of the

consumer at the producer. Working with things em-

bedding a REST Web server, we can expand the API

with methods dedicated to registration. A system in-

terested to be notiﬁed about a change of state on a re-

source will announce itself by providing the callback,

an URL representing a REST service on the consumer

side. We demonstrate this mechanism with a simple

example involving a BMS and a motion detector as

illustrated in ﬁgure 3.

Motion sensor

BMS

POST /register HTTP/1.1

Host:

motion.room5.ofﬁce

Content-Length: 24

Content-Type: text/plain

http://bms.ofﬁce/notify

Wait for motion

POST /notify HTTP/1.1

Host: bms.ofﬁce

Content-Length: 4

Content-Type: text/plain

Referer: motion.room5.ofﬁce

true

Figure 3: Event notiﬁcation mechanism with (1) consumer

registration step with callback notiﬁcation, (2) producer

value monitoring, (3) producer notiﬁcation to the consumer.

1 - The BMS will register at the motion sensor in

order to be notiﬁed when someone enters or leaves a

room. This is achieved by the BMS sending a HTTP

POST request to http://motion.room5.ofﬁce/register

containing the callback URL. 2 - The producer will

then internally watch its resource. 3 - Every time

the value changes the motion sensor will do a HTTP

POST request to the callback URL.

The steps 2 and 3 are repeated until the consumer

unregisters.

4 FROM KNX TO RESTful APIs

As reviously outlined with WoT paradigms, every ob-

ject is expected to embed a REST server offering an

API located through URLs for interaction. Unfortu-

nately this approach can not be applied as such to a

KNX network. Devices connected to the KNX net-

work have no IP address and therefore will not be

accessible by using URLs. In addition to this, KNX

IntroducingtheWeb-of-ThingsinBuildingAutomation-AGatewayforKNXInstallations

101

devices are very constrained and task oriented, which

makes it impossible for them to embed a Web server.

A way of ﬁlling this gap is by proposing a gateway

exposing devices functionalities in the form of REST-

ful APIs. The gateway will hide the complexity of the

KNX network and allow clients to interact with KNX

devices in a Web-of-Things manner. So, the devices

will appear to other participants of the WoT as they

would be embedding the API on themselves. Clients

will therefore be able to retrieve information from a

KNX network (e.g. to read a temperature value) or to

interact with the environment (e.g. to move blinds).

This chapter describes how devices functionalities

are mapped to URLs and RESTful services. Also,

we outline our discovery approach allowing clients to

identify which devices are accessible by using REST-

ful services and what are their capabilities.

4.1 KNX Application Layer

The KNX application layer, also known as KNX in-

terworking was thought to ensure interoperability be-

tween devices of various manufacturers. It standard-

izes the way how payload data inside telegrams have

to be structured and interpreted.

Like many systems dedicated to automation, the

interworking is based on so-called functional blocks

to describe system functionality (KNX, 2012). Logi-

cal parts of a device, such as a speciﬁc function are

symbolized by those functional blocks (FBs). We

can illustrate this principle with an example of a light

switch FB that is a logical function of a four channels

relay. A functional block is always attached only to

one device.

Functional

block

Light switch

OutputsInputs

Parameters

DPT I1

DPT I2

DPT P1

DPT O1

Datapoint type

Data type

Size

Format Coding Value range Unit

Figure 4: Functional block structure and datapoint type

composition.

As visible in the upper part of ﬁgure 4, FBs are

composed of a set of datapoints (DPs). Those data-

points are communication endpoints of devices allow-

ing access to the functions of a block (Neugschwandt-

ner et al., 2007). KNX administrators simply link

outputs and inputs together for associating devices.

Datapoints are also standardized in terms of syntax

and semantics as visible in the lower part of ﬁgure 4,

and also organized in several categories depending on

their FBs purposes. For example, our light switch pro-

vides the DP ”switch on off” allowing to turn the light

on or off. By knowing the datapoint type, one can

ﬁnd in the KNX speciﬁcation all information regard-

ing the datapoint, including the format, coding, value

range and unit.

The KNX protocol identiﬁes two categories of

DPs: group objects (GOs) and interface object prop-

erties (IOPs). The GOs are endpoints involved in

group communications between producers and con-

sumers basing on a multicast approach. This type of

DP is used by sensors, actuators and control devices

for exchanging information. On the other hand, IOPs

are only for conﬁguration and management purposes.

One can address an IOP only with the physical ad-

dress of the device.

4.2 ETS export Archive

The KNX association has developed the ETS (En-

gineering Tool Software) software for conﬁguring a

KNX infrastructure. With this software, administra-

tors and engineers have the possibility to create the

building hierarchy, the network topology, and ﬁnally

to create group objects that will represent functional-

ities between devices. At this time, no other compa-

rable software exists, so that every KNX installation

must be conﬁgured with ETS. ETS exports projects in

an archive composed of multiple XML ﬁles, as shown

in ﬁgure 5. The knx master.xml contains the descrip-

tion of all the datapoint types. The network topol-

ogy, building organization and group addresses are

stored in the 0.xml ﬁle. Finally, there is a folder for

every manufacturer, containing a XML ﬁle for each

device type composing the network. The device ﬁle

informs about the available datapoints on the device.

This archive, being zipped without security, contain-

ing XML ﬁles easily understandable allows to import

all the network knowledge into other applications. By

applying a XSL transformation to the XML ﬁles in-

side the archive, we are able to centralize all informa-

tion necessary for our gateway into one single XML

ﬁle.

ICINCO2013-10thInternationalConferenceonInformaticsinControl,AutomationandRobotics

102

Figure 5: ETS project archive structure.

4.3 Datapoints to REST

As previously explained, access to functionalities in

a KNX network is done via group objects, which

are compositions of datapoints and a group address.

In the elaboration of the gateway, we need to match

group objects to REST services for allowing in-

teraction with KNX devices. For doing this, we

make use of the XSLT output as visible in listing 1.

By taking into consideration some ﬁelds of the

XML, we are able to compose an URL identifying

a speciﬁc group object. For example, the datapoint

shown in listing 1 would result in following URL:

http://heating.ofﬁce005.ground.leso.epﬂ.ch/dpt switch.

The domain part is composed of the physical lo-

cation of the device inside the building, completed

by the domain name of the organization. The

last part of the URL that represents the action to

perform is the datapoint type name. We can now

easily link group objects to URLs by following this

rule: http://<GROUP NAME>.<LOCATION>.

<ORGANIZATION DOMAIN>/<DATAPOINT>.

Listing 1: Datapoint XML representation after XSL trans-

formation.

< d a t a p o i n t s t a t e B a s e d =” t r u e ”

name=” H e a t i n g ” d e s c =” S t a t u s ”

mainNumber= ” 1 ”

p r i o r i t y =”Low” a ctio n N a m e = ” DPT Swit ch ”

a c t i o n D e s c = ” on / o f f ” d pt D e s c =”1− b i t ”

d p t B i t s S i z e =” 1 ”

l o c a t i o n = ” O f f i c e 0 0 5 . g r o u n d . LESO”>

6195

< / k n x A d d r e s s>

< / d a t a p o i n t>

Our objective is here to allow the BMS to pull

state values and to perform actions on the KNX net-

work by sending HTTP requests to the gateway. A

HTTP GET request will result in the HTTP response

containing the actual value of the group object inside

the payload data. For changing a state, one will send a

HTTP POST request containing the new value inside

the payload data.

Representing the structural organization of the

building inside the domain part of the URL opens a

new dimension. By acting this way, we can hide the

fact that the device is actually in a KNX network and

not directly connected to an IP network. For users

of the system, the device seems to be an IP one with

its own DNS entry directly pointing to it. However,

this brings a certain complexity for the DNS sys-

tem as it musts contain entries matching with KNX

groups. For example, the DNS equivalence of the

group heating located in room ofﬁce005 of the ground

ﬂoor in the leso building, giving the DNS entry heat-

ing.ofﬁce005.ground.leso has to redirect to the gate-

way.

4.4 Events

To avoid control systems being forced to imple-

ment a polling strategy for observing changes of

states, our gateway offers a notiﬁcation mechanism

allowing to observe every group object. Here, the

events notiﬁcations principle of the Web-of-Things

is applied. Every URL identifying a group ob-

ject is extended with two sub-resources for regis-

tration and unregistration. The register and un-

type as sub-resource. In our previous example, the

URLs for registration and unregistration will be as

follows: http://heating.ofﬁce005.ground.leso.epﬂ.ch/

dpt switch/[un]register. The gateway holds internally

a list of all the consumers registered for every group

object. For every change of state of a group object,

the gateway checks its list of listeners, and will then

perform the notiﬁcation through the callback of the

consumers.

4.5 Discovery

Before communicating with KNX devices, a sys-

tem has ﬁrst to discover what group objects are

available on the gateway. A very simple manner

would be to provide a single list informing about

all group objects. Such an approach is obviously

not well adapted due to its poor structure and the

need to transmit the whole list for every discovery

request. Here, we expand our concept of building-

composition structured DNS. In addition of keeping

entries for groups, it does also have entries for the

sub-domains composing the URLs. For example, it

will store entries like ground.leso.epﬂ.ch. By call-

ing http://ground.leso.epﬂ.ch, the DNS server redi-

rects the request to the gateway. The gateway will

perform a lookup in the XML ﬁle to ﬁnd all children

and will respond with a JSON structured message.

IntroducingtheWeb-of-ThingsinBuildingAutomation-AGatewayforKNXInstallations

103

Once a group has been located, the available dat-

apoints can be known by adding the placeholder

* instead of the datapoint identiﬁer. The gateway

will answer with a JSON payload describing the

datapoints one can interact with, as visible in list-

ing 2. The resulting URL structure is as follows:

http://<GROUP NAME>.<LOCATION>. <OR-

GANIZATION DOMAIN>/*.

Listing 2: JSON message structure example of a data-

point description for http://heating.ofﬁce005.ground.leso.

epﬂ.ch/*.

{ ” d a t a p o i n t i n f o ” : ”1− b i t ” ,

” d a t a p o i n t t y p e ” : ” DPT Switch ” ,

” d e s c r i p t i o n ” : ” on / o f f ” ,

” b i t s s i z e ” : 1 ,

” d a t a p o i n t n u m b e r ” : ” 1 . 0 0 1 ” ,

” u r l ” : ” h t t p : / / h e a t i n g . o f f i c e 0 0 5 .

gr o u nd . l e s o . e p f l . ch / d p t s w i t c h ” }

5 IMPLEMENTATION

We provide here more details on a practical imple-

mentation of the gateway according to the principles

exposed in Section 4. We voluntary restricted the im-

plementation to only state based group objects which

are used by BMS.

5.1 Platform

We selected as hardware platform the Raspberry Pi

model B which is low-cost and offers enough comput-

ing power for running our gateway. This tiny micro-

computer (Ras, 2013) (85.6mm x 56mm x 21mm)

embeds an ARM1176JZFS CPU running at 700MHz

with 512MB of RAM. The model B offers an Ethernet

connectivity with an RJ45 port. It is composed of a

SD card reader, two USB ports, one HDMI video port

and a RCA video output. This module can be con-

sidered as low-power by consuming only about 4W,

powered at 5V over a micro USB port. The Raspberry

Pi can be operated by many Linux systems installed

on a SD card plugged into the device. Any kind of

software compatible with the ARM processor can be

installed on it, like Java, MySQL and many others.

5.2 Architecture

Our implementation relies on the Calimero 2.0 Java

library (Cal, 2013). This library provides Java classes

and methods for KNXnet/IP tunnel communications,

and datapoint object representation allowing develop-

ers to build applications dedicated to KNX infrastruc-

tures. The Web part of our implementation is com-

posed of a Java servlet running on a Jetty server (Jet,

2013). We opted for Jetty instead of other common

Java Web servers like Tomcat, Glassﬁsh, JBoss or

Grizzly because of Jetty being easily embeddable on

low-resources hardware thanks to its lightweight im-

plementation. All components of the implementation

are open source and free.

As shown in ﬁgure 6, we base our implementation

on several logical modules shared in different scenar-

ios of use. The ﬁrst one is the conﬁguration of the

gateway, where the administrator will provide all nec-

essary information for proper running. Once the gate-

way being conﬁgured, it enters in its normal operation

where it can serve requests for manipulating group

objects. We here detail the role of every module.

The Datapoints ﬁle act as database even only con-

sisting of XML tags. This ﬁle is on the heart of the

application and holds all the mandatory information

for communication with the KNX devices. It con-

tains a description of every group object reachable on

the network, indicating the datapoint type, the group

address, and other informal data about the group ob-

ject. This ﬁle also stores conﬁguration data provided

through the Web conﬁguration page.

The Web server stands as entry point of the appli-

cation. It implements the doGet() and doPost() meth-

ods for handling the HTTP requests. The ﬁrst step is

to decode the URL in order to identify which action is

requested on which group object, as it could be a di-

rect interaction or a notiﬁcation registration message.

Once the operation being resolved, it acts as controller

and dispatches the request to the right modules. At the

end of processing, it will respond either with a value

corresponding to the GET read request, or only with

the HTTP response code in the case of a POST.

The XML generator processes the ETS project

archive for generating the XML datapoints ﬁle. It

ﬁrst decompresses the archive and then applies the

XSL stylesheet to the project. All special characters

as accents are removed during this processing, as they

can not be present in URLs. At end, the XML ﬁle is

placed inside the resource directory of the Web server.

The DNS manager is responsible of adding DNS

record entries representing groups. This is performed

with the DNSJava library (DNS, 2013) offering meth-

ods for managing zones and records of a DNS server.

The Datapoint locator acts as query engine for

the datapoints ﬁle. It can lookup speciﬁc group ob-

jects according to the datapoint type, group name and

location, and then returns them in the Calimero data-

point object representation. It is also used for retriev-

ing all the possible domain names for accessing the

group objects, used by the DNS manager for adding

ICINCO2013-10thInternationalConferenceonInformaticsinControl,AutomationandRobotics

104

HTTP

server

DNS server

KNXnet/IP Gateway

discovery

Calimero 2.0

DNS

manager

KNX

comm

http://knxgateway.epﬂ.ch

KNX - WoT Gateway

192.168.1.3

epfl.ch

192.168.1.212

C:\epfl.knxproj

Load

Submit

Locate

root

**********

DNS server IP

DNS main domain

DNS user

DNS password

KNXnet/IP GW IP

ETS archive

KNXnet/IP

Gateway

KNXnet/IP Tunneling

Datapoint object representation

Calimero 2.0

REST

client

HTTP

server

Datapoint

locator

datapoints.xml

KNX

comm

KNX Twisted Pair

KNXnet/IP

Gateway

HTTPDP

Gateway conﬁguration Gateway WoT<->KNX

datapoints.xml

XML

generator

Events

manager

Figure 6: Overall KNX-WoT gateway architecture illustrating the logical modules for two scenarios: gateway conﬁguration

(left part) and gateway normal operation (right part).

entries on the DNS server. In the case of a client will-

ing to discover the available datapoints, the Datapoint

locator can answer with all sub-domains or with all

datapoints descriptions of a group.

The KNX comm represents an interface to the

KNXnet/IP network. This module can discover

KNXnet/IP gateways by sending multicast messages,

thus avoiding administrators to look after the IP ad-

dress of the gateway, some times hard to ﬁnd because

of being DHCP conﬁgured. Further to this, it then

handles the tunnel connection, allowing to talk with

the KNX network. By listening to the network, it will

notify the Events manager of incoming telegrams that

might concern some consumers. Activating a cache

feature can avoid to overload the KNX network due

to many clients reading the same group object.

For managing the notiﬁcation paradigm, we in-

troduce an Events manager. This module stores

in an associative table the consumers registered on

group objects for notiﬁcations. Triggered by the KNX

comm module, it will lookup if consumers are regis-

tered for the group object having undergo a change of

state, and then launches the notiﬁcation by calling all

related callbacks.

6 EVALUATION

We evaluated the capabilities and limitations of the

implemented gateway through several tests. In order

to have realistic feedbacks, we performed our tests on

a building already equipped with a KNX installation.

From the evaluation results, we also discuss some im-

provements of the gateway that would be beneﬁcial

for BMS.

6.1 Performance

To establish the performances of our gateway, we de-

cided to measure various key-values such as: max-

imum number of requests per second, maximum si-

multaneous requests, notiﬁcation reaction time (from

the action on the KNX device until producer notiﬁca-

tion) and processing time of the ETS project archive

(during conﬁguration). All our measurements are

done with an existing KNX installation of the 4 ﬂoors

ofﬁce LESO building located on the EPFL campus in

Lausanne, Switzerland. The installation features 265

devices, distributed in 765 groups, with a total of 795

group objects and represents an average installation

that can be found in many buildings.

Table 1: Gateway performance measured on a real-life

KNX installation running 265 devices.

Measure type Result

ETS archive processing time 30 [min]

Maximum HTTP requests per second 45

Maximum simultaneous HTTP requests 620

Average event reaction time 33 [ms]

6.2 Discussion

Table 1 summarises the performance of the gateway

implemented on a Raspberry Pi as described in Sec-

tion 5.1. The ETS archive processing time is quite

long, mainly due to the XSLT that is extremely re-

source consuming. However, as this operation has

only to be performed during the conﬁguration of the

gateway, we can assume that it is not an important

issue. The maximum HTTP requests per seconds is

actually bottlenecked by the twisted pair of the KNX

IntroducingtheWeb-of-ThingsinBuildingAutomation-AGatewayforKNXInstallations

105

network offering only 9600b/s. The maximum simul-

taneous HTTP requests is limited by the Raspberry

Pi. Nonetheless, we believe that the measured value

is largely sufﬁcient for common BMS operation. Fi-

nally, we observed a fast event response time that

would typically allow a BMS to function in reactive

mode. We can see that all the results are suitable for

such an installation and that the Raspberry Pi has to be

considered as an alternative to classical PCs running

gateways or serving as middleware.

A potential limitation of our proposition lies in

the DNS approach which implies access to the DNS

server of the host IP network. Such access may be

restricted by security policies in which case a ded-

icated DNS server has to be made available for the

gateway. A second issue is related to the security of

our gateway where currently no authentication is im-

plemented. An authentication layer based on access

lists could be a solution to this.

Some developers have actually built small appli-

cations interacting with the KNX devices through our

gateway, this in various languages. Their feedback

were positive, showing the beneﬁts of leveraging on

standardized and well-accepted protocols to reduce

the integration time of KNX devices on a BMS. Some

developers asked us to extend the event notiﬁcation

system for recording on the gateway a series of val-

ues, and to be notiﬁed once the buffer being full or af-

ter a period of time elapses. This can be implemented

by adding a storage module to the gateway, based on

a small database such as SQLite or MySQL.

7 CONCLUSIONS

In this paper, we explored a new way allowing build-

ing management systems and information system to

interface KNX installations by leveraging on well-

known standards like HTTP and RESTful APIs. In-

stead of having to implement the KNX network proto-

col on the BMS, developers beneﬁt from the simplic-

ity of use of the WoT, thus facilitate the integration of

heterogeneous networks. We believe that BMS will

have to dialogue with various networks in near future

because of new technologies appearing, like Enocean

and others. In addition to this, our results show that

the Raspberry Pi is enough powerful to run gateways.

Future works cover security aspects by adding an

authentication layer and optional encryption of data

to prevent misuse. A centralization of data on the

gateway will also be explored, allowing BMS to look

for past data used in many scenarios where user be-

haviour plays a primary key role. Finally, we will

investigate the feasibility of building a direct connec-

tion to the KNX twisted pair in the gateway to elimi-

nate the need of the KNXnet/IP module. The software

running on the gateway can be made available for any

scientiﬁc research project upon request to the authors.

REFERENCES

(2012). KNX Advanced Course Speciﬁcation. KNX Asso-

ciation, february 2012 edition.

(2013). Calimero 2.0. http://calimero.sourceforge.net/.

(2013). Dnsjava library. http://www.xbill.org/dnsjava/

(2013). Jetty server. http://jetty.codehaus.org/jetty/

(2013). Rapberry pi. http://www.raspberrypi.org/.

Aijaz, F., Chaudhary, M., and Walke, B. (2009). Perfor-

mance comparison of a soap and rest mobile web

server. In Proc. of the Third International Conference

on Open-Source Systems and Technologies (ICOSST

2009).

Bovet, G. and Hennebert, J. (2012). The web-of-things con-

quering smart buildings. volume 10s/2012, pages 15–

19. ElectroSuisse.

Groba, C. and Clarke, S. (2011). Web services on em-

bedded systems – a performance study. In 2010 8th

IEEE International Conference on Pervasive Comput-

ing and Communications Workshops PERCOM Work-

shops, volume 3, pages 726–731. IEEE.

Guinard, D. (2011). A Web of Things Application Architec-

ture – Integrating the Real-World into the Web. PhD

thesis, ETHZ.

Guinard, D., Trifa, V., Mattern, F., and Wilde, E. (2011).

From the internet of things to the web of things : Re-

source oriented architecture and best practices. In Flo-

rianEditors, editor, Architecting the Internet of Things,

pages 1–34.

Hamad, H., Saad, M., and Abed, R. (2010). Performance

evaluation of restful web services. In Computer Engi-

neering, volume 1, pages 72–78. Computer Engineer-

ing Department.

Kastner, W., Neugschwandtner, G., and K

ogler, M. (2005).

An open approach to eib/knx software development.

In Fieldbus Systems and their Applications, pages

255–262.

Kindberg, T. and al. (2002). People, places, things: Web

presence for the real world. In Mobile Networks and

Applications, volume 7, pages 365–376. Building.

KonnexAssociation (2004). Knx speciﬁcation.

Neugschwandtner, M., Neugschwandtner, G., and Kast-

ner, W. (2007). Web services in building automation:

Mapping knx to obix. In Proc. of the 5th IEEE In-

ternational Conference on Industrial Informatics, vol-

ume 1, pages 87–92.

Ostermaier, B., Schlup, F., and R

omer, K. (2010). Web-

plug: A framework for the web of things. In Proc. of

the First IEEE International Workshop on the Web of

Things (WOT2010), Mannheim, Germany.

ICINCO2013-10thInternationalConferenceonInformaticsinControl,AutomationandRobotics

106