Implementation of a KNX-ZigBee Gateway for Home Automation

The 13th IEEE International Symposium on Consumer Electronics (ISCE2009) Implementation of a KNX-ZigBee Gateway for Home Automation Woo Suk Lee Seun...
Author: Kristin Goodwin
11 downloads 0 Views 1MB Size
The 13th IEEE International Symposium on Consumer Electronics (ISCE2009)

Implementation of a KNX-ZigBee Gateway for Home Automation Woo Suk Lee

Seung Ho Hong

Ubiquitous Sensor Network Research Center Hanyang University Ansan, Korea [email protected]

Dept. of Electronics, Electrical, Control & Instrument Engineering Hanyang University Ansan, Korea [email protected]

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 available, ZigBee is one of the most useful for home automation. A wireless home networking system can be configured using ZigBee alone. However, compatibility with conventional networking systems based on wired media is not supported. KNX is a mature protocol for wired media and is recognized as an international standard. In this paper, a KNX-ZigBee gateway is proposed for interfacing between KNX and ZigBee systems, thereby enabling the integration of wired and wireless home automation systems.


This section explains the KNX-ZigBee gateway’s translation strategy with which to translate entities from one network to the other. Although the KNX–ZigBee gateway will require its own separate maintenance, its adoption will permit both networks (KNX and ZigBee) to be kept as they are. The gateway will enable each system to leverage the benefits of the other system and protocol. A network diagram illustrating the configuration of KNX, ZigBee, and the KNX–ZigBee gateway is shown in Fig. 1. Because the KNX–ZigBee gateway must be equipped to handle user data, application-level services, and the device addresses in both networks, three functions are supported: translation of user data attributes, translation of application level services, and translation of addresses.

Keywords— KNX; ZigBee; Home Automation; Internetworking; Gateway



Wireless technologies are becoming increasingly common in the automation systems used in home and building. They are relatively inexpensive and easy to install, as well as to extend. Moreover, they offer aesthetic benefits and allow mobile device connectivity. Among many existing wireless protocols, ZigBee is particularly well suited to home automation (HA). ZigBee is designed to enable reliable, cost-effective, lowpower, wirelessly networked monitoring and control products based on an open standard. Wireless HA can be achieved using ZigBee alone. However, to facilitate the expansion of conventional wired control networks, it is necessary to maintain compatibility with current wired protocols, some of which offer advantages that might be leveraged by a wireless system. Accordingly, newly introduced technologies (such as communication protocols) should support compatibility with existing technologies. Even within the field of HA, many communication protocols and systems exist with which ZigBee must be compatible.

Figure 1. KNX-ZigBee network diagram

A. Attribute translation Although KNX regulates DPTs, which describe the usage of user data, while ZigBee regulates an HA profile. The two systems have many elements in common. By matching DPTs with the HA profile, the data attributes of the two networks can be translated from one to the other.

Among many types of existing home networking systems that use wired media, KNX (Konnex) is selected as a representative HA protocol in this paper. This is because it is a merger of other HA standards and is a relatively mature protocol that has been adopted as an international standard.

The DPTs defined by the KNX system enable the user to encode data usage efficiently. One bit user data can be defined as DPT_Switch (DPT 1.001), DPT_Bool (1.002), DPT_Enable (1.003), and so on. For example, the data generated by a binary input device that gives an actuating command to an output device for On/Off switching, can be labelled as DPT_Switch (1.001).

Within the previous study [1], a gateway concept which enables to interface between KNX and ZigBee system and protocol was proposed. And, as the further study, this paper shows how to implement a real gateway. 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.

978-1-4244-2976-9/09/$25.00 ©2009 IEEE



illustrated in Fig.4. However, KNX telegrams do not provide a field for DPT information for the efficient network resource management reason. Since, the DPT information is managed at the initial stage 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 data contained in telegram.

The HA profile defined by the ZigBee system comprises Device, Cluster, Command, Attribute, and Attribute data. A binary-input ZigBee node that performs the same function as the KNX node described in the previous paragraph 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 illustrated in Fig. 2. Corresponding specific Commands and Command IDs for the ‘On/Off Switch’ device (not shown in Fig. 2) also exist, in addition to General Command Frames that act across the entire profile.

