KNX ZigBee Gateway for Home Automation

4th IEEE Conference on Automation Science and Engineering Key Bridge Marriott, Washington DC, USA August 23-26, 2008 KNX ZigBee Gateway for Home Automation Woo Suk Lee, Seung Ho Hong Abstract The demand for wireless technology in home automation systems has recently been increasing due to several advantages such as installation cost reduction, easy placement, easy extension, aesthetic benefits, and mobile device connectivity. Among the many wireless technologies, ZigBee is one of the most useful for home automation; a wireless home networking system can be configured using ZigBee alone. Compatibility with conventional home networking systems that are based on wired media, however, is not supported. KNX is a mature protocol for wired media that is recognized as an international standard. This paper proposes a KNX ZigBee gateway to interface between KNX and ZigBee systems and thereby enable integration of wired and wireless home automation systems. W I. INTRODUCTION ireless technologies are becoming increasingly common in home and building automation systems. They are relatively cheap and easy to install as well as extend; moreover, they offer aesthetic benefits and enable mobile device connectivity [1,2]. Among the many existing wireless protocols, ZigBee is particularly well suited to home automation (HA). ZigBee is intended to enable reliable, cost-effective, low-power, wirelessly networked monitoring and control products based on an open standard [3], and wireless HA can be achieved using ZigBee alone. To enable the expansion of conventional wired control networks, however, we must maintain compatibility with current wired protocols, some of which confer advantages that might be leveraged by a wireless system. Among the many types of home networking systems that use wired media, KNX (Konnex) is recognized as an international standard. In this paper, we propose a method to interface between the wired KNX protocol and the wireless ZigBee protocol. A. Overview of the KNX system KNX is an international standard communication protocol for home automation (ISO/IEC 14543, CENELEC EN 50090, CEN EN 13321-1, GB/Z 20965) that is based on standard protocols for the EIB (European Installation Bus), BatiBus, and the EHS (European Home System). KNX supports Manuscript received March 10, 2008. This study was supported by a grant from the Basic Research Program of the Ubiquitous Sensor Network Research Center (USNRC) funded by the Gyeonggi Regional Research Center (GRRC) plan. Woo Suk Lee is with the Hanyang University, 1271 Sa-1 dong, Sangnok-gu, Ansan, Gyeonggi-do, Korea (phone: +82-400-4084; fax: +82-502-4084; e-mail: wsl@ hanyang.ac.kr). Seung Ho Hong is with the Hanyang University, 1271 Sa-1 dong, Sangnok-gu, Ansan, Gyeonggi-do, Korea (phone: +82-400-5213; fax: +82-502-4084; e-mail: shhong@ hanyang.ac.kr) several communication media, including twisted pair, power line, radio-frequency, and Ethernet (Fig. 1). It also supports several topologies and thus enables flexible installation. A distinguishing feature of KNX is its addressing system. In KNX, every bus is identified by both a physical and a group address. The physical address is used for initialization, programming, and diagnostic operations, while the group address is used for communication during regular operation. Devices use the group address to communicate via multicast. The same length of user data carried in a KNX telegram can be utilized in different ways. The information regarding utilization is not contained in the telegram. Instead, it is defined externally as DPT (Datapoint Type) for effective use of the bandwidth of the medium. DPT defines, for instance, one bit data as 24 kinds of usage, such as DPT_Switch (DPT number: 1.001), DPT_Bool(1.002), DPT_Enable(1.003) and so on. The current version of the standard defines 296 kinds of DPT [4]. Fig. 1. Supported medium and common object definitions of KNX B. Overview of the ZigBee system ZigBee is a low-rate, low-power, low-cost wireless networking protocol that is targeted toward automation and remote control applications and is designed to provide connectivity for equipment that will operate for as long as several years [5]. ZigBee defines three categories of devices according to their roles in the network: coordinator, router, and end devices. Devices are additionally classified into two types by functionality: Full Function Devices (FFD) and Reduced Function Devices (RFD). 978-1-4244-2023-0/08/$25.00 2008 IEEE. 750

User-defined data can be carried by a ZigBee network, but to guarantee compatibility among devices from different vendors, the ZigBee protocol defines standard device profiles. A HA profile has been published as the first in a series of profiles. In the current version of the HA profile, there are 31 device definitions for general devices, lighting devices, closure devices, HVAC devices, and intruder alarm system devices [6]. protocols were needed. Until the announcement of the new HA profile, the application layer of ZigBee provided very limited HA functionality. As a result, we considered the adoption of ZigBee as a network-layer protocol and KNX as an application-layer protocol. The network layer of ZigBee provides advanced technologies such as routing and security, and the application layer of KNX defines application-level functions and services for HA. To make full use of the three protocols, IEEE 802.15.4, ZigBee, and KNX, we took a systematic approach to merge them. One possible hierarchical structure that we formulated is shown in Fig. 3. The application, transport, and network layers of KNX are implemented on top of the ZigBee protocol stack, and an interface layer enables interactions between the two protocols. This is called the KNX over ZigBee system. Fig. 2. Outline of the ZigBee stack architecture II. KNX ZIGBEE INTERFACE METHODS Devices designed for networked operation tend to base their communication protocols on the characteristics of control networks, which make the introduction of new technologies difficult. Newly proposed technologies, such as communication protocols, should therefore support compatibility with existing technologies. Even within the field of HA, many communication protocols and systems exist with which ZigBee must be compatible. In this paper, we selected KNX as a representative HA protocol because KNX is a merger of other HA standards and is a relatively mature protocol that has been adopted as an international standard. An interface between KNX and ZigBee will enable ZigBee systems to support the conventional KNX protocol, and will allow KNX systems to support new wireless technologies, including routing and security, which were not previously supported. This paper proposes a method for interfacing between KNX and ZigBee, which we call the KNX ZigBee gateway. Fig. 3. Hierarchical layered structure of KNX over ZigBee Within KNX over ZigBee, it is possible to use advanced wireless technologies, including routing and security, which are not supported by KNX/RF but are here implemented by using ZigBee as a new data-link. KNX over ZigBee wireless nodes are also able to communicate with existing KNX devices. At the application level, a mixed wired and wireless network with conventional KNX and KNX over ZigBee devices is equivalent to a KNX-based network. A network diagram illustrating this is shown in Fig. 4. III. RESEARCH BACKGROUND The broad goal of our research is to develop a HA system and devices based on WSN (Wireless Sensor Network) technologies. We considered several wireless technologies as means to access an open medium. We adopted IEEE 802.15.4 as a lower layer protocol for our device. Because the function of IEEE 802.15.4 is limited to PHY and MAC, other upper layer Fig. 4. Network diagram with KNX and KNX over ZigBee devices 751

This approach, however, is limited in that KNX over ZigBee nodes cannot communicate with pure ZigBee nodes. Recently, the ZigBee standard organization has released a HA profile specification [6] that includes many new items that make ZigBee practical for HA applications. We therefore propose the KNX ZigBee gateway method to leverage the beneficial characteristics of both networks. In the next section, we will explain the KNX ZigBee gateway in detail. IV. KNX ZIGBEE GATEWAY This section considers the KNX ZigBee gateway as an interface between the two networks with which to translate entities from one network to the other. Although the KNX ZigBee gateway itself will require maintenance, by its adoption, both networks, KNX and ZigBee, can be maintained as is. The gateway will enable systems to leverage the benefits of each protocol and system. A network diagram illustrating the configuration of KNX, ZigBee, and the KNX ZigBee gateway is shown in Fig. 5. Because the KNX ZigBee gateway must handle entities such as the value of user data, application-level services, and the addresses of devices of both networks, three functions are supported: translation of attributes of user data, translation of application level services, and translation of addresses. switching, can be labeled as DPT_Switch (1.001) [10]. The HA profile defined by the ZigBee system comprises Device, Cluster, Command, Attribute, and Attribute data. A binary input ZigBee node that carries out the same function as the KNX node given above can be classified as an On/Off Switch. An On/Off Switch device has five categories of Clusters: On/Off, Scenes, Groups, Identify, and On/Off Switch Configuration, each with its own attributes. These configurations are shown in Fig. 6. Corresponding specific Commands and Command IDs for the On/Off Switch device (not depicted in Fig. 6) also exist, in addition to General Command s that act across the entire profile [7]. The logical access point for device communication is the endpoint in ZigBee and the communication object in KNX. An endpoint is mapped to a Device in a HA profile, and a communication object is mapped to a DPT. Hence, a Cluster in ZigBee, for example, can be mapped to a DPT in KNX. A comparison between DPTs and HA profiles is shown in Fig. 7. Fig. 5. Network diagram with KNX, ZigBee and the KNX ZigBee gateway Fig. 6. An example HA profile for an On/Off Switch device For illustration, we will use an example for translating a telegram of a KNX binary input device to a ZigBee frame which communicates in broadcast, group-messaging mode. A. Attribute translation Although KNX regulates DPTs while ZigBee regulates a HA profile, they share many elements. By matching DPTs with the HA profile, the data attributes of each network can be translated. The DPTs defined by the KNX system enable the user to encode the usage of the data efficiently. For example, one bit user data can be defined by the DPTs DPT_Switch (DPT 1.001), DPT_Bool (1.002), DPT_Enable (1.003), and so on. The data generated, for example, by a binary input device that gives an actuating command to an output device for On/Off Fig. 7. Comparison between DPTs of KNX and HA profiles of ZigBee 752

When a KNX telegram, for example, one that was generated by a binary input device, arrives at the KNX ZigBee gateway, the particular KNX substandard to use must be selected before the telegram is translated into a ZigBee frame. All of the KNX substandards employ the same application layer structure, but several substandards in the KNX system differ depending on which media they support. The telegram formats for different substandards can differ. Here, the most widely used KNX substandard, KNX/TP1, which uses twisted pair as its medium, is selected concretely to represent the translation procedure. The full telegram arriving at the KNX ZigBee gateway is shown in Fig. 8. Fig. 8. An example of a KNX/TP1 telegram generated by binary input device As shown in Fig. 8, the KNX/TP1 telegram does not provide a field for DPT information because the DPT information is managed by a commissioning tool called ETS. Given both the incoming telegram and the DPT information, the KNX ZigBee gateway can discern the intended use of the telegram. In the example, user data, marked with the red color in Fig. 8, is 000001 to indicate On and the assigned DPT for this user data is DPT_Switch(1.001) [10]. In the case of ZigBee, information related to Device, Cluster, Command, Attribute, and Attribute data is managed at the application layer and APS (Application Support) sub-layer. Hence, the information from the KNX network has to be translated appropriately to the ZigBee application layer and APS sub-layer data structures. The frame structure of ZigBee for each layer is given in Fig. 9 and the frame format (ZigBee 2007) for the APS sub-layer is shown in Fig. 10. Fig. 10. ZigBee APS frame format The Profile Identifier, Cluster Identifier, Attribute ID, Data Type, and Attribute data fields will be filled when we translate the example telegram from the KNX network. The result of attribute translation for this example is shown in Fig. 11. Fig. 11. Translating the KNX user data attributes to ZigBee Fig. 9. ZigBee frame structure The particular fields in the APS header and the APS payload (ASDU) are described in Fig. 10. All fields must be given to translate the KNX telegram to a ZigBee frame successfully. B. Application service translation In addition to translating attributes, the gateway must also translate application services such as user value writing and user value reading. The KNX system has three kinds of representative services that are provided during normal operations. These are A_GroupValue_Read, A_Group Value_Response, and A_GroupValue_Write [9]. The information regarding which service is being used is kept on the telegram as APCI (Application Protocol Control Information). In the example telegram, A_GroupValue_ Write is used. The A_GroupValue_Write service can be translated as shown in Fig. 12. 753

address with the KNX destination group address, address translation is accomplished automatically. The result of address translation for the example telegram is shown in Fig. 14. Fig. 12. Translating a KNX application level service to ZigBee In this study, we used the General Command for the ZigBee HA profile, instead of a Command that is defined only for a given Cluster because the General Command encompasses more common services such as Read_Attributes, Write_Attributes, and Report_Attributes. In addition, because (in our example) A_GroupValue_Write is a service for which the remote application process does not issue a confirmation, the ACK Request and Disable Default Response fields are set to No ACK Request and No Default Response. C. Address translation One of the most important tasks for the KNX ZigBee gateway is address translation. KNX uses 16-bit physical addresses and 16-bit group addresses. During normal operation, the source address of a telegram should be a physical address and the destination address should be a group address. ZigBee uses three kinds of addresses: 64-bit IEEE extended addresses, 16-bit network addresses, and 16-bit group addresses. The 64-bit IEEE extended address is a unique identifier, while the 16-bit network address can be assigned by a coordinator. A notable commonality between KNX and ZigBee is support of 16-bit group addresses; direct mapping from one to the other is possible. When translating the example telegram, the 16-bit group address is used directly as a destination address, and in this case, no destination endpoint is specified in the frame; destination endpoints are maintained separately in a group table associating groups with endpoints, so that group-addressed frames can be delivered selectively to those endpoints that are associated with a particular group [8]. The mapping of group addresses to endpoints is shown in Fig. 13. Fig. 14. Translating destination group address from KNX to ZigBee V. RESULT OF THE TRANSLATION PROCESS The ZigBee frame format for the APS sub-layer given in Fig. 10 is filled out to correspond with the example incoming KNX telegram. Some fields, such as Transaction Sequence Number, Source Endpoint, and APS Counter and Security depend on the specific application and context. The results of translation for our example are shown in Fig. 15. The APS header and ASDU can also be constructed using the proposed KNX ZigBee gateway method. Translation from a ZigBee frame to a KNX telegram can be performed by the reverse of the given procedure. 0~1 Bit 2 3 Type(Z) B 00' Manufacturer Disable Default Direction Specific Response B 0' B 0' B 1' 1 Octet 0/2 0/1 1 Control(Z) Control Manufacturer Code ZCL Header Transaction Seq. Number 2 1 Attribute ID X 0000' ZCL APS Header Addressing Fields Command ID B 02' Data Type X 10' 1 Octet 0/1 0/2 0/2 0/2 0/1 1 4 Octets Payload Reserved B 000' ZCL Payload 0/ 5~7 Octet Attribute Data X 01' APS Payload Payload Octets Control Dest. Endpoint Group Address X 3801' Cluster Identifier X 0006' Profile Identifier X 0104' Source Endpoint APS Counter Ext. Header Payload Delivery ACK ACK Extended Type Security Mode Format Request Header Present B 00' B 11' B 0' B 0' B 0' 0~1 Bit 2~3 4 5 6 7 Fig. 13. Association concept between groups and endpoints in a group table By using group addresses, one message can control several devices, just as in a KNX system. By assigning the same KNX and ZigBee group addresses to a ZigBee device in the initial stage and replacing a telegram's ZigBee destination Introductory remarks Field can vary depending on a case Field that is not exist in this case By attribute translating By address translating By application service translating Fig. 15. Translation results for the example KNX frame 754

VI. DISCUSSION While the KNX ZigBee gateway offers a practical solution to the problem of integrating wireless and wired HA systems, we foresee some possible problems. For example, some attributes and application-level services cannot be translated. Even though DPTs and HA profiles are defined for the same HA devices, the definitions may not be interchangeable between the systems. In this case, a custom profile can be defined in the ZigBee system or a user-defined DPT can be used. For group addressing in our example, the broadcast communications mode is used. The ZigBee standard, however, recommends that group messaging in broadcast only be used for group less than 5 [6]. This matter can be resolved by applying schemes, such as multicast communications, to achieve energy efficiency. The sophisticated structure of the KNX-ZigBee gateway makes it appear complex to implement. Some systematic ideas or schemes that make its structure as simple as possible need to be investigated. REFERENCES [1] Christian Reinisch, Wireless communication in home and building automation, Master s thesis, Vienna University of Technology, February 2007. [2] Christian Reinisch, Wolfgang Kastner, Georg Neugschwandtner, Wolfgang Granzer, Wireless technologies in home and building automation, INDIN 2007, Volume 1, PP. 93 98, 23 27 June 2007. [3] ZigBee Alliance home page, http://www.zigbee.org/en/about/ [4] KNX Specification, 03_07_02 Datapoint Types v1.4 AS v20071214a. doc v1.4, December 14, 2007. [5] Sinem Coleri Ergen, ZigBee/IEEE 802.15.4 summary, U.C. Berkeley, September 10, 2004. [6] ZigBee Specification, ZigBee home automation public application profile, v1.0 revision 25, ZigBee document 053520r25, ZigBee Standard Organization, October 25, 2007. [7] ZigBee Specification, ZigBee cluster library specification, ZigBee document 075123r01ZB, ZigBee Standard Organization, October 19, 2007. [8] ZigBee Specification, ZigBee specification, ZigBee document 053474r17, ZigBee Standard Organization, January 17, 2008. [9] KNX Specification, 03_03_07 layer application v1.0 AS, December 19, 2001. [10] KNX Specification, 07_20 (S12) lighting v1.7 AS, March 25, 2002. VII. CONCLUSION & FUTURE WORK In this paper, we proposed a KNX ZigBee gateway to interface between KNX and ZigBee systems and enable integration of wireless and wired home automation systems. As a next step, we plan to implement the KNX ZigBee gateway and use it to establish a home lighting control system. This experimental model will include direct lighting, indirect lighting, and artificial lighting devices, as well as ZigBee sensor and actuator nodes. Using these devices, we will test home lighting services, for example, scene control, scheduled control, and automatic light level adjustment. The planned experimental model is depicted in Fig. 16. With the help of this experimental home lighting control system, we will investigate the compatibility between the two protocols and also study the feasibility of a ZigBee-based HA system. Fig. 16. Expected experimental model for a home lighting control system 755