Offering Web-of-Things connectivity to building networks · PDF fileOffering Web-of-Things Connectivity to Building Networks ... connected to building networks like KNX, BACnet or

Offering Web-of-ThingsConnectivity to Building Networks

Gerome BovetTelecom ParisTech46 Avenue BarraultParis, 75013 [email protected]

Jean HennebertUniversity of Applied SciencesFribourgBd. de Perolles 80Fribourg, 1700 [email protected]

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies are notmade or distributed for profit or commercial advantage and that copies bearthis notice and the full citation on the first page. Copyrights for componentsof this work owned by others than ACM must be honored. Abstracting withcredit is permitted. To copy otherwise, or republish, to post on servers or toredistribute to lists, requires prior specific permission and/or a fee. Requestpermissions from [email protected]’13 Adjunct, September 8–12, 2013, Zurich, Switzerland.Copyright c© 2013 ACM 978-1-4503-2215-7/13/09...$15.00.

http://dx.doi.org/10.1145/2494091.2497590

AbstractBuilding management systems (BMS) are nowadayspresent in new and renovated buildings, relying ondedicated networks. The presence of various buildingnetworks leads to problems of heterogeneity, especially fordeveloping BMS. In this paper, we propose to leverage onthe Web-of-Things (WoT) framework, using well-knownstandard technologies of the Web like HTTP andRESTful APIs for standardizing the access to devices seenfrom an application point of view. We present theimplementation of two gateways using the WoT approachfor exposing KNX and EnOcean device capabilities asWeb services, allowing a fast integration in existing andnew management systems.

Author KeywordsBuilding networks, Web-of-Things, EnOcean, KNX,Gateways

ACM Classification KeywordsD.2.11 [Software Engineering]: Software Architectures.;H.4.3 [Information Systems Applications]:Communications Applications.

IntroductionBuilding management systems (BMS) are nowadays verycommon in different types of buildings such as offices,

Session: WoT 2013: Fourth International Workshop on the Web of Things

UbiComp’13, September 8–12, 2013, Zurich, Switzerland

1555

manufactures or even private households. Those BMS relyon a variety of sensors and actuators linked with eachother forming a dedicated building network. At origin,only the temperature of a building was controlled in avery simple way over global or room-wise thermostats,targeting a threshold temperature value. Since then,motivated by raising energy costs and by the growingimportance of the comfort, new strategies involving otherkind of devices and being much more complex have beendeveloped. New generation of BMS are taking advantageon many kinds of sensing and actuating devices, formanaging the HVAC (Heating, Ventilation and AirConditioning), the lightening, doors opening, windows andblinds control, and also for restricting access. Thisconstellation of devices has led buildings to become”smart” and are now relying on information systemsconnected to building networks like KNX, BACnet orLonWorks. The most installed network in Europe is KNX.The EnOcean network is gaining importance in buildings,based on energy harvesting wireless technologies [?].

Unfortunately, those building management networks donot propose any standardization from an application pointof view to dialogue with interconnected devices. Becauseof this situation, BMS combining multiple networks areuncommon. Buildings where the network should evolvewith new devices that are not compatible with the actualone, or where extending the wiring is not feasible becauseof physical constraints are good examples of the resultingnetwork heterogeneity [?], as illustrated in figure 1. Evenif gateways encapsulating the specific building telegramsin IP packets are existing, it actually exists no standard atthe application level, having as consequence every buildingnetwork protocol to be understood and implemented bythe BMS.

BMS

IP GatewayIP Gateway

IP Gateway

IP B

ackbone

Figure 1: Network heterogeneity in smart buildings

Looking now at Internet and Web technologies, Webservices are nowadays trendy and widespread, allowinginteroperability between heterogeneous informationsystems (IS). Their key benefits are in being platformindependent and using well-known standards for structuredexchange. The Simple Object Access Protocol (SOAP) isan example of Web service protocol specification relyingon Extensible Markup Language (XML) for its messageformat and Hypertext Transfer Protocol (HTTP) formessage negotiation and transmission [?]. Unfortunately,because of the large overhead of XML and the complexityof the service description language WSDL, SOAP is notwell suited for accessing sensors and actuators consideredas things. On the other hand, the resource orientedarchitecture (ROA) part of the emerging Web-of-Things(WoT) concept, offers new ways for accessing things,which are more suited for BMS [?].

In this paper, we propose an approach for KNX andEnOcean networks to become homogeneous, allowingaccess to devices in a Web-of-Things manner. By takingadvantage of the bests practices of the WoT, weguarantee a fast integration of both building networks inevery control system. In addition to this, we putimportance on the fact that our gateways must be simple



1556

to use, low-cost and easily integrable in an existingenvironment.

This paper is organised as follows. The next section refersand summarizes related work. The application of theWeb-of-Things to the KNX and EnOcean networks isdiscussed in the third section. The fourth describes theimplementation of the gateways. Performance tests in aexisting buildings are shown in the fifth section. The sixthsection concludes our paper and provides insights onfurther research.

Related workCooltown [?] is one of the early projects consideringpeople, places and things as Web resources. A newinteraction approach using HTTP GET and POST formanipulating things was introduced. Lately, with theevolution made in embedded systems, it was possible toembed Web servers directly on sensors and actuators. TheWebPlug [?] framework introduce so-called mashups,relying on the Web-of-Things paradigm, where sensorsand actuators play a central role.

Trying to ease the development of applications using KNXdevices has been explored in different works. A firstattempt was realized with the BCU SDK [?], whichconsists of a script generating C++ classes representingdevices capabilities. A more Web oriented approach hasbeen realized in [?]. The principle was to expose KNXfunctionalities as Web services by using the oBIX (OpenBuilding Information Exchange) standard, which is aspecial XML schema for representing building data andoperations. Unfortunately, oBIX is not at all widespread inBMS, probably because of its relatively complex XMLschema. In addition to this, the proposed implementationdoes not allow an easy integration of the gateway in an

existing environment, requiring an important configurationeffort for large networks. The openhab [?] project is aBMS system offering interfaces to various buildingnetworks, including KNX. An integration of EnOcean isactually under development. Although being a completesolution, it does not allow for importing a KNXconfiguration nor exposing stored data through RESTservices. Additionally the project is quite complex andasks for having a deep knowledge of its working. Ourapproach tackles these limitations by taking advantage ofthe WoTs simplicity and by being highly integrable inexisting KNX infrastructures.

Mapping building networks to RESTful APIsAs required when using the WoTparadigm, every object isexpected to embed a REST server offering an API locatedthrough self-descriptive URLs. This vision canunfortunately not be applied as such to building networks.Devices connected to KNX or EnOcean networks are notIP-enabled and will therefore not be accessible throughURLs. In addition to this, those devices are veryconstrained and task oriented, which makes it impossiblefor most of them to embed a Web server. We propose tofill this gap by introducing gateways exposing devicesfunctionalities in the form of RESTful APIs. The role ofthose gateways is to hide the complexity of each buildingnetwork and to allow clients interacting with attacheddevices in a Web-of-Things manner. In other words, thedevices will appear to other participants of the WoT asthey would be embedding the API on themselves.

From KNXKNX interworking, the KNX application layer, wasthought to ensure the interoperability between devicesfrom various manufacturers. It standardizes the structureand interpretation of telegrams payload data. As it is the



1557

case for many automation systems, system functionality isdescribed by so-called functional blocks which ensures theinterworking [?]. Logical parts of a device, such as aspecific function are symbolized by those FunctionalBlocks (FBs). This principle can be illustrated with anexample involving a light switch FB that is a logicalfunction of a four channels relay. A functional block isalways attached to only one device.

Functional block

Light switch

OutputsInputs

Parameters

I1

I2

P1

O1DPT I1

DPT I2

DPT P1

DPT O1

Datapoint type

Data type Size

Format Coding Value range Unit

Figure 2: Functional block structure and datapoint typecomposition

As illustrated on figure 2, FBs are composed of a set ofdatapoints (DPs). Those datapoints are communicationendpoints of devices allowing access to the functions of ablock [?]. The inputs (DPT I) stand for states that can bealtered by other devices. The parameters (DPT P) areconfigured by administrators or engineers for changing the

behaviour of the FB. At last, the outputs (DPT O) giveinsights of the actual state of the block. Datapoints arealso standardized in terms of syntax and semantics asvisible in the lower part of figure 2, and are also organizedin several categories depending on their FBs purposes. Forexample, our light switch provides the DP switch on offallowing to turn the light on or off. By knowing thedatapoint type, one can find in the KNX specification allinformation regarding the datapoint, including the format,coding, value range and unit. The KNX protocol identifiestwo categories of DPs: group objects (GOs) and interfaceobject properties (IOPs). The GOs are endpoints involvedin group communications between producers andconsumers basing on a multicast approach. This type ofDP is used by sensors, actuators and control devices forexchanging information. On the other hand, IOPs are onlyfor configuration and management purposes. One canaddress an IOP only with the physical address of thedevice.

The Engineering Tool Software (ETS) was developed bythe KNX association for configuring a KNX infrastructure.With this software, administrators and engineers have thepossibility to create the building hierarchy, the networktopology, and finally to create group objects that willrepresent functionalities between devices. At the time ofwriting this article, ETS is the most used tool for KNXconfiguration in professional installations. As shown infigure 3, ETS exports projects in an archive composed ofmultiple XML files. The knx master.xml file contains thedescription of all the DP types. The network topology,building organization and group addresses are stored inthe 0.xml file. Finally, there is a folder for everymanufacturer, containing a XML file for each device typecomposing the network. The available DPs on a deviceare contained in the device file. Luckily, this archive is



1558

zipped without any security and contains easilyunderstandable XML files, which allows developers toimport all the network knowledge inside third-partyapplications. As illustrated in figure 3, we suggest here toperform a XSL transformation on the different filesincluded in the archive to aggregate all useful informationfor our gateway into one single XML file.

ETS project archive

knx_master.xml

0.xml Product ID.xml

Manufacturer IDProject ID

datapoints.xmltransform.xsl

Figure 3: ETS project archive structure

As we previously pointed out, access to functionalities in aKNX network is achieved via group objects, which are acombination of datapoints and a group address. Foroffering interaction with KNX devices, we match groupobjects to REST services. This is obtained by using theXSLT output issued from the XSL transformation, whichallow us to to compose an URL identifying a specificgroup object. For example, following URL would be linkedto the data point shown in listing 1:http://heating.office005.ground.leso.epfl.ch/dpt switch.The domain part is composed of the physical location ofthe device inside the building, completed by the domainname of the organization. The last part of the URL thatrepresents the action to perform is the datapoint typename. We can now easily link group objects to URLs byfollowing this rule:

http://<group name>.<location>.<organization domain>/<datapoint>.

Listing 1: Datapoint XML representation after XSLtransformation

<d a t a p o i n t s t a t e B a s e d=” t r u e ”name=” Heat ing ” d e s c=” S t a t u s ”mainNumber=”1”p r i o r i t y=”Low” actionName=” DPT Switch ”a c t i o n D e s c=”on/ o f f ” dptDesc=”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 . ground . LESO”>

<knxAddress t y p e=” group ”>6195

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

Since now, clients can interact with the KNX devicesthrough the gateway by sending HTTP requests. A GETrequest will result in the gateway returning the actualstate of the DP. On the other side a POST requestcontaining the new state inside the payload data willresult in the KNX device changing its state. Representingthe structural organization of the building inside thedomain part of the URL opens a new dimension. Byacting this way, we can hide the fact that the device isactually in a KNX network and not directly connected toan IP network. For users of the system, the device seemsto be an IP one with its own DNS entry directly pointingto it. However, this brings a certain complexity for theDNS system as it musts contain entries matching withKNX groups redirecting requests to the gateway.

From EnOceanEnOcean also works with its own application layerensuring compatibility between devices. It relies on the



1559

EnOcean Equipment Profile (EEP) providing informationabout the type of telegram and the representation of thedata. Four types of telegrams are defined: RPS forRepeated Switch telegrams sent by push buttons, 1BS forOne Byte telegrams sent by contacts and switches, 4BSfor Four Byte telegrams sent by various types of sensors,and the VLD for Variable Length telegrams. EEPs arespecified in an XML file provided by the EnOcean alliancethat holds the description of all profiles, including framecomposition, structure of data and meaning of data.Furthermore, every field of data of an EEP is identified bya so-called shortcut, such as TMP for temperature orHUM for humidity. The listing 2 shows the XMLdescription of a datafield.

Listing 2: Datafield XML representation of an EEP

<d a t a f i e l d><data>Temperature</ data><s h o r t c u t>TMP</ s h o r t c u t><d e s c r i p t i o n>

Temperature ( l i n e a r )</ d e s c r i p t i o n>

DB 1 Temperature (8 b i t ) −4 0 . . . 0 C ,l i n e a r n = 2 5 5 . . . 0

168<ra ng e><min>255</min><max>0</max></ r an ge><s c a l e><min>−40</min><max>0</max></ s c a l e> C

</ d a t a f i e l d>

Mapping EnOcean capabilities is much more complicatedthan KNX, even if the configuration of the network is verysimple by just pairing devices together. Indeed there is no

central management of the network like with ETS.Forming groups of functionalities by pairing devices isachieved by the user putting the actuator in a teach-inmode, and triggering a learn telegram on the sensor thathave to drive the actuator. All the knowledge isdistributed in the actuators and it exists unfortunately noway to retrieve it, because of the sensors sendingbroadcast telegrams and most actuators being onlylisteners. The major drawback of this working is the factthat it is therefore not possible to automate the mappingof the EnOcean network capabilities to REST APIs. Analternative is to let the user reproduce the pairing ofdevices by using a Web application hosted on the gateway.However the process can be simplified for the user by thegateway listening to teach-in telegrams. Those telegramshold the EEP information, so that the gateway is now ableto parse and interpret the telegrams. The user can thenadd the detected devices to the gateway by furnishingadditional information such as a name and the location.This information is then used to map URLs with shortcutsof EEPs by following this rule:http://<sensor name>.<location>.<organization domain>/<shortcut>. This allowsclients to retrieve values of sensors by sending a HTTPGET request. However, as sensors are only senders andcan not listen to command telegrams, the gateway willreturn the last captured data. As there is no way todiscover actuators, their properties, like name, description,location and compatible EEPs have to be entirely filled inby the user. From now, it is possible for clients sending aHTTP POST request to actuate either by giving allshortcuts values of the EEP inside a JSON payload, or byspecifying the shortcut inside the URL as follows:http://<actuator name>.<location>.<organization domain>/[<shortcut>].



1560

Common functionsEach gateway is extended with common APIs, especiallyinteresting for reactive and proactive BMS. Developerscan discover what devices are accessible and what aretheir capabilities by sending GET requests to URLsrepresenting locations. The gateway will answer with aJSON indicating all sub-locations or devices inside thespecified location. One can also gather knowledge aboutthe available datapoints/shortcuts of a device by puttingthe .../* placeholder at the end of the URL.

For reactive BMS, we offer a notification mechanism,notifying them as soon as the value of a sensor changes.Clients must first register themselves on the interestingresource and indicate the callback that will have to becalled by the gateway. This is achieved by putting the.../[un]register keyword at the end of an URL pointing toan endpoint (e.g.http://air.office005.ground.leso/hum/register).

Finally, and dedicated to proactive BMS, we offer to themthe possibility to announce their needs for storing historydata on the gateway, and retrieving it later. For doing this,a client will interact with the .../storage sub-resource ofan endpoint. By putting the add/remove keywords (e.g.http://air.office005.ground.leso/tmp/storage/add), andby indicating the number of days data should be stored inthe case of an add command, clients have the possibilityto start or end storing data. For retrieving the storeddata, clients can either indicate the number of days onewants to go back in the history (i.e .../storage?days=X ),or by specifying a period of time with a start and an enddate (i.e. .../storage?from=X&to=Y ).

ImplementationIn this section, we provide further insights on theimplementation of both gateways by following theprinciple described in this article. For running ourgateways, we decided to use the Raspberry Pi model Bplatform that is low-cost and offers sufficient computingpower for our purposes [?].

EnOcean modesDue to the pairing principle of EnOcean, where sensorsare learned on actuators, our gateway has to provide twomodes of working: hybrid and bridge. Those behavioursare illustrated in figure 4. In the bridge mode it is thegateway’s role to drive actuators, according to virtualgroups created through the Web application. Thissimplifies the physical pairing of devices by needing onlyto learn the gateway on actuators. In this mode, thegateway will listen to telegrams sent by sensors, and if thesender of an incoming telegram is configured in bridgemode and is part of a group, the gateway will thenretransmit the original telegram by replacing the sender IDby its own. The drawback of this mode is at adding somelatency and essentially to be critical in case of thegateway failing (e.g. hardware problem, power outage,etc.), in which case users will no more be able to actuate(e.g switching lights, moving blinds, etc.) because ofsensors being not directly paired with actuators.

In order to avoid those problems, we implemented asecond mode of working, the hybrid mode. This time, notonly the gateway is learned in actuators, but also thesensors. This allows to both the gateway and sensors todrive actuators. By having a direct link between sensorsand actuators, we can provide a better user experience.As for the hybrid mode, the gateway will store eachcaptured telegram for providing state values to clients.



1561

Sensor

Actuator

Gateway

12

2

Sensor sends radio telegram

Gateway stores the telegram into the database if wished and notifies consumers

Gateway rebroadcasts radio telegram by replacing the sender ID

4

4Actuator receives the radio telegram andperforms the action

2

2Actuator receives the radio telegram andperforms the action

Bridge mode

Hybrid mode

3

1

3

Sensor sends radio telegram1

Gateway stores the telegram into the database if wished and notifies consumers

3

Figure 4: EnOcean gateway hybrid and bridge modes

ArchitectureThe KNX gateway relies on the Calimero 2.0 Javalibrary [?]. This library provides Java classes and methodsfor KNXnet/IP tunnel communications, and datapointobject representation allowing developers to buildapplications dedicated to KNX infrastructures. For theEnOcean gateway, as it currently exists no similar library,we had to develop our own library for capturing, parsingand sending telegrams over an USB dongle. The Web partof our implementation is based on Java servlets runningon a Jetty server [?]. We argue our choice for Jettybecause it is easily integrable on low-resources equipmentsthanks to its lightweight implementation, compared toother Web servers like Tomcat, Glassfish or Grizzly.MySQL was chosen as database engine. All componentsof the implementation are open source and free.

As illustrated on figure 5, our implementation relies onseveral logical modules very similar for each 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 WoT <-> KNX

Notification

manager

Storage

manager

Gateway WoT <-> EnOcean

REST

client

HTTP

server

EnOcean

comm

HTTPEEP

Notification

manager

Storage

manager

Capturing telegrams

Parsing telegrams

Sending telegrams

EnOcean library

EnOcean

USB dongle

Figure 5: Architecture of the KNX and EnOcean gateways

EvaluationThe performance and limitations of the implementationswere evaluated by several tests. For having realisticfeedbacks we performed our tests on two buildings alreadyinstalled with KNX and EnOcean networks. Starting fromthe evaluation results, we also propose some improvementsof the gateway that could valuable for BMS.

KNX performanceFor determining the gateway’s performance, we selectedto measure some key-values, like maximum number ofrequests per second, maximum simultaneous requests,notifications reaction time (i.e from the action on theKNX device until notification) and processing time of theETS project archive during configuration. We base ourmeasurements on an existing KNX installation of the four



1562

floors office LESO building located on the EPFL campusin Lausanne, Switzerland. This installation features 265devices, distributed in 795 group objects and represents anaverage installation that can be found in several buildings.

Measure type Result

ETS archive processing time 30 [min]Maximum HTTP requests per second 45Maximum simultaneous HTTP requests 620Average event reaction time 33 [ms]

Table 1: KNX gateway performance measured on a real-lifeKNX installation running 265 devices

EnOcean performanceFor the EnOcean gateway, we measured the samekey-values as for KNX apart the ETS archive processingfile. The gateway was installed at the College ofengineering, Fribourg, Switzerland, where an office roomof 20m2 is equipped with 7 sensors, 3 lights/blindsswitches and 4 actuators. This lab office is occupied bythree people and represents a typical room that can befound in office buildings.

Measure type Result

Maximum HTTP requests per second 82Maximum simultaneous HTTP requests 631Average event reaction time 29 [ms]

Table 2: EnOcean Gateway performance measured on areal-life EnOcean installation running 14 devices

DiscussionTable 1 summarises the performance of the KNX gatewayrunning on a RaspberryPi. The XSLT being extremelyresource consuming, this is reflected when processing theETS archive file that needs quite a long time. However, as

this operation has only to be performed during theconfiguration of the gateway, we can assume that it is notan important issue. The maximum HTTP requests perseconds is actually bottlenecked by the twisted pair of theKNX network offering only 9600b/s. The maximumsimultaneous HTTP requests is limited by the RaspberryPi. Nonetheless, we believe that the measured value islargely sufficient for common BMS operation. Finally, weobserved a fast event response time that would typicallyallow a BMS to function in reactive mode. From table 2,we can clearly see that all results are also satisfying forthe EnOcean. All limitations are due to the Raspberry Pireaching its limits of processing capabilities. Anyway, theRaspberry Pi is largely sufficient for such applications andhas to be considered as an alternative to classical PCsrunning gateways os serving as middleware.

Our approach implying access to the DNS server of thehost network can be considered as a hurdle. The access tothe DNS may be restricted by security policies in whichcase a dedicated DNS server has to be set up for thegateways.

Some developers where asked to build prototypical BMSapplications using KNX or EnOcean devices, and this invarious development languages. We obtained very positivefeedbacks showing the benefits of leveraging onstandardized and well-accepted protocols for reducingintegration time.

ConclusionsTaking inspiration on Web-of-Things paradigms, weinspected the feasibility and benefits of using well-knownWeb standards like HTTP and RESTful APIs forinterfacing building networks and building managementsystems. Our concepts and implementation were proven



1563

by being used on real installations, resulting in manypositive feedbacks coming from developers pointing to thesimplicity of use of WoT APIs.

From a global point of view, we believe that theintegration of heterogeneous networks can be muchsimplified using WoT approaches. We also believe that ina near future, BMS will have to handle various networksbased on different technologies, where smart gateways willprove their usefulness.

Our future works will cover security aspects of thegateway through authentication and encryption of data toprevent misuse. A mechanism for distributing the logicalrules coming from proactive BMS, potentially distributedin the cloud, will also be explored.

AcknowledgementsThe authors are grateful to the Swiss Hasler Foundationand to the RCSO grants from the HES-SO financing ourresearch in this exciting area of smart buildings.



1564

Documents

Offering Web-of-Things connectivity to building networks · PDF fileOffering Web-of-Things Connectivity to Building Networks ... connected to building networks like KNX, BACnet or