Figure 4. Attribute translation between KNX and ZigBee


Application service translation In addition to attributes translation, the KNX-ZigBee gateway must also translate application services such as user value writing and user value reading. The fields pertaining to application service translation in KNX and ZigBee frames are shown in Fig. 5.

Figure 2. An example HA profile for an ZigBee ‘On/Off Switch’ device

The logical access points for device communication are the endpoint in ZigBee and the communication object in KNX. An endpoint is mapped to a Device in an HA profile, and a communication object is mapped to a DPT. Hence, a Cluster in ZigBee can be mapped to a DPT in KNX. A comparison of DPTs and HA profiles is presented in Fig. 3.

Figure 5. Application service translation between KNX and ZigBee


Address translation One of the most important tasks for the KNX–ZigBee gateway is address translation. A notable common feature of KNX and ZigBee is their support of 16-bit group addresses. Thus a direct mapping from one to the other is possible. The mapping of group addresses is shown in Fig. 6. By using group addresses, one message can control several devices in either of the two systems. By assigning the same KNX and ZigBee group addresses to each device in the initial stage, address translation can be accomplished automatically.

Figure 3. Comparision between KNX DPTs and ZigBee HA profiles

According to the strategy explained above, entities related to attribute translation can be translated (or mapped), as

Figure 6. Address translation between KNX and ZigBee




The KNX-ZigBee gateway hardware consists of two main components: the KNX module and the ZigBee module. Each module includes an appropriate communication stack. The photograph of the actual hardware is shown in Fig. 7. and the hardware structure is illustrated in Fig. 8. A. KNX module The KNX module contains a KNX communication stack to enable the transmission and reception of KNX telegram. Lower layer (up to DLL) functions are carried out by the TP-UARTIC line driver, while upper layer (above DLL) functions are processed in the AVR ATmega128 MCU. The essential part of the KNX stack is partially implemented for experimental purposes. When a KNX telegram is received, it is transformed by the TP-UART-IC into UART formatted data and then transferred to the MCU through UART0. After the KNX telegram is processed, it is shared with the ZigBee module through UART1. Transmission to a KNX communication line can be accomplished in the reverse order.

Figure 8. Hardware structure of the KNX-ZigBee gateway



Even though the core part of the KNX-ZigBee gateway is physically stored in the separate KNX and ZigBee modules, this translation routine operates independently of the stacks. The KNX-ZigBee translation routine is composed of three main parts: attribute translation, application service translation and address translation. In addition to these, the routine should manage the GA (Group Address) & DPT table, since a KNX frame does not carry DPT information in the frame. The translation processing sequence is illustrated in Fig. 9.

B. ZigBee module The ZigBee module contains a ZigBee full stack developed by RadioPulse®. This stack is contained in an MG2455 radio chip, the design of which is based on the one-chip concept. Hence, transceiving and processing are carried out in a single chip. The module is programmed to share translation data with the KNX module through UART0. Aside from this, UART1 can be used to debug and download a hex level program.

A. Translation sequence from KNX to ZigBee When a KNX telegram arrives at the KNX-ZigBee gateway, it is transferred to the KNX-ZigBee gateway translation routine. In the meantime, the GA & DPT table is accessed to find the proper DPT for the GA contained in the received frame. The DPT thus obtained is then employed for attribute translation. The other translations are archived by interpreting the KNX frame.

C. Peripheral components Translation sequences and results can be observed using the 128 x 64 graphic LCD. Data exchanged between the KNX and ZigBee modules also can be monitored via the debug port. Furthermore, the modules can be used as communication modules for KNX or ZigBee devices, if attached to appropriate base devices.

Following this, a separately arranged and constructed Simple Frame, defined for data exchange in the KNX-ZigBee gateway translation routine, is delivered to the ZigBee module. The ZigBee module assembles the information from the received Simple Frames it has received, and converts this information into a ZigBee frame. Finally, the ZigBee frame thus generated is transmitted by means of the APSDEDATA.req primitive of the ZigBee stack. B. Translation sequence from ZigBee to KNX When a ZigBee frame arrives at the ZigBee module of the KNX-ZigBee gateway, the ZigBee communication stack is notified of its arrival through the APSDE-DATA.ind primitive. The frame is then separately coded into three Simple Frames, and delivered to the KNX-ZigBee gateway translation routine. When a Simple Frame related to address translation arrives at the KNX module, it is used to find the proper DPT for the GA carried in the Simple Frame. After the KNX telegram has been constructed, it is transmitted by A_GroupValue primitives.

Figure 7. Photograph of the KNX-ZigBee gateway


Figure 9. A

The ZigBee stack was developed by RadioPulse®. Some function names have been modified to facilitate understanding

Figure 9. KNX and ZigBee communication stacks and the translation routine of the KNX-ZigBee gateway



An example is employed to illustrate the results of translating a telegram from a KNX/TP1 (KNX substandard, which is based on twisted pairs) binary input device to a ZigBee frame. The KNX telegram arriving at the KNX–ZigBee gateway is shown in Fig. 10. This telegram contains a destination GA of 0x3801 and an application service of A_GroupValue_Write. In addition to the information in the frame, the corresponding DPT, stored separately in the GA & DPT table, is DPT_Switch (1.001).

Figure 10. An example of a KNX/TP1 telegram

The ZigBee frame format for the APS sub-layer, shown in Fig. 11, is filled out to correspond with the incoming KNX telegram. Some fields, such as Transaction Sequence Number, Source Endpoint, APS Counter and Security, depend on the specific application and context. The APS header and ASDU can also be constructed using the KNX–ZigBee gateway. Translation of a ZigBee frame into a KNX telegram can be accomplished by reversing the given procedure.

Figure 11. Translation results for the example KNX frame




As an actual experiment to validate the performance of the KNX-ZigBee gateway, KNX-ZigBee unified wired-wireless home network demonstration system has been developed. In Fig. 12, the light bulbs marked with red circles belong, on the left side, to the KNX/TP1 wired network, and, on the right side, to the ZigBee wireless network. Each light bulb controller has the same GA (0x3801) used in the previous example. When a telegram is generated by a KNX binary input device of the same type used in the previous example, it illuminates the bulb connected to the KNX binary output device. When the same telegram is delivered to the KNXZigBee gateway, it is also activates the bulb connected to the ZigBee binary output device. The results of the experiment are illustrated in Fig 12.

As a next step, the KNX–ZigBee gateway will be used to implement an energy-efficient home lighting control system. The experimental model will include several types of lighting sources and controllers. Most of the lights will be controlled by a KNX device, while the power consumption of each light will be monitored by a ZigBee sensor node. The planned experimental model is depicted in Fig. 13. With the help of this experimental energy-efficient home lighting control system, the compatibility between the two protocols will be further investigated, and the energy-saving capabilities of a ZigBeebased HA system will also be studied.

Figure 13. Proposed home lighting control experimental model


[3] [4] [5] [6] Figure 12. Demonstration system of KNX, ZigBee unified network




In this paper, a KNX–ZigBee gateway is proposed and implemented as an interface between KNX and ZigBee systems, enabling the integration of wireless and wired home automation systems. While the KNX-ZigBee gateway offers a practical solution to the problem of integrating wired and wireless HA systems, some problems remain, including difficulties in attribute mapping created by attributes that are not readily mapped to between systems. In such cases, custom KNX DPT’s or ZigBee profiles can be adopted.


Woo Suk Lee, Seung Ho Hong, “KNX-ZigBee gateway for home automation”, IEEE-CASE 2008, PP. 750–755 , 23–26 August 2008. 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. KNX Specification, “03_07_02 Datapoint Types v1.4 AS v20071214a. doc v1.4,” December 14, 2007. KNX Specification, “03_03_07 layer application v1.0 AS,” December 19, 2001. KNX Specification, “07_20 (S12) lighting v1.7 AS,” March 25, 2002. ZigBee Specification, “ZigBee home automation public application profile,” v1.0 revision 25, ZigBee document 053520r25, ZigBee Standard Organization, October 25, 2007. ZigBee Specification, “ZigBee cluster library specification,” ZigBee document 075123r01ZB, ZigBee Standard Organization, October 19, 2007. ZigBee Specification, “ZigBee specification,” ZigBee document 053474r17, ZigBee Standard Organization, January 17, 2008.

Suggest Documents