MASTER's THESIS Radio Technologies for Smart Homes: Zigbee Or Enocean

MASTER’S THESIS

Thesis submitted in partial fulfilment of the requirements for the degree of Master of Science in Engineering at the University of Applied Sciences Technikum Wien Telecommunication and Internet technologies

Radio technologies for Smart Homes: ZigBee or EnOcean by Felix Richter, BSc 1200, Vienna, Höchstädtplatz 5

Supervisor 1: Mag. DI, Friedrich Praus Supervisor 2: FH-Prof. Dipl.-Ing. Dr.techn., Thomas Sommer Vienna, 27.02.2012

Declaration

„I confirm that this thesis is entirely my own work. All sources and quotations have been fully acknowledged in the appropriate places with adequate footnotes and citations. Quotations have been properly acknowledged and marked with appropriate punctuation. The works consulted are listed in the bibliography. This paper has not been submitted to another examination panel in the same or a similar form, and has not been published. “

Place, Date Signature

Kurzfassung

Diese Masterarbeit befasst sich mit zwei möglichen Funktechnologien, die in einem „Smart Home“ (übersetzt „Intelligentes Heim“) eingesetzt werden können. Sowohl der offene ZigBee Standard als auch der proprietäre EnOcean Standard spezifizieren ein drahtloses Sensornetzwerk (WSN) und werden in den ersten Kapiteln ausführlich beschrieben. Es folgt der Vergleich beider Technologien. Dabei stellt sich heraus, dass das Hauptargument für ZigBee seine Sicherheitsfunktionen sind. Als größter Vorteil von EnOcean kann das Energy Harvesting gesehen werden. Dabei erfolgt die Energieversorgung durch das Generieren von Energie aus der Umgebung, z.B. durch Druck, Temperaturdifferenz, Sonnenenergie, etc. Der praktische Teil der Arbeit umfasst den Aufbau eines drahtlosen Sensornetzwerkes mit EnOcean-Technologie, als Teil eines Smart Home Projektes. Die Arbeit beinhaltet die Beschreibungen des Hardwareaufbaus, der Hardware selbst, und der Software- konfigurationen.

Schlagwörter: ZigBee, EnOcean, drahtloses Sensornetzwerk, WSN, Energy Harvesting

Abstract

This master’s thesis deals with two possible wireless technologies which may be used in a Smart Home. Both the open ZigBee standard and the proprietary EnOcean standard are specifying a wireless sensor network (WSN) and both are described in detail in the first chapters. It follows the comparison of both technologies, where it comes out that ZigBee's advantages are its security functions while EnOcean's big advantage is its Energy Harvesting technology. With this technology energy is supplied by generating it from the environment, e.g. by pressure, temperature difference, solar energy, etc. The practical part of the thesis comprises the construction of a wireless sensor network with EnOcean technology, as part of a smart home project. The thesis includes descriptions of the hardware configuration, of the hardware itself, and of the software configurations.

Keywords: ZigBee, EnOcean, wireless sensor network, WSN, Energy Harvesting

Acknowledgements

I want to thank my supervisor Mag. DI Friedrich Praus for his readiness to help others. I also want to thank FH-Prof. Dipl.-Ing. Dr.techn. Thomas Sommer who helped me finding an interesting topic, helped me improving my thesis and supported the project financially.

Table of Contents

1 Introduction ...... 6 1.1 Motivation ...... 6 1.2 Scope of work...... 8

2 Own contributions ...... 8

3 State of the art ...... 9 3.1 ZigBee ...... 9 3.1.1 IEEE 802.15.4 ...... 9 3.1.2 ZigBee Details ...... 22 3.2 EnOcean ...... 32 3.2.1 Technical description ...... 36 3.2.2 EnOcean Dolfin System Architecture for developers ...... 41 3.2.3 Fields of Application ...... 42 3.3 Comparison of ZigBee and EnOcean ...... 44 3.3.1 ZigBee and energy harvesting ...... 44 3.3.2 Technical comparison ...... 45 3.3.3 Economic comparison ...... 48

4 Project SMART HOME ...... 50 4.1 Concept ...... 50 4.1.1 What is the Beckhoff System? ...... 51 4.1.2 EnOcean integration into the Beckhoff system ...... 51 4.1.3 What is KNX? ...... 52 4.2 Hardware Design ...... 53 4.2.1 Hardware components ...... 53 4.2.2 Hardware installation and configuration (EnOcean) ...... 54 4.3 Software Design ...... 64 4.3.1 TwinCat ...... 64 4.3.2 SmartHome Software - Source Code (PLC) ...... 65 4.3.3 SmartHome Software – Configuration ...... 83 4.3.4 SmartHome Software - Running System ...... 89 4.3.5 SRC-ADO-V3 configuration software ...... 92 4.4 Project evaluation ...... 97

5 Summary & Outlook ...... 98

Bibliography ...... 99

List of Figures ...... 102

List of Tables ...... 106

List of abbreviations ...... 107

A: Table of Hardware ...... 109

B: Description of hardware components relevant for EnOcean integration ...... 110 1) Beckhoff BK9050 - Bus Coupler ...... 110 2) Beckhoff KL6581 - EnOcean-Masterterminal ...... 112 3) Beckhoff KL6583 - EnOcean-Receiver and Transmitter ...... 113 4) EasySense PG1 (switch) ...... 114 5) EasySense SRG01 (switch) ...... 115 6) EasySense SRW01 – Window Contact (sensor) ...... 117 7) EasySense SR65 – Outdoor Temperature Sensor (sensor) ...... 118 8) EasySense SR04PST - Indoor temperature sensor (sensor) ...... 119 9) EasySense SRC-ADO 4AA/4DA Typ1 (actuator) ...... 122

C: Background technologies ...... 123

1 Introduction 1.1 Motivation This chapter deals with how I came to this topic, namely by my interest in environmental, research, and future technologies.

The problem! – The people's energy consumption gets higher and higher and finite resources, such as oil, are getting rare with time. Ultimately renewable energy systems (solar, hydro, wind, geothermal ...) will be used for energy production. These have to be mainly due to its dependence on weather conditions, co-ordinated to meet the energy consumption optimally. This task is performed by the smart grid (intelligent power grid).

Smart Grids: They are used to calculate and predict the energy consumption in future as accurately as possible. This is done by the use of data of past energy consumption of individual households, by the use of weather forecasts, and many other forecasts. With the help of energy consumption forecasts conventional power plants, renewable power plants, and also solar panels on the roofs of the consumers could be coordinated through the Smart Grid.

Figure 1 – a simplified Smart Grid (engi.elect.equi.org)

Smart Meter: The data of the current and past energy consumption of the consumers and the data of the current generation of the consumers own solar system is collected by Smart Meters and then forwarded to the coordination centre. A Smart Meter is usually integrated in a Smart Home, an intelligent house network, where it works as an interface between home and the outside world. Each smart home includes a room controller that acts as a coordinator between the various devices. Smart Meters are used either as a component of a room controller or even serve as one.

Figure 2 – function of a Smart Meter (jacksonemc.com)

Smart Home: A smart home is not only used to transmit the data of energy consumption, but also to reduce the energy consumption itself. It is used to intelligently control home appliances so that they are used only if they are actually needed or if energy is cheap at this time. But these are just the energy saving relevant functions of a smart home. Other advantages are more comfort and safety, time savings, etc.

Since a global implementation of the tasks, mentioned in the previous paragraphs, sounds like a mission statement for a quarter century I have decided to start at the base, namely the development and configuration of a Smart Home. Home automation is not a new invention, but there are new technologies and concepts. One of these new technologies is called "wireless data transmission", which has slowly gained acceptance in this area in the last 10 years. Two of these wireless technologies are described in detail in this Master's Thesis.

Figure 3 – a simplified Smart Home (joybien.com)

1.2 Scope of work When I started the Master course at the University of Applied Sciences there was already a running Smart Home project which was named "Smart Code". That project shall use ZigBee technology for wireless transmission. My study course then became the mission to search for alternatives to the ZigBee technology where we found a radio technology called EnOcean. My task then was to describe the two technologies ZigBee and EnOcean in detail and then to summarise their advantages and disadvantages and the differences of their properties. With this information we, the project team, shall start our own smart home project for testing purposes where the wireless technology that would be best suited for our needs should be used. The project requirements where:

 Low installation costs  Low maintenance costs  Simple configuration  Easy expandability  Up to 1000 sensors  optional: Security functions

2 Own contributions In the theoretical the two technologies ZigBee and EnOcean are described in detail. My contributions in these chapters will be the search for information and a summarised technical preparation of these. Afterwards the two technologies shall be compared technically as well as economically so that one of the two technologies that match the requirements best will be chosen. The chosen one then shall be integrated into a test Smart Home project. My contribution to this project will be the building up of the hardware, a part of the programming of the Smart Home source code in order to allow the integration of the chosen technology and of course the programming of the integration of the chosen technology itself. Another mission will be the learning of one or more programming languages provided by the IEC 61131-3 standard which are used to program the PLC from Beckhoff where the chosen technology will be integrated into. Last but not least the findings from developing a smart home with the selected technology shall be published.

3 State of the art For reasons of completeness the ZigBee chapter was adopted from my bachelor thesis with some small changes.

3.1 ZigBee The ZigBee standard is a product of the ZigBee Alliance which was founded in late 2002. It is a union of currently more than 230 companies. ZigBee’s main specifications are the simple implementation, the small sized stack, the low data transfer rate, the low power consumption and the cheap hardware. ZigBee is an open wireless network standard which defines a protocol stack which is based on the IEEE 802.15.4 standard. The IEEE standard is also specified in this document because the knowledge of this standard is essential to understand ZigBee. (wiki- ZigBee, 2010)

3.1.1 IEEE 802.15.4 The IEEE Standard 802.15.4 defines a low-rate Wireless Personal Area Network (LR- WPAN) which transfers information over short distances, usually in the personal operating space (POS) of 10 m. The main objectives of an LR-WPAN are ease of installation, reliable data transfer, short-range operation, extremely low cost, and a reasonable battery life, while maintaining a simple and flexible protocol. The standard specifies the physical layer, called “PHY”, and the medium access control sublayer, called “MAC”. It supports fixed, portable, and moving devices with no battery or very limited battery consumption and provides a longer range at a lower data rate. The edition of 2006 is backward compatible to the 2003 edition. (IEEE-Std-802.15.4, 2006) This document refers to the 2006 edition.

3.1.1.1 Types of devices The IEEE 802.15.4 standard defines two different types of devices, a full-function device (FFD) and a reduced-function device (RFD): (IEEE-Std-802.15.4, 2006)

 A FFD supports three modes. It works either as a personal area network (PAN) coordinator, a coordinator, or a device. It is able to communicate with RFDs or other FFDs.

 A RFD is used at extremely simple applications which do not send large amounts of data. A RFD can communicate only to an FFD and may only associate with a single FFD at a time. Typically the RFDs consume minimal resources and memory capacity.

A device which uses the IEEE 802.15.4 standard is either a RFD or a FFD. A WPAN consists of two or more devices which communicate on the same physical channel. At least one device must be a FFD which operates as the PAN coordinator. The PAN coordinator may connect the WPAN with other networks. (IEEE-Std-802.15.4, 2006)

3.1.1.2 Topologies An IEEE 802.15.4 WPAN supports two topologies: the star topology and the peer-to-peer topology. The PAN identifier is a unique identifier which is chosen by each independent PAN. It allows communication between devices inside a network using short addresses. The PAN identifier also enables communication between devices across independent networks. (IEEE-Std-802.15.4, 2006)

3.1.1.2.1 Star network formation A network which is configured in star formation consists of a single central controller, the so called PAN coordinator. Every communication goes over it and it is the only communication partner for every other device in the network. The PAN coordinator controls the communication of the PAN. Each device is identified by a unique 64 bit or a short 16 bit address. Each network is identified by a PAN identifier which is not currently used by another network within the radio sphere of influence. After the PAN identifier is chosen, the PAN coordinator allows other devices, FFDs and RFDs, to join its network. A device either initiates or terminates a communication while a PAN coordinator may also route communication around the network. In this network formation only the PAN coordinator might be main-powered while the other devices will mostly be battery powered. (IEEE-Std-802.15.4, 2006)

3.1.1.2.2 Peer-to-peer network formation As well as the star network the peer-to-peer (P2P) network also consists of a PAN coordinator which is the first device that communicates on the network. In difference to the star network in the P2P network any device is able to communicate with any other device within its radio sphere of influence. This fact enables the implementation of more complex network formations, like mesh networking topology. Also the routing of messages from any device to any other device on the network would be possible but route functions are defined by higher layers and are not part of this standard. Further network structures are constructed out of the peer-to-peer topology, for example the cluster tree formation. (IEEE- Std-802.15.4, 2006)

Figure 4 - Star and Peer-to-Peer topology (IEEE-Std-802.15.4, 2006)

3.1.1.2.3 Cluster tree network formation The cluster tree network is an advanced peer-to-peer network. Most devices are FFDs because they allow forwarding data packages. RFDs connect as a leaf device at the end of a branch because they have no route function. Exactly one FFD of each cluster may act as coordinator and provide synchronization services and other services to other devices. Only one coordinator can be the overall PAN coordinator, which may have greater computational resources than the other devices in the network. The first cluster is formed by the PAN coordinator which chooses an unused PAN identifier (PAN ID) and broadcasts beacon frames to its neighbor devices. Candidate devices request to join the network by answering the beacon frame. If the PAN coordinator authorizes a device to join its network, it adds the new device as a child device in its neighbor list. The newly joined device also adds the PAN coordinator in its neighbor list but as parent device. If the newly joined device is a FFD it then also begins transmitting periodic beacon frames in order that other devices may join the network at that device. Once, network requirements or specified limits are reached the first PAN coordinator orders a FFD to become the PAN coordinator of a new cluster close-by the first one. The lines in Figure 5 do not represent the communication flow, but they show the parent-child relationship between the devices. The multicluster structure provides an increasing area of coverage, while on the other side also the message traffic and the time of waiting is increased. (IEEE-Std-802.15.4, 2006)

Figure 5 - cluster tree network (IEEE-Std-802.15.4, 2006)

3.1.1.3 Architecture The IEEE 802.15.4 architecture is built-up by two layers where each layer provides its own functions and offers its services to the higher layers. The two layers are based upon the first two layers of the OSI seven-layer model. An LR-WPAN device includes a PHY, which contains the radio frequency (RF) transceiver along with its low-level control mechanism, and a MAC sublayer that provides access to the physical channel for all types of transfer, see Figure 6. The upper layers consist of a network layer which may provide routing functions, and an application layer which defines the functions of the device. ZigBee for example defines the upper layers while it is based on the two layers defined by the IEEE standard. The upper layer may access the MAC sublayer through an IEEE 802.2 Type 1 logical link control (LLC) and through the service- specific convergence sublayer (SSCS). (IEEE-Std-802.15.4, 2006)

Figure 6 - LR-WPAN device architecture (IEEE-Std-802.15.4, 2006)

3.1.1.4 PHY-Layer The PHY layer offers two services to the MAC layer: 1) The PHY data service which is accessed through the PHY data service access point (PD-SAP) and 2) the PHY management service which is accessed through the physical layer management entity SAP (PLME-SAP). The PHY data service enables the transmission and reception of PHY protocol data units (PPDUs) across the physical radio channel. (IEEE-Std-802.15.4, 2006)

Figure 7 - The PHY reference model (IEEE-Std-802.15.4, 2006)

The PHY defines the following tasks: (IEEE-Std-802.15.4, 2006)  Activation and deactivation of the radio transceiver  Energy detection (ED) within the current channel  Link quality indicator (LQI) for received packets  Clear channel assessment (CCA) for carrier sense multiple access with collision avoidance (CSMA-CA)  Channel frequency selection  Data transmission and reception (PHY protocol data units (PPDUs)) across the physical radio channel

Table 1 shows the frequency bands and the data rates which are defined by this standard.

Table 1 - Frequency bands and data rates (IEEE Std. 802.15.4, 2006)

3.1.1.5 MAC-Layer The MAC sublayer offers two services to the upper layers: 1) the MAC data service which is accessed through the MAC common part sublayer service access point (MCPS-SAP) and 2) the MAC management service which is accessed through the MAC sublayer management entity SAP (MLME-SAP). (IEEE-Std-802.15.4, 2006)

Figure 8 - The MAC sublayer reference model (IEEE-Std-802.15.4, 2006)

The MAC sublayer handles the access to the physical radio channel and offers the following tasks: (IEEE-Std-802.15.4, 2006)  Generating network beacons if the device is a coordinator  Synchronizing to network beacons  Supporting PAN association and disassociation  Supporting device security  Employing the CSMA-CA mechanism for channel access  Handling and maintaining the GTS mechanism (see chapter 3.1.1.6.1 Superframe structure)  Providing a reliable link between two peer MAC entities  Data transmission and reception (MAC protocol data units (MPDUs)) across the PHY data service

3.1.1.6 Functional overview This chapter provides an overview of the functions of a 802.15.4 LR-WPAN. It includes information on the data transfer models, the frame structures, improving probability of successful delivery, power consumption considerations and security.

3.1.1.6.1 Superframe structure The superframe structure is an optional model which defines the data flow. The format is defined by the coordinator. The data flow begins and ends with beacon frames which are sent by the coordinator. The superframe is divided into 16 equally sized slots while the first slot is reserved for the beacon frame. Beacon frames are used for synchronization of the attached devices, identification of the PAN and description of the superframe structure. (IEEE-Std-802.15.4, 2006)

There are two main types of superframes (IEEE-Std-802.15.4, 2006):  The first type consists only of the contention access period (CAP) between the two beacons. During this time any device is able to communicate. In order to avoid packet collisions each device uses a slotted CSMA-CA mechanism. With the 16th slot all transactions have to be completed.  The second type adds the contention free period (CFP) to the CAP, out of the CAP. For example when an application requires specific data bandwidth the PAN coordinator dedicates portions to that application. These portions are called guaranteed time slots (GTSs) which form together the CFP. The CFP includes up to seven GTSs which always appear at the end of the CAP. A GTS may allocate more than one slot period. Before the CFP starts all transactions in the CAP have to be completed and all transaction in the CFP have to be completed before the CFP ends.

Both superframe types have at least an active period and may include an optionally inactive period in which the devices may enter a power-safe mode. A coordinator stops transmitting beacons if it does not wish to use a superframe structure. (IEEE-Std-802.15.4, 2006)

Figure 9 - Superframe structure without GTS Figure 10 - Superframe structure with GTS (Typ1) (IEEE-Std-802.15.4, 2006) (Typ2) (IEEE-Std-802.15.4, 2006)

Figure 11 - Superframe structure with GTS and inactive period (IEEE-Std-802.15.4, 2006)

3.1.1.6.2 Data transfer model The IEEE 802.15.4 standard specifies three types of data transaction. The first transaction is the data transfer from a device to a coordinator, the second one is the data transfer from a coordinator to a device and the third one is the data transfer between two peer devices. In star topology the transaction between two peer devices is not valid because data may be exchanged only between the coordinator and a device. In peer-to-peer networks all three transactions may be used because it allows data exchange between any two devices in the network. The data transfer is either “beacon-enabled” or “nonbeacon-enabled”. A beacon-enabled PAN provides synchronization functions and a support for low-latency devices, while a nonbeacon-enabled PAN is used when these functions are not necessary. However, in order to discover the network the beacon is still required. (IEEE-Std-802.15.4, 2006)

 Data transfer to a coordinator beacon-enabled: The device first listens for the network beacon. When the beacon is received, the device synchronizes to the superframe structure. The device then may transmit its data frame to the coordinator using slotted CSMA-CA. The coordinator may complete the transaction by sending back an optional acknowledgment frame. When an acknowledgment is not required, the acknowledgement frame is not sent and the originator assumes that the transmission was successful. (IEEE-Std-802.15.4, 2006) nonbeacon-enabled: A device simply transmits its data frame to the coordinator, using unslotted CSMA-CA. Like in beacon-enabled mode, the coordinator may complete the transaction by sending back an optional acknowledgment frame. (IEEE-Std-802.15.4, 2006)

Figure 12 - Communication to a coordinator, Figure 13 - Communication to a coordinator, beacon-enabled (IEEE-Std-802.15.4, 2006) nonbeacon-enabled (IEEE-Std-802.15.4, 2006)

 Data transfer from a coordinator beacon-enabled: When the coordinator wishes to transfer data to devices, it adds a list of pending messages in the network beacon. A device periodically receives network beacons. If a message is pending that is relevant for this device it transmits a MAC command that requests the data, using slotted CSMA-CA. The data request is then acknowledged by the coordinator by transmitting an acknowledgement frame. Then the coordinator sends the pending data frame using slotted CSMA-CA or immediately after the acknowledgment frame. The device completes the transaction by sending back an optional acknowledgment frame. After successful data transmission the message will be removed from the list of pending messages in the beacon. (IEEE-Std-802.15.4, 2006) nonbeacon-enabled: A coordinator stores the data which is destined for a particular device. A device periodically (rate is application-defined) contacts its coordinator in order to check if data is actually stored on it. Therefore it transmits a MAC command that requests the data, using unslotted CSMA-CA. After the coordinator acknowledges the successful reception of the data request, it transmits the data frame to the device, using unslotted CSMA-CA. If there is no pending data frame, the coordinator points out this fact either in the acknowledgment frame following the data request or in the data frame with a zero- length payload. The device completes the transaction by sending an acknowledgment frame, if requested. (IEEE-Std-802.15.4, 2006)

Figure 14 - Communication from a coordinator, Figure 15 - Communication from a coordinator, beacon-enabled (IEEE-Std-802.15.4, 2006) nonbeacon-enabled (IEEE-Std-802.15.4, 2006)

 Peer-to-peer data transfers

A peer-to-peer network allows every device to communicate with any other device in its radio sphere of influence. In order to do this effectively, the devices wishing to communicate will need to receive constantly while the devices transmit its data using unslotted CSMA-CA. Another way of peer-to-peer transmission uses synchronization functions but which are not part of this standard. (IEEE-Std-802.15.4, 2006)

3.1.1.6.3 Frame structure The frame structure defines the packages a frame consists of. Each protocol layer adds layer specific headers and footers to its payload.

General description of the MAC-frame The MAC frame starts with the MAC header (MHR), followed by the MAC payload and ends with the MAC footer (MFR). Data units of above layers may be passed to the MAC layer as payload which is referred to as the MAC service data unit (MSDU). The MFR always contains a 16-bit frame check sequence (FCS). Together the MHR, MAC payload and MFR form the MAC protocol data unit (MPDU). (IEEE-Std-802.15.4, 2006)

The IEEE 802.15.4 standard defines four frame structures, which vary generally at the MAC level. The structures of the different PHY frames vary only in their length. The following list enumerates the individual fields of the four different frame structures: (IEEE- Std-802.15.4, 2006)

 Beacon Frame: used by coordinators o MHR: Frame Control, Sequence Number, Addressing Fields, Auxiliary Security Header o MAC payload: Superframe Specification, GTS Fields, Pending Address Fields, Beacon Payload o MFR: Frame Check Sequence

 Data Frame: used for data transfer o MHR: Frame Control, Sequence Number, Addressing Fields, Auxiliary Security Header o MAC payload: Data Payload o MFR: Frame Check Sequence

 Acknowledgment Frame: used for confirming successful reception o MHR: Frame Control, Sequence Number o MAC payload: no MAC payload included o MFR: Frame Check Sequence

 MAC Command Frame: o MHR: Frame Control, Sequence Number, Addressing Fields, Auxiliary Security Header o MAC payload: Command Type, Command Payload o MFR: Frame Check Sequence

General description of the PHY-frame The MPDU is then passed to the PHY as the PHY payload and is then called PHY service data unit (PSDU). The PHY starts with the synchronization header (SHR), containing the Preamble Sequence and Start-of-Frame Delimiter fields, followed by the PHY header (PHR) containing the length of the PHY payload and ends with the PHY payload. Together the SHR, PHR and PHY payload form the PHY protocol data unit (PPDU). (IEEE-Std- 802.15.4, 2006)

Figure 16 - Schematic view of the MAC- and the Figure 17 - Schematic view of the MAC- and PHY-packet of a Beaco-frame (IEEE-Std- the PHY-packet of a Data-frame (IEEE-Std- 802.15.4, 2006) 802.15.4, 2006)

Figure 18 - Schematic view of the MAC- and the PHY-packet of an Figure 19 - Schematic view of the MAC- and Acknowledgment-frame (IEEE-Std- the PHY-packet of a MAC-Command-frame 802.15.4, 2006) (IEEE-Std-802.15.4, 2006)

3.1.1.6.4 Improving possibility of successful delivery The IEEE 802.15.4 standard provides the following mechanisms in order to improve the possibility of a successful data transmission:

 CSMA-CA mechanism The carrier sense multiple access with collision avoidance (CSMA-CA) is a mechanism for collision avoidance, in case of multiple access of many devices on the same transmission channel. Depending on the network configuration, an IEEE 802.15.4 WPAN may use two types of channel access mechanisms: o unslotted CSMA-CA mechanism used by nonbeacon-enabled PANs o slotted CSMA-CA mechanism used by beacon-enabled PANs

Acknowledgment and beacon frames do not use any CSMA-CA mechanism. (IEEE-Std- 802.15.4, 2006) More detailed description of the functionality of the CSMA-CA mechanism can be found in the IEEE 802.15.4 standard.

 Frame acknowledgment A successful reception of a data or MAC command frame may be confirmed with an optional acknowledgment frame. The initiator assumes that the transmission was unsuccessful if it does not receive an acknowledgment after some time. Then it retries the transmission several times. The initiator assumes that the transmission was successful if the acknowledgment is not required. (IEEE-Std-802.15.4, 2006)

 Data verification A FCS mechanism applies a 16-bit cyclic redundancy check (CRC) in order to detect bit errors in every frame. (IEEE-Std-802.15.4, 2006)

3.1.1.6.5 Power consumption considerations The protocol has been developed for mainly battery-powered devices. In order to reduce power consumption the devices use duty-cycling, where they will spend most of their time in a sleep state. While main-powered devices may listen to the RF channel continuously, battery-powered devices listen to the RF channel periodically in order to determine whether a message is pending or not. (IEEE-Std-802.15.4, 2006)

3.1.1.6.6 Security The cryptographic mechanism in this standard uses symmetric-key cryptography while higher layers provide the required keys. Keys that are shared between two peer devices are called “link keys”, while a keys that are shared between a group of devices are called “group keys”. The cryptographic mechanism provides combinations of the security services: data confidentiality, data authenticity and replay protection. (IEEE-Std-802.15.4, 2006)

3.1.2 ZigBee Details The ZigBee standard, developed by the ZigBee Alliance, specifies a low-cost two-way and wireless communication standard which has very low-power consumption. The ZigBee standard may be implemented in consumer electronics, home and building automation, industrial controls, PC peripherals, medical sensor applications and some more. The ZigBee standard specifies the application support sub-layer (APS), the ZigBee device objects (ZDO), ZigBee device profile (ZDP), the application framework, the network layer (NWK), and ZigBee security services. (ZigBee-Specification, 2007)

ZigBee Protocol Versions There are 2004, 2006 and 2007 versions of the ZigBee standard. This document refers to the 2007 version with version number “r17”. Backwards compatibility of the 2007 version with the 2006 version is required while backwards compatibility with the 2004 version is not required. The abbreviation of the protocol version of the 2004-version is “0x01” while the abbreviation of the 2006 and 2007 versions are “0x02”. The protocol version can be found in the Network (NWK) header. (ZigBee-Specification, 2007)

3.1.2.1 Network Topologies and devices The NWK layer, defined by ZigBee, supports star, peer-to-peer (mesh), and tree topologies. The ZigBee standard specifies three types of devices: (ZigBee-Specification, 2007)

 ZigBee end device: an IEEE 802.15.4-2003 RFD or FFD participating in a ZigBee network, which is neither the ZigBee coordinator nor a ZigBee router.

 ZigBee router: an IEEE 802.15.4-2003 FFD participating in a ZigBee network, which is not the ZigBee coordinator but may act as an IEEE 802.15.4-2003 coordinator within its personal operating space, that is capable of routing messages between devices and supporting associations.

 ZigBee coordinator: an IEEE 802.15.4-2003 PAN coordinator; establishes a new network

All types of ZigBee devices provide the functionalities join, leave, and rejoin a network. Additionally, ZigBee coordinators and routers provide the following functionalities: (ZigBee- Specification, 2007)

 Permit devices to join the network using the following: o Association indications from the MAC o Explicit join requests from the application o Rejoin requests  Permit devices to leave the network using the following: o Network leave command frames o Explicit leave requests from the application  Participate in assignment of logical network addresses  Maintain a list of neighboring devices

3.1.2.2 Architecture The ZigBee stack contains a set of layers where each layer provides a set of services to the next higher layer. Communication between two layers is done through service access points (SAPs) where each SAP supports a number of service primitives. Data entities provide a data transmission service while management entities provide all other services.

The IEEE 802.15.4 standard specifies the first two layers: the physical layer (PHY) and the medium access control sub-layer (MAC). The ZigBee standard builds on the two IEEE 802.15.4 layers and specifies the network (NWK) layer and the application layer (APL) framework. The application layer framework contains the application support sub-layer (APS), the ZigBee device objects (ZDO) and the application framework. The application framework contains the application objects which are manufacturer-defined. They share APS services and security services with the ZDO. (ZigBee-Specification, 2007)

Figure 20 - ZigBee stack architecture (ZigBee-Specification, 2007)

3.1.2.2.1 Network Layer Specification The network layer provides a service interface between the IEEE 802.15.4 MAC layer and ZigBee’s application layer framework. The network layer includes two service entities in order to interface with the application layer: (ZigBee-Specification, 2007)

 The NWK layer data entity (NLDE) provides data transmission via the NLDE service access point (NLDE-SAP).  The NWK layer management entity (NLME) provides the management service via the NLME service access point (NLME -SAP). The NLME also runs a database of managed objects, known as the network information base (NIB).

Figure 21 - NWK layer reference model (ZigBee-Specification, 2007)

Network Layer Data Entity (NLDE) The NLDE provides a data service which allows an application to transport application protocol data units (APDU) between two or more devices within a network. The NLDE provides the services (ZigBee-Specification, 2007):

 Generation of the Network level protocol data unit (NPDU): NKW header + NWK payload (APDU = application support sub-layer PDU)  Topology-specific routing  Security: to ensure the authenticity and confidentiality of a transmission.

Network Layer Management Entity (NLME) The NLME provides a management service which allows an application to interact with the stack. Therefore it provides the services (ZigBee-Specification, 2007):

 Configuring a new device  Starting a network  Joining, rejoining and leaving a network  Addressing  Neighbor discovery  Route discovery  Reception control  Routing

General NPDU Frame Format The NWK layer protocol data unit (NPDU) frame format contains two units: a NWK header and a NWK payload. The NWK header is composed of several fields which appear in a fixed order. (ZigBee-Specification, 2007)

Figure 22 - General NWK frame format (ZigBee-Specification, 2007)

Frame Control Field The frame control field has a length of 2 byte or 16 bits. It contains several sub-fields which include information defining the frame type, addressing and sequencing fields and other control flags. (ZigBee-Specification, 2007)

Figure 23 - Frame control field of an NPDU (ZigBee-Specification, 2007)

3.1.2.2.2 Application Layer Specification ZigBee Application Support (APS) Sub-Layer The application support sub-layer (APS) offers an interface between the network layer (NWK) and the application layer (APL) framework. It provides services which are used by the ZDO and the application objects. The APS layer offer its services through two entities: (ZigBee-Specification, 2007)

 The APS data entity (APSDE) offers the data transmission service through the APSDE service access point (APSDE-SAP).  The APS management entity (APSME) offers a variety of services, including security services and binding of devices, through the APSME service access point (APSME-SAP). It also runs a database of managed objects which is called APS information base (AIB).

Figure 24 - APS Sub-Layer reference model (ZigBee-Specification, 2007)

Application Support Sub-Layer Data Entity (APSDE) The APSDE provides a data service which allows the transport of application PDUs between two or more devices within a network. The APSDE provides the services: (ZigBee-Specification, 2007)  Generation of the application level PDU (APDU): APS PDU = application PDU + the appropriate protocol overhead.  Binding of devices  Group address filtering  Reliable transport  Duplicate rejection  Fragmentation: this enables segmentation of messages

Application Support Sub-Layer Management Entity (APSME) The APSME provides a management service which allows an application to interact with the stack. Therefore it provides the services: (ZigBee-Specification, 2007)  Binding management  AIB management

 Security  Group management

General APDU Frame Format The Application support sub-layer protocol data unit (APDU) frame format contains two units: an APS header and an APS payload. (ZigBee-Specification, 2007)

Figure 25 - General APDU frame format (ZigBee-Specification, 2007)

Frame Control Field The frame control field has a length of 1 byte or 8 bits. It contains several sub-fields which include information defining the frame type, addressing fields, and other control. (ZigBee- Specification, 2007)

Figure 26 - Format of the frame control field of an APDU (ZigBee-Specification, 2007)

Application Framework

The application framework in ZigBee is responsible for hosting the application objects on ZigBee devices.

Application objects There is space for up to 240 individual application objects which are identified by an endpoint address from 1 to 240. The address 0 is reserved for the interface to the ZDO, while the address 255 is reserved for broadcasting to all application objects. The endpoints 241-254 are currently not in use and are reserved for future use. (ZigBee-Specification, 2007)

Application profiles Application profiles are agreements for messages, message formats, and processing actions that enable developers to create an interoperable, distributed application employing application entities that reside on separate devices. These application profiles enable applications to send commands, request data, and process commands and requests. Each application profile gets a unique cluster identifier. (ZigBee-Specification, 2007)

ZigBee Device Objects

The ZigBee device objects (ZDO) stands in contact with the application objects, the device profile, and the APS. The ZDO’s responsibilities contains: (ZigBee-Specification, 2007)

 Initializing the application support sub-layer (APS), the network layer (NWK), and the Security Service Provider.  Assembling configuration information from the end applications to determine and implement discovery, security management, network management, and binding management.  Role-defining of the device within the network (ZigBee coordinator, router or end device)

3.1.2.3 Security Services Specification ZigBee’s security services contain methods for key establishment, key transport, frame protection, and device management. The level of security primarily depends on the safekeeping of the symmetric keys, on the protection mechanisms employed, and on the proper implementation of the cryptographic mechanisms and associated security policies involved. The provided security services cryptographically protect the interfaces between different devices only. Separation of the interfaces between different stack layers on the same device is arranged non-cryptographically, via proper design of security service access points. (ZigBee-Specification, 2007)

3.1.2.3.1 Security Keys ZigBee devices support two different types of keys: “link” keys and “network” keys. The receiving device must know whether a frame is protected with a link key or a network key.

Link key: A communication between two peer devices (unicast communication) in a network of ZigBee devices is secured by a link key which is about 128 bits long. A link key may be acquired via key-transport, key-establishment, or pre-installation. The key- establishment technique is based on a “master” key which is acquired via key-transport or pre-installation. The link and master keys may be used only by the APS sublayer and shall be available only to the APL layer.

Network key: A communication to all devices (broadcast communication) in a network of ZigBee devices is secured by a network key which is about 128 bits long. A network key is acquired either via key-transport or pre-installation. The two types of network keys are “standard-” and “high-”security. They differ in the distribution of the network key and does not affect how messages are secured. The (active) network key may be used by the NWK and APL layers. (ZigBee-Specification, 2007)

Figure 27 - link and network key scenarios

3.1.2.3.2 Layer Security The NWK & APS layer are responsible for secure transmission of outgoing frames and for secure reception of incoming frames. In addition the APS layer generates and manages the cryptographic keys, which are either link keys or network keys. It also offers key establishment, key transport, and device management services to applications and the ZDO. The NWK layer may use the Advanced Encryption Standard (AES) and CCM* mechanism for frame-protection. (ZigBee-Specification, 2007)

Figure 28 - ZigBee frame with security on the NWK level (ZigBee-Specification, 2007)

Figure 29 - ZigBee frame with security on the APS level (ZigBee-Specification, 2007)

3.1.2.3.3 ZigBee Coordinator The ZigBee coordinator configures the security level of the network by setting an attribute (nwkSecurityLevel) in the NIB. The network is unsecured if the attribute is set to zero, otherwise it is secured. The ZigBee coordinator also configures the Trust Center’s address by setting an attribute (apsTrustCenterAddress) in the AIB. The default address is the own address of the ZigBee coordinator. (ZigBee-Specification, 2007)

Trust Center Application The Trust Center is an application which runs on a device trusted by devices within a ZigBee network to distribute keys for the purpose of network and end-to-end application configuration management. The Trust Center runs either in low-security or high security mode. (ZigBee-Specification, 2007) .

3.1.2.4 ZigBee Profiles A ZigBee profile, also called application profile, is a collection of device descriptions, which together form a cooperative application. For instance, a thermostat on one node communicates with a furnace on another node. Together, they cooperatively form a heating application profile. ZigBee profiles are either manufacturer-specific or public. Each profile has a unique profile identifier which will be given by the ZigBee Alliance. (ZigBee-Specification, 2007)

3.1.2.4.1 The ZigBee Device Profile The device profile defines general actions between ZigBee devices. It defines clusters like any other ZigBee profile, but unlike other ZigBee profiles those clusters define capabilities which are supported in all ZigBee devices. The Device Profile supports the key inter-device communication functions, as follows: (ZigBee-Specification, 2007):

 Device and Service Discovery  End Device Bind  Bind and Unbind  Binding Table Management  Network Management

3.2 EnOcean EnOcean provides a proprietary system which means that the standard is manufacturer specific and is not open or public. (Gessler & Krause, 2009) This fact makes it difficult to write a scientific work about the standard.

The EnOcean standard was developed in the year 2001 by the same-named company EnOcean. In the year 2008 several well-known companies (e.g. Thermokon Sensortechnik, Beckhoff, Siemens,…) from Europe and North America have created and joined the EnOcean-Alliance. (Schäfer, 2010)

EnOcean is a wireless technology that uses energy harvesting to enable battery less sensors and switches. It is used primarily in building automation. In order to gain energy, electromagnetic, solar cells, thermocouples and other energy converters are used. The energy they produce is enough to transmit the wireless signal over a distance of up to 300 meters. The EnOcean products operate maintenance free and have a service life of at least 50,000 operations. (wiki-EnOcean, 2010)

EnOcean uses the 868 MHz (Europe) frequency band and achieves data rates from up to 125 kBit/s. The technology uses the ALOHA-method instead of CSMA. In this method messages will be send several times, in case of EnOcean it will be send 3 times. In contrast to other technologies the telegram length is very short and contains only 4 user- data-bytes. The number of devices in a network is limited only by the address space (4 Bytes=232). It seems the only drawbacks are that the EnOcean standard has not been released yet as an open international standard (Gessler & Krause, 2009) and that a holistic security concept is missing.

Components of EnOcean devices The idea to this technology came from a simple operation: Where sensors capture measured values, the energy state constantly changes. When a switch is pressed, the temperature alters or the luminance level varies. These operations generate as much energy as a wireless signal needs to be transferred. (EnOcean.com, 2010)

Figure 30 - Energy Harvesting Wireless Sensor Solution from EnOcean (EnOcean.com, 2010)

Each EnOcean module has its own microcontroller that detects measured data (in sensor modules), controls energy management and wireless transmission, and is intelligent enough to make its own decisions for example when another device fails. (EnOcean.com, 2010)

Elements of intelligent Sensors of EnOcean: (EnOcean.com, 2010)

1. Topology of wireless sensor networks: EnOcean prefers to use an optimal mixture of battery-less wireless nodes, line powered wireless nodes and wired information channels.

2. Energy management: More intelligent energy management leads to more cost- attractiveness of components and systems.

3. Software concept: The software of EnOcean modules is either so specialized that no modifications are necessary or it allows application-specific configuration. The aim is easy use of the technology without special knowledge.

Advantages of EnOcean

The three primary advantages are: (EnOcean-Alliance.org, 2010)

1) no wires 2) no batteries 3) no limits

Advantages for Building Professionals: (EnOcean-Alliance.org, 2010)

 Flexibility: no cabling, simple fitting and removal, e.g. switches on glass, stone, wood and furniture  Interoperability: straightforward combination of products from a variety of manufacturers and for a wide selection of applications  Simple planning of complex and flexible systems: optimal sensor positioning even for changing conditions of use  Cost savings in installation, maintenance, renovation and energy use  Large-scale energy savings: through temperature regulation in single rooms, wireless window contacts or lighting control on demand  Environmentally friendly: far less cable material (copper, sheaths, etc)  Interoperability: straightforward combination of products from a variety of manufacturers and for a wide selection of applications  Compatibility with other building automation systems  Time-savings: planning is speeded up, fast fitting, integration, configuration  Scalability of the building system ensures a sustained building structure  Service-free wireless sensors: no batteries needed, so no replacement and disposal worries  Reduced risks through less fire load  Subsequent fitting of wireless sensors in preservation listed buildings  Little noise, dust and dirt

Advantages for Product Manufacturers (OEMs): (EnOcean-Alliance.org, 2010)

 Simple expansion of portfolio to wireless-based products  Ready available and wide-ranging, interoperable system product portfolio  Concentration on own core competences  Fast implementation and time to market  Low investment in R&D, T&M, etc

 Various evaluation tools obtainable to support development  Direct support from EnOcean field applications engineering  Competitive advantage over battery-powered wireless solutions  New differentiated marketing advantages

Advantages for Users: (EnOcean-Alliance.org, 2010)

 Large-scale energy savings: through temperature regulation in single rooms, wireless window contacts or lighting control on demand  Cost benefits in integration, installation and operation  Flexible room arrangement  Enhanced living comfort  Simplified building management: no cabling, simple fitting and removal, e.g. switches on glass, stone, wood and furniture  Fewer outages in facility use  Simple retrofitting of sensors  Time-savings: fast fitting, integration, configuration  Environmentally friendly: far less cable material (copper, sheaths, etc)  Less electrosmog through EnOcean technology  Easier subletting and lower vacancy rates  Service-free wireless sensors: no need for batteries  Products with enabling EnOcean technology available from various manufacturers

3.2.1 Technical description

Switches and Sensor modules from EnOcean harvest energy. Energy sources could be motion, pressure, light, temperature change, rotation and vibration. This tiny energy is enough to supply the sensor, microcontroller and the radiofrequency module with power. (EnOcean.com, 2010)

3.2.1.1 Energy harvesting

Only because EnOcean has managed to reduce drastically the energy consumption of their devices it became possible to use energy harvesting. That is why EnOcean energy harvesting wireless sensors can operate where other technologies fail because they consume too much energy. (EnOcean.com, 2010)

Energy converters / Energy harvesting modules: (EnOcean.com, 2010) ECO 100 – Motion Energy Harvesting: Motion converters are used in switches where the switching operation (push a button) generates the energy:

 Electrodynamics energy converter  User-dependent energy generation from button motion  Service-free for 50,000 switching cycles  For small and flat switch designs

ECS 300/ ECS 310 – Solar Cells: Solar cells generate energy out of light and can be used for the sensors STM 300/ STM 300C:

 ECS 300: 35.0 × 12.8 × 1.1 mm  The smaller ECS 300 is intended to be used in unidirectional sensor applications  ECS 310: 50.0 × 20.0 × 1.1 mm  ECS 310 is designed for use in bidirectional applications using EnOcean Smart Ack technology

ECT 310 – Thermo Energy Harvesting: Thermo converters use lost heat and temperature differences as energy source:

 Standard peltier element in combination with EnOcean ultra low power DC/DC converter  Operation by minimum temperature difference  Maintenance free, full integration possible  Allows energy harvesting actuators

Rotation converter Rotation converters convert the rotation energy into electricity. It can be used for example in Gas or water meters.

Vibration converter Vibration converters convert the vibration energy into electricity. The source of vibration energy could be machines, motor vehicles, persons when they are running and many other originators.

3.2.1.2 Radio technology

Characteristics of the EnOcean wireless standard: (EnOcean.com, 2010) High reliability  License-free 868 MHz frequency band with 1% duty cycle  Multiple telegram transmission with checksum  Short telegrams (approximately 1 ms) for little probability of collision  Long range: 30 meters in buildings and 300 meters in free field  Repeater available for range extension  One-way and bidirectional communication

Low energy  High data transmission rate for sensor information of 125 kbit/s need  Small data overhead  ASK modulation  Even the small amount of energy of 17 µW is enough to transmit an entire telegram which is about 14 Bytes long. (Gessler & Krause, 2009)  The extremely small amount of energy of 50 µWs is enough to transmit a signal up to 300 meters. This is only possible due to the very short signal duration. The entire process from start to finish does not last longer than a thousandth of a second.

Interoperability  Wireless protocol defined and integrated in modules  Sensor profiles specified and implemented by users  Unique transmission ID (32 bits)

Coexistence  No interference with DECT, WLAN, PMR systems, etc with other  System design verified in industrial environment wireless  The reliability of EnOcean modules is given even in industrial systems environments because in the used frequency band there are no permanently sending systems such as DECT, GSM or WLAN. However, the IEEE 802.15.4 standard (which is used for example by ZigBee) also specifies one of the 26 transmission channels on the same frequency as EnOcean. This fact should be considered in the planning phase. (Gessler & Krause, 2009)

Network components: (EnOcean.com, 2010)  Transmitters (switches & sensors): are only able to send and use energy harvesting  Transceivers - Bidirectional components (room controllers & gateways): are able to send and receive; can operate as actuators and/or repeater and/or gateways, are mostly battery or main powered  Receivers - Actuators: are only able to receive and are mostly battery or main powered

Network topology – P2P EnOcean supports only the peer-to-peer network topology where each device type is able to communicate with any other device type in the network.  Transmitters either communicate with bidirectional devices or directly with an actuator.  Actuators either receive information from a bidirectional device or directly from a transmitter.  Bidirectional devices both receive information from a transmitter or from another bidirectional device and transmit information either to an actuator or to another bidirectional device.

Figure 31 - Topology of an EnOcean network (EnOcean.com, 2010)

3.2.1.3 Layer model EnOcean uses three layers of the ISO/OSI-model which are shown in Table 2. (Gessler & Krause, 2009)

Table 2 - layer model of the EnOcean standard (Gessler & Krause, 2009)

Layer Functions

7: Application Layer sensor and actuator profiles

2: Data Link Layer sending the signal threefold and randomly

1: Physical Layer 868.3 MHz, 10mW EIRP, ASK, 125kBit/s

1: Physical Layer

The radio system works within the ISM-band on 868.3 MHz. ASK (Amplitude-Shift Keying) is used as modulation process with a modulation factor of 1 which means that the digital zeros are not transmitted in order to save energy. Another way to optimize energy at data transmission is to communicate the telegrams as fast as possible. Therefore a data rate of 125 kBit/s was chosen although the telegram length is only 14 Bytes long. (Gessler & Krause, 2009) Also the shortness of the telegrams, approximately 1 ms, reduce the probability of collisions. (EnOcean.com, 2010)

2: Data Link Layer

Communication over the EnOcean radio system is generally carried out unidirectional from the energy harvesting sensor to a receiver. Answering or synchronisation services are not used and that is why a bus access procedure like CSMA is not needed. The consequence is that collisions can occur. To minimize the occurrence of collisions the telegrams are transmitted three times. Between the repeating transmissions there are inserted randomly generated waiting times in order to prevent systematic occurring collisions. Transceiver modules allow a bidirectional communication but also have a higher demand for energy. (Gessler & Krause, 2009)

7: Application Layer

On the application layer EnOcean defines several different profiles. These profile- definitions reach from simple signalisation of a switch-state to metered values of a sensor. (Gessler & Krause, 2009)

3.2.1.4 Telegram format In order to transmit packets with only a minimum of energy the telegram-format consists of only a few bytes. The energy that is used for transmission is too low to provide management functions. Each telegram consists of 14 Bytes which contain only necessary information. Figure 32 gives an example of an EnOcean telegram. (Gessler & Krause, 2009)

Figure 32 - EnOcean's telegram format; 1.row: Byte number; 2.row: value (hexadecimal) (Gessler & Krause, 2009)

Table 3 - telegram format description (EnOcean.com, RCM, 2007)

Byte 1-2: Synchronisation Bytes (0xA5 and 0x5A)

Byte 3: Header:  Type of telegram (3 bits): o 0B = Rx receiving telegram o 6B = Tx transmitting telegram  Length (5 bits): Number of Byte following the header

Byte 4: Type of source:  05=PTM  06=STM (1 Data Byte)  07=STM (4 Data Bytes)  08=CTM

Byte 5-8: Data Bytes

Byte 9-12: Address of the sender - 32-bit transmitter ID Each EnOcean transmitter has an individual ID

Byte13: Status information; e.g. repeater level 0 = original message (not repeated)

Byte 14: Checksum Byte; calculated by addition of all octets except sync bytes and checksum.

3.2.2 EnOcean Dolfin System Architecture for developers The EnOcean Dolphin system contains all four sections which are needed to complete an autonomous wireless sensor: (EnOcean.com, 2010) Energy Harvesting

 Energy harvesting sensors harvest energy from their surroundings

EnOcean Modules

 PTM – Pushbutton Transmitter Module  STM – Sensor Transmitter Module  RCM – Receiver Modules  TCM – Transceiver Module

Software

1. A powerful & easy to use operation system 2. Software for modular and versatile, user- friendly integration in applications

EnOcean Wireless Standard

 EnOcean wireless standard uses 868 (Europe) & 315 MHz (North America)  Optimized energy management

The EnOcean Alliance forces the interoperability between different end-products, from different manufactures, based on EnOcean technology by standardizing communication profiles. The document “EnOcean Equipment Profiles (EEP) V2.0 (PDF)“ defines profiles of existing and upcoming types of equipment. (EnOcean-Alliance.org, 2010)

At this time there are about 350 interoperable end products from more than 100 companies on the market which are all based on the EnOcean technology. EnOcean modules are currently built-in in more than 100.000 buildings. Furthermore the EnOcean Alliance tries to establish the technology as an IEC-standard. (Markt&Technik, 2009)

3.2.3 Fields of Application The maintenance free wireless sensors from EnOcean provide a high flexibility at low investment and operational cost. That is why the field of application reaches from home automation to industrial automation and of course other areas of application which we do not know yet. (EnOcean.com, 2010)

Building Automation & Home Automation (EnOcean.com, 2010)  Optimisation of energy saving  Reduction of operating costs  Enhances convenience  Radio technology o permits flexibility o minimizes installation times o reduces system costs  No battery: o Minimizes the maintenance o Eco-friendly o save key resources

Figure 33 - gives an example of a home automation scenario. (EnOcean.com, 2010)

Industrial Automation (EnOcean.com, 2010) Manufacturing:  Lowering costs  Increasing flexibility

Logistics:  Guarantees of quality  Process optimisation

Automotive:  Improve comfort, safety and functionality  Create competitive advantage

Medical:  Continuous patient monitoring  No batteries to maintain  Better patient care

Further applications:  Consumer electronics  Toys  Defence  Homeland security

Figure 34 - gives an example of an industrial automation scenario (EnOcean.com, 2010)

Case Studies On the EnOcean website there are some case studies listed (http://www.enocean.com/en/case-studies/#other).

3.3 Comparison of ZigBee and EnOcean

3.3.1 ZigBee and energy harvesting

The British market research company IDTechEx published an analyses about wireless sensor networks in which comes out that 90 percent of the wireless sensor devices have to be maintenance free. That is why energy harvesting sensors are preferred, instead of sensors which need batteries.

For example two skyscrapers in Madrid together have built-in more than 8000 light switches which use the EnOcean technology. The maintenance would be very cost intensive when using battery powered switches. In addition, there can be savings of about 40 percent of energy, 33km of cable, 20 percent of installation costs and 80 percent of renovation costs. (Markt&Technik, 2009)

2009 the ZigBee Alliance had the idea to publish a ZigBee Green Power profile which connects devices that use energy harvesting techniques. It should use the IEEE 802.15.4 standard operating at 2.4GHz and it should be compatible to ZigBee networks (ZigBeeAlliance, 2009), but there are some barriers:

 There will not be a completely battery-free ZigBee device because it is not possible to get enough power from energy harvesting to implement all the features that make ZigBee ZigBee. (Westervelt, 2009) ZigBee modules need 30 to 100 times more energy than EnOcean modules. If ZigBee wants to use Energy Harvesting it would have to reduce its energy consumption drastically. Therefore it would have to down size its protocol stack. As result the product would lose its interoperability to existing ZigBee versions. (Markt&Technik, 2009)

 EnOcean’s standard operates at either 315 MHz (America) or 868 MHz (Europe), where less power is required than ZigBee needs at 2.4 GHz. (Westervelt, 2009) The reasons are that there would be interferences on the 2.4GHz frequency band which are caused by e.g. WiFi. The existing ZigBee version therefore changes the channels to avoid interferences. Like other ZigBee features these actions consume too much energy in order to use energy harvesting. (Markt&Technik, 2009)

 Beside technical obstacles there is also the problem with patents. The patents of EnOcean cover besides the energy harvesting methods also the method of storing the energy and the method of the radio transmission. EnOcean also holds the patent on the whole modules. (Markt&Technik, 2009) The ZigBee Alliance does not develop energy harvesting techniques but it creates extensions to the existing ZigBee stack that would allow OEMs to use energy harvesting. So the ZigBee standard itself does not stand in violation with EnOcean’s IP (International Protection) but as soon as any OEM partner of ZigBee releases a product which uses ZigBee and energy harvesting, EnOcean lawyers will protect the company’s 40 patent families. (Westervelt, 2009)

3.3.2 Technical comparison 1. Standard: The ZigBee standard is an open standard, whereas EnOcean provides a proprietary standard (closed standard). Both provide open profile-standards. 2. Standard specifications: While the ZigBee standard specifies only the communication between devices and within a device, the EnOcean standard specifies the whole system of the sensor devices, containing energy harvesting, energy management, processing sensor data, and wireless communication. 3. Layer model: The ZigBee protocol stack is based on the IEEE 802.15.4 stack. Together they use four layers whereas the application layer is built up very complex. However, EnOcean’s protocol stack isn’t very complex. It consists of only 3 layers. 4. Layer specifications: Each layer of ZigBee provides its whole frame to the next under-layer as payload. Every layer adds header-fields to the payload and may also footer-fields. Speculation!1: EnOcean’s layers may also add some fields to each upper-layer, but not as much as ZigBee does. 5. Radio frequencies: ZigBee provides three radio frequency bands: 2 regional bands (868MHz-EU & 915MHz-US) and 1 global band (2.4GHz). 6. Network topology: While ZigBee supports star, peer-to-peer (mesh), and tree topologies, EnOcean supports only peer-to-peer networks. 7. Network devices: While ZigBee specifies two types of devices (RFD and FFD), EnOcean specifies three types of devices (transmitters, bidirectional devices, receivers). While EnOcean’s “RFDs” (transmitters, receivers) either transmit or receive messages, ZigBee’s RFDs may communicate in both directions. EnOcean’s RFDs may communicate with RFDs and FFDs, while ZigBee’s RFDs only communicate with FFDs. EnOcean’s “FFDs” (bidirectional devices) as well as ZigBee’s FFDs may communicate with RFDs or other FFDs. While a ZigBee network must provide an internal controller (coordinator), an EnOcean network may outsource coordination through a gateway or it provides an internal room controller. 8. Data transfer (excl. device reg. & instal.): ZigBee’s data transfer is defined as an offer/answer model. That is why it specifies several different frames (beacon, data, ack,..), while EnOcean uses only a data frame. ZigBee’s data transfer model is more complex than EnOcean’s model which simply transmits its messages three times. 9. Saving energy: ZigBee specifies a superframe structur which provides an inactive time where devices turn into sleep mode and safe energy. EnOcean’s devices have very low energy consumption so they can us energy harvesting in order to produce the energy they need. ZigBee’s devices are either battery or main powered. EnOcean’s devices are either energy harvesting or main powered. 10. Security: ZigBee provides security services which contain key establishment, key transport, frame protection, and device management. EnOcean doesn’t provide any security services. 11. Profiles: ZigBee specifies several profiles where each contains a collection of device descriptions, which together form a cooperative application. EnOcean provides only one profile, the EnOcean Equipment Profile (EEP) which describes the functionality of all EnOcean devices.

1 Since EnOcean is not an open standard this statement is a speculation.

Table 4 - Technical comparison of EnOcean and ZigBee (Martin, 2007)

EnOcean ZigBee Standards proprietary, EEP IEEE 802.15.4 + ZigBee (EnOcean Equipment standard + ZigBee Profiles Profiles) Standard status closed open Offering Complete Modules Complete Software Stack for RF Chip Battery & Maintenance free Yes No Network Topology P2P (Gessler & Krause, Star network, P2P/Cluster 2009) tree network (IEEE-Std- 802.15.4, 2006) Frequency 868 (EU) /315 (US) MHz 868 (EU) /915 (US) MHz, 2.4GHz Interference Risk very low very high (2,4GHz) Minimum Telegram period 0.6ms 30ms (868MHz), 4ms (2.4GHz) (Anders & Schmidt) Telegram length (max) 14 Bytes 133 Bytes (IEEE-Std- 802.15.4, 2006) Data Rate 125kb/s 20 - 250kb/s (IEEE-Std- 802.15.4, 2006) Range: Room/Line of Sight 30/300m 30/30-100m (LOS) Sleep Current 0.08µA 1µA Total System Energy Factor 1 Factor 10-100 Requirements Security NO YES (ZigBee- Specification, 2007) Live Cycle - Cost Excellent Good Product Interoperability Yes Some profiles are not compatible with each other OEM Products on Shelves >265 <10 Target Market Residential, Commercial, Industry, Medical, Industrial Telecom, Consumer, Residential, Commercial,…

Comparison of advantages and disadvantages

EnOcean ZigBee

 No Batteries: EnOcean uses energy

 Security: the data transfer is /can be harvesting instead of batteries secured, encrypted  Availability: EnOcean devices are  Lower purchasing costs: the easy to get through the EnOcean purchasing costs of ZigBee modules are Website, and there is a bigger variety lower than for example EnOcean of devices than ZigBee provides modules Advantages  Interoperability: all devices and  Open standard profiles are compatible to each other

 No security: the data transfer is not  Batteries: ZigBee devices are mostly secured, encrypted battery powered  Higher purchasing costs: the  Bad availability: ZigBee modules are purchasing costs of EnOcean hard to get in Europe and there is not modules (sensors, gateways,..) are such a variety of devices as EnOcean higher than for example ZigBee provides. modules.  Bad interoperability: different profiles Disadvantages  Closed standard might not be compatible to each other

 specifies the whole system of a  all that ZigBee specifies is the radio, and device; (energy harvesting, storage, communication radio)

Differences

Results of the comparison The advantages of EnOcean are the disadvantages of ZigBee and vice versa.

The EnOcean technology is perfect in situations where many sensors or switches (~ >100) have to be used, in order to minimise the maintenance costs. EnOcean should not be used where security is important due to the fact that EnOcean has no security functions.

The ZigBee technology is perfect in situations where some sensors or switches (~ <100) have to be used, for example for home automation. Due to the fact that ZigBee has several security features it may be implemented where security is important.

3.3.3 Economic comparison ZigBee Development Kit (digi.com)

The iDigi X4 Starter Kit ZB includes:  ConnectPort X4 gateway w/ Ethernet / router and coordinator  XBee ZB module w/ interface board / end device  XBee ZB wall router / router  XBee ZB light/temperature sensor / end device

Figure 35 - iDigi X4 Starter Kit ZB (digi.com)

Costs: (digistoreeurope.com) iDigi X4 Starter Kit ZB (EU Version): 324,40 Euro +energy costs - Batteries (the more devices the more batteries) +maintenance costs +setup costs

EnOcean Development Kit (EnOcean.com, EDK300, 2010)

EnOcean Developer-Kit EDK 300 includes:

 1x EVA 300 (TCM 3x0) evaluation board  1x EVA 320 (STM3 00) evaluation board  1x TCM 300 with adapter board (Transceiver Modules) / actuators or routers  1x STM 300 with adapter board (Scavenger Transceiver Module) / routers, actuators and sensors  1x TCM 320 (Transceiver Modules) / actuators or routers  1x Self-powered switch PTM 200 (Pushbutton Transmitter Module) / switch  2x EOP 300 Programmer (to load customer specific FW)

Figure 36 - EnOcean Developer-Kit EDK 300 (EnOcean.com, EDK300, 2010)

Costs: (EnOcean.com, EDK300 Press, 2009)

EnOcean Developer-Kit EDK 300: 550 Euro (recommended price) +energy costs +setup costs

4 Project SMART HOME 4.1 Concept The project was a university-research project with the goal of building up an intelligent home network in a laboratory. The decision fell on wireless radio modules with EnOcean technology, because the installation costs as well as the maintaining costs are very low. The maintenance costs are very low because of the use of energy harvesting technology instead of batteries. This fact is important when lots of sensors shall be installed. The lack of wiring the sensors also raises the expandability positively. Because EnOcean does not has as much functions as ZigBee its configuration will be more simple. EnOcean was chosen despite the lack of security functions, since this was only an optional requirement. Sensors and actuators which are based on EnOcean technology communicate with the software "TwinCat" which runs on the PC (Win XP). The bus system of Beckhoff acts as an interface between sensors and the PC. The tasks of the practical part were the building up of the basic hardware and the programming and configuration of the software. Lamps shall be switched by means of EnOcean technology. Other hardware and software implementation as HVAC (heating, ventilation and cooling), blinds, etc... should be addable without much effort.

The tasks of the project were:  Configuration of the Beckhoff (PLC) hardware  Programming the basic Smart Home code  Integration of EnOcean technology (HW & SW)  Integration of KNX/EIB technology (HW & SW)  Remote access over the Internet

Figure 37 - Basic Smart Home configuration

4.1.1 What is the Beckhoff System? Beckhoff implements open automation systems based on PC Control technology. The product range covers Industrial PCs, I/O and Fieldbus Components, Drive Technology and automation software. The Beckhoff “New Automation Technology” philosophy represents universal and open control and automation solutions that are used worldwide in a wide variety of different applications, ranging from CNC-controlled machine tools to intelligent building automation. (Beckhoff.at)

4.1.2 EnOcean integration into the Beckhoff system My part of the Smart Home Project was the integration of EnOcean, which is described in detail in the following chapters. There are two possible ways for EnOcean integration. In the first one the Beckhoff-System acts only as actuator and is able to read data of sensors. All actuators receive the same ‘Sender ID’. In case two, the Beckhoff-System acts as a Room Controller. It receives EnOcean data with the IDs of the sensors and transmits data with its own EnOcean transceiver IDs. The ID of a device is unique and not changeable.

Figure 38 - EnOcean integration – Case 1: read Figure 39 - EnOcean integration – Case 2: read only and write

Tasks for Implementation: 1. Wiring the EnOcean Transceiver KL6583 with the Beckhoff connector block KL6581 2. Programming the EnOcean integration in the software PLC a. Receiving EnOcean telegrams b. Providing the EnOcean data to the rest of the program c. Sending EnOcean telegrams 3. Configuration of the EnOcean actuator using the software “SRC-ADO-V3”

Figure 40 – Smart Home project from EnOcean side

4.1.3 What is KNX? The Konnex bus (KNX) is a fieldbus for building automation. It was developed out of the European Installation Bus (EIB), the BatiBUS and the European Home Systems (EHS). Developer is the Konnex Association. The Konnex bus is the successor of these fieldbuses and is backward compatible with the EIB bus. The aim is to develop a unified flexible array bus that will meet the future requirements for a flexible building automation. (itwissen.info - KNX)

4.2 Hardware Design

4.2.1 Hardware components Table 5 contains a list of the basic hardware components and all components which are relevant for EnOcean integration. Descriptions of these components may be found in appendix: “B: Description of hardware components relevant for EnOcean integration”

Table 5 - EnOcean relevant component list

Type Quantity Description Costs in € FC9002 1 Ethernet PCI network card 198,00 BK9050 1 Bus Coupler 168,00 KL9010 1 Bus End Terminal 9,46

KL2722 = 1 Output terminals; The switching element is a triac 29,40 KL2012 KL6581 1 EnOcean Master Terminal (bidirectional) 185,00 KL 6583 1 EnOcean transmitter and receiver (unidirectional) 155,00

PG1 1 Universal Wireless Switch (4 channel Light) 61,00 SR04PST 1 Wireless Room Temperature Sensor 162,00 SR65 1 Wireless Outdoor Temperature Sensor 124,20 SRG01 1 Window handle 76,80 SRW01 1 Wireless window contact 62,00 Wireless EnOcean actuator (Receiver) with analog & SRC ADO 1 308,88 digital outputs (4AA/4DA)

1 24V lamp - green ~10

1 24V lamp - red ~10

2 Power transformer: 230AC  24AC ~40

4.2.2 Hardware installation and configuration (EnOcean) The usage of the transceiver KL6583 allows both the receiving and sending of EnOcean signals. The transceiver module communicates by wire with the Beckhoff KL6581 EnOcean master terminal, which is the connecting link between the transceiver and the application.

a) Wiring

Figure 41 - How the wiring is done (Beckhoff, KL6581,KL6583, 2010)

Connect the cables as follows: (Beckhoff, KL6581,KL6583, 2010)

1. Open a spring-loaded terminal by slightly pushing with a screwdriver or a rod into the square opening above the terminal. 2. The wire can now be inserted into the round terminal opening without any force. 3. The terminal closes automatically when the pressure is released, holding the wire securely and permanently.

Table 6 - Wiring data (Beckhoff, KL6581,KL6583, 2010)

Terminal housing KLxxxx Wire size width 0,08 ... 2,5 mm2 Wire stripping length 8 ... 9 mm

Figure 42 and Figure 43 illustrate a connection plan and a description of how to connect the KL6583 to the KL6581. The connection plan shows where to connect which cable. The data cables (Can+ and Can-) of the KL6583 module are connected at the terminal points A (No.1) and B (No.5) at the KL6581. The KL6581 terminal gets its power through the power contacts from the BK9050, shown in the picture below. The KL6581 terminal may forward the power to one or more KL6583 modules by connecting them to the terminal points No.2 and 3 or 6 and 7. For the connection between the KL6581 and KL6583 a CAN cable should be used which must not be longer than 500 meters.

Figure 42 - Connection plan of KL6581 (Beckhoff, KL6581,KL6583, 2010)

Figure 43 - Connection plan of KL6583 (Beckhoff, KL6581,KL6583, 2010)

Table 7 - Connections points of KL6581 and KL6583 (Beckhoff, KL6581,KL6583, 2010)

Terminal point Connection point No Description on KL6581 on KL6583 A CAN + 1 Data contact B CAN - 5 Data contact + 24 V DC + 24 V DC 2, 6 24 V power contacts 0 V GND 3,7 GND power contacts Shield Shield 4, 8 Shield

Figure 44 gives an overview of the connection between the KL6581 and KL6583. It shows a second KL6583 module but which is not implemented in this project.

Figure 44 - Connections between KL6581 and KL6583 (Beckhoff, KL6581,KL6583, 2010)

b) Configuration of a KL6583

 Node address By turning the switch S3 the node address can be changed. Valid addresses reach from 1 to 8. If more than one KL6583 module is used than each module must have a different address. This fact limits the number of modules to eight. (Beckhoff, KL6581,KL6583, 2010) In this project the node address “1” was chosen because there is only one KL6583.

Figure 45 - Node address switch of KL6583 (Beckhoff, KL6581,KL6583, 2010)

 Termination resistor In the last KL6583 module the termination resistor has to be activated. This is done by setting both DIP switches S1 and S2 to ON as shown in the picture below. 1 means OFF while ON means ON. (Beckhoff, KL6581,KL6583, 2010) Because our project owns only one KL6583 it is also the last in the row and therefore the termination resistor ha to be activated.

Figure 46 – configuration of the termination resistor (Beckhoff, KL6581,KL6583, 2010)

c) Connecting the KL6581 to the BK9050

Now the KL6581 terminal gets attached to the BK9050 bus coupler. The power connectors on the BK9050 are fed with 24V DC. The KL6581 receives the power supply of 24V and forwards it to the end device KL6583 EnOcean Transceiver which works with 24V. The picture beneath illustrates where the terminal KL6581 may be placed and how the power supply is implemented.

Caution! It must be assured that terminals, between the BK9050 Bus Coupler and the KL6581 EnOcean Master Terminal, forward the voltage through power contacts.

Figure 47 - Voltage and terminal arrangement of the terminals KL6581 and KL2012 to the BK9050/ edited picture of ... (Beckhoff, BK9050, 2008)

d) Diagnostic LEDs and error handling By watching the LEDs it can be seen if everything is running fine or if there is an error.

 BK9050 The picture below illustrates the BK9050 and shows the specified names of each LED while the tables below the picture reveal the meaning of each LED.

Figure 48 - BK9050 and its diagnostic LEDs (Beckhoff, BK9050, 2008)

Table 8 - LEDs for power supply diagnosis (Beckhoff, BK9050, 2008)

Power LEDs Meaning

Us off: Bus Coupler has no voltage 24 VDC

Up off: No 24 VDC power supply connected to the power contacts

Table 9 - LEDs for K-bus diagnostics (Beckhoff, BK9050, 2008)

K-bus Meaning

K-bus RUN on or flashing: K-bus running

K-bus ERR Flashing: an error occured

Table 10 - LEDs for Ethernet diagnostics (Beckhoff, BK9050, 2008)

Ethernet Meaning

WD ERR on: Watchdog Error

COM on or flashing: Communication with controller

ERROR flashing: DHCP or BootP active. Waiting for an IP address

on: hard real time is switched on at TC. No ADS communication is RTE possible at the same time. All TCP, UDP and ICMP telegrams (e.g. ping) will not be answered.

on: LINK available LINK/ACT flashing: LINK available and communication

 KL6851 The picture below illustrates the LEDs of the KL6581 while the table below the picture indicates the operating state of each LED.

Figure 49 - LEDs of KL6581 (Beckhoff, KL6581,KL6583, 2010)

Table 11 - Meaning of the KL6581 LED displays (Beckhoff, KL6581,KL6583, 2010)

State and significance LED Color On off flashing

Lit, either weakly or strongly: No K-Bus K-Bus K-Bus Run green K-Bus communication is OK communication communication

Error red Fault occurred No error -

Data are being sent to a Data Send green - KL6583 communication

Data are being received Data Receive green - from a KL6583 communication

 KL6583 The picture below illustrates the LEDs of the KL6583 while the table below the picture indicates the operating state of each LED.

Figure 50 - LEDs of KL6581 (Beckhoff, KL6581,KL6583, 2010)

Table 12 - Meaning of the KL6583 LED displays (Beckhoff, KL6581,KL6583, 2010)

State and significance LED Color On off flashing

24 V Power supply not LED 1 Green - present connected

No error (no EnOcean Lights up briefly each time an LED 2 Green - telegrams being sent) EnOcean Frame is sent

- 200 ms wrong node address (valid addresses: 1 to 8) - 1 second no communication with the LED 3 Green No error - KL6581 - goes out briefly, EnOcean data being received or sent

e) Range planning In order to assure the reception of a signal the maximum transmission range must not be exceeded. Additionally different materials between the transmitter and the receiver can reduce the transmission range. The following tables show the attenuation of different materials and their influence on the range.

Table 13 - Attenuation of different materials (Beckhoff, KL6581,KL6583, 2010)

Material Attenuation

Wood, plaster, uncoated 0...10 % glass (without metal)

Brick, chipboard 5...35 %

Concrete with iron 10...90 % reinforcement

Metal, aluminum cladding 90..100 %

Table 14 - Impact on the range (Beckhoff, KL6581,KL6583, 2010)

Material Range

Line of sight Typically 30 m in corridors, up to 100 m in halls

Plasterboard walls/wood Typically 30 m, through max. 5 walls

Brick walls/aerated Typically 20 m, through max. 3 walls concrete

Reinforced concrete Typically 10 m, through max. 1 wall/ceiling walls/ceilings

Caution! The distance of the KL6583 module to a reinforced concrete ceiling should be at least 50 cm and to a wall 10 cm. Do not attach or screw the KL6583 module to a metal plate! Maximum air humidity 95% without condensation and ambient temperature 0 - 55°C. (Beckhoff, KL6581,KL6583, 2010)

4.3 Software Design The Beckhoff hardware BK9050 works only in combination with a software PLC which runs on a computer. The software which is used is called “TwinCat”. The configuration software for the EnOcean actuator “SRC ADO” is called “SRC-ADO-V3”.

4.3.1 TwinCat TwinCAT PLC Control PLC stands for Programmable Logic Controller. Usually it is a device that is used for the control of a machine or system and is programmed on a digital basis. TwinCAT PLC Control is a program which runs a software PLC and runs on an external computer. It offers a complete development environment for control. (Beckhoff, TwinCat_PLC_1) TwinCAT PLC runs under the Windows NT/2000/XP/Vista operating systems and includes both the programming environment and the run-time system. The PLC program may be written in the languages provided by the IEC 61131-3 standard: (Beckhoff, TwinCat_PLC_2)

 IL (Instruction List)  LD (Ladder Diagram)  FBD/CFC (Function Block Diagram)  SFC (Sequential Function Chart)  ST (Structured Text)

TwinCAT System Manager The TwinCAT System Manager is the configuration center for the system: Relationships are defined between the number of PLC systems, PLC system programs, configuration of axis control, and connected I/O channels. The System Manager: (Beckhoff, TwinCat_SysMgm)

 Connects I/O devices to tasks in a variable-oriented manner  Connects tasks to tasks in a variable-oriented manner  Supports units at the bit level  Supports synchronous or asynchronous relationships

4.3.1.1 TwinCat version & libraries  Version: o TwinCat 2.11, Built 1553

 Libraries: o Standard.lib o TcBase.lib

o TcSystem.lib  Logfile o TcKL6581.lib  EnOcean o TcBABasic.lib  Home Automation o TcUtilities.lib  System Time o TcKL6301.lib  EIB/KNX o TcMouseEvents.lib  Visualisation

4.3.2 SmartHome Software - Source Code (PLC) Version 1.7 of the source code is the latest version I have created and I have been working with. The software consists of the following parts whereas the parts written in bold were field of my responsibility:  “EIB/KNX” folder contains programs for KNX integration  “EnOcean” folder contains programs for EnOcean integration. EnOcean data may be received and/or transmitted  “Logfile” folder contains programs for creating a “.csv” logfile  “RoomTypeNumber” folder contains a function block which defines functions of a room, e.g. switching a light  “Main” program calls up all programs and makes it possible to connect an EnOcean-function with an Room-function, e.g. a connection of the EnOcean- Switch-function with the Room-Light-function

The software connects EnOcean data-inputs and -outputs with function-blocks which are used for example to switch a light.

Figure 51 - Structure of the project (green colored programs are not in use)

4.3.2.1 Description of P_EnOcean 1. Main-Communication Function Block for KL6581

This function block is responsible for communication with the KL6581 EnOcean Bus Terminal. Data exchange with the EnOcean network is started via this function block. (Beckhoff, KL6581,KL6583, 2010)

Restrictions: (Beckhoff, KL6581,KL6583, 2010)  This block may only be called once per KL6581!  In the PLC project this block may only be called once per cycle  A PLC project may contain a maximum of 64 KL6581 terminals!

Program:

Variable declaration: VAR:

Figure 52 - P_EnOcean - Main FB

Inputs & Ouputs: (Beckhoff, KL6581,KL6583, 2010) bInit: “TRUE” activates the function block nIdx: a unique number for each KL6581 terminal (valid values: 1 to 64) bError: if “TRUE” an error occurred str_KL6581: linked with the send and receive blocks.

Data types: (Beckhoff, KL6581,KL6583, 2010) KL6581_INPUT: Is linked to the input addresses of the KL6581 KL6581_OUTPUT: Is linked to the output addresses of the KL6581

2. Search EnOcean Device ID

This function block reads the EnOcean ID of all devices that it has received and writes them in an array with a size of 256. (Beckhoff, KL6581,KL6583, 2010)

Program:

Variable declaration: VAR:

VAR_PERSITENT:

VAR_CONSTANT:

Figure 53 - P_EnOcean - Search FB

Inputs & Ouputs: (Beckhoff, KL6581,KL6583, 2010) bInit: “TRUE” activates the function block str_KL6581: linked with the main function block “FB_KL6581_KL6583_No1”. byNode: ID of KL6583 Transceiver; if “0”  all KL6583s are received; if a value of 1 to 8  only the corresponding KL6583 is received. ar_ID: output array[0…255] which includes all EnOcean IDs that were found.

After the device IDs are found, they could be allocated to constant variables which cannot be changed by the program.

3. Switch No.1 - PG1

This function block processes received switch data. One function block is used for each switch. The data is given out in a data structure with a variable for each button. The variables are of the data type “Boolean”. (Beckhoff, KL6581,KL6583, 2010)

Program:

Variable declaration: VAR:

VAR_OUTPUT:

Data type:

Figure 54 - P_EnOcean - Switch FB

Inputs & Ouputs: (Beckhoff, KL6581,KL6583, 2010) str_KL6581: linked with the main function block “FB_KL6581_KL6583_No1”. byNode: ID of KL6583 Transceiver; if “0”  all KL6583s are received; if a value of 1 to 8  only the corresponding KL6583 is received. dw_ID: EnOcean ID of the device to be received. str_EnOceanSwitch: output of the switch data; data type = “str_EnOceanSwitch”

The variable “str_Data_Switch_No1” is defined as output variable in order to provide its content/status to other programs.

4. Window Handle No.1 - SRG01

This function block processes data from a window handle. The data is given out in a data structure with a variable for each condition. The variables are of the data type “Boolean”. (Beckhoff, KL6581,KL6583, 2010)

Program:

Variable declaration: VAR:

VAR_OUTPUT:

Data type:

Figure 55 - P_EnOcean - Window Handle FB

Inputs & Ouputs: (Beckhoff, KL6581,KL6583, 2010) str_KL6581: linked with the main function block “FB_KL6581_KL6583_No1”. byNode: ID of KL6583 Transceiver; if “0”  all KL6583s are received; if a value of 1 to 8  only the corresponding KL6583 is received. dw_ID: EnOcean ID of the device to be received. ar_Data: output of the window handle data; data type = “ar_EnOceanWindow”

The variable “ar_Data_WindowHandle_No1” is defined as output variable in order to provide its content/status to other programs.

5. Window Contact Sensor No.1 - SRW01

This function block processes data from a window contact. The data is given out through two variables, one for each status (open or close).

Program:

Variable declaration: VAR:

VAR_OUTPUT:

Figure 56 - P_EnOcean - 1BS FB - Window Contact

Inputs & Ouputs: (Beckhoff, KL6581,KL6583, 2010) str_KL6581: linked with the main function block “FB_KL6581_KL6583_No1”. byNode: ID of KL6583 Transceiver; if “0”  all KL6583s are received; if a value of 1 to 8  only the corresponding KL6583 is received. dw_ID: EnOcean ID of the device to be received. bOpen: “TRUE” if contact is open. bClose: “TRUE” if contact is closed.

The variables “bOpen_WindowContact_No1” and “bClose_WindowContact_No1” are defined as output variables in order to provide their content/status to other programs.

6. Indoor Temperature Sensor No.1 - SR04PST

Because there is no special function block for temperature measuring devices the function block “fb_Rec_Generic” was chosen. It receives all kinds of EnOcean telegrams. In order to interpret the data the manufacturer’s documentation for the sending EnOcean device is necessary, see Table 26 - SR04PST EnOcean telegramTable 26. (Beckhoff, KL6581,KL6583, 2010)

Program:

Variable declaration: VAR:

Figure 57 - P_EnOcean - Generic FB - IndoorTemp

Inputs & Ouputs: (Beckhoff, KL6581,KL6583, 2010) str_KL6581: linked with the main function block “FB_KL6581_KL6583_No1”. byNode: ID of KL6583 Transceiver; if “0”  all KL6583s are received; if a value of 1 to 8  only the corresponding KL6583 is received. dw_ID: EnOcean ID of the device to be received. ar_Value: 4-byte EnOcean data is saved as an array [0…3]  see 8)

Following functions convert the binary data into temperature & turn-switch status: (Beckhoff, KL6581,KL6583, 2010)

Program:

Variable VAR_OUTPUT: declaration:

Figure 58 - P_EnOcean - Conversion Functions - IndoorTemp

 F_BYTE_TO_TEMP function This function converts a byte raw value into a REAL variable.

Inputs & Ouputs: byData: Raw data minTemp: Minimum temperature. maxTemp: Maximum temperature. f_Byte_To_Temp: Temperature value, scaled over min temp and max temp.

 F_BYTE_TO_TURNSWITCH function This function converts a byte raw value into a bool array, which is present as a data structure.

Inputs & Ouputs: byData: Raw data minTemp: Minimum temperature. maxTemp: Maximum temperature. f_Byte_To_TurnSwitch: data structure (AUTO, 0, I, II, III).

The variables “r_Data_Temperatur_InTemp_No1”, “r_Data_SetPoint_InTemp_No1” and “str_Data_FanSpeed_InTemp_No1” are defined as output variables in order to provide their content/status to other programs.

7. Outdoor Temperature Sensor No.1 - SR65

Program:

Variable declaration: VAR:

Figure 59 - P_EnOcean - Generic FB - OutdoorTemp

Inputs & Ouputs: (Beckhoff, KL6581,KL6583, 2010) str_KL6581: linked with the main function block “FB_KL6581_KL6583_No1”. byNode: ID of KL6583 Transceiver; if “0”  all KL6583s are received; if a value of 1 to 8  only the corresponding KL6583 is received. dw_ID: EnOcean ID of the device to be received. ar_Value: 4-byte EnOcean data is saved as an array [0…3]  see 7)

The following function converts the binary data into a temperature value: (Beckhoff, KL6581,KL6583, 2010)

Program:

Variable declaration: VAR_OUTPUT:

Figure 60 - P_EnOcean - Conversion Functions – OutdoorTemp

 F_BYTE_TO_TEMP function This function converts a byte raw value into a REAL variable.

Inputs & Ouputs: byData: Raw data minTemp: Minimum temperature. maxTemp: Maximum temperature. f_Byte_To_Temp: Temperature value, scaled over min temp and max temp.

The variable “r_Data_Temperatur_OutTemp_No1” is defined as output variable in order to provide its content/status to other programs.

8. Send Switch Data This function block is responsible for sending switch data using EnOcean technology.

Program:

Variable declaration: VAR:

VAR_INPUT:

Figure 61 - P_EnOcean - Switch Send FB

Inputs & Ouputs: (Beckhoff, KL6581,KL6583, 2010) bStart: “TRUE” starts sending the data. byNode: Address of the desired KL6583 module (valid values: 1 to 8). bData: data to be sent. (true or false) nRockerID: number of the button (valid values 0 to 3). nEnOceanID: a value of 0 to 127 is added to the EnOcean ID of the transceiver (valid values: 0 to 127). str_KL6581: is linked with the main function block “FB_KL6581_KL6583_No1”.

The variables “nRockerID_Send:Switch_No1”, “bStart_Send_Switch_No1” and “bData_Send_Switch_No1” are defined as input variables in order to provide write rights to other programs.

4.3.2.2 Description of P_EnOcean_DataMngt This program completes the EnOcean integration by adding two functions which handle with the data of the “P_EnOcean” program.

1. Variables used in this program

Figure 62 - P_EnOcean_DataMngt - Variables

2. Call up of the P_EnOcean program

In order to write the inputs and read the outputs of the “P_EnOcean” program it has to be added. This is done by clicking the F2 button, and choosing the “P_EnOcean” program which can be found in the category “Defined Prgrams”(Definierte Programme).

Figure 63 - P_EnOcean_DataMngt - Calling up the P_EnOcean program

In the programable window the “P_EnOcean” program appears with its input and outputs.

Figure 64 - P_EnOcean_DataMngt – Called up P_EnOcean program

3. “Caution!” variable

This self-defined function causes a warning if the status of the window contact is not the same as the status of the window handle. For example, if the window handle would be open while the window would be closed there would be a warning for security reasons. Two output variables of the “P_EnOcean” program are used: 1. bClose_WindowContact_No1 2. ar_Data_WindowHandle_No1.bClose

Figure 65 - P_EnOcean_DataMngt - Caution! function

4. Creation of Buttons for sending Switch data

This self defined function generates four buttons, which are used to generate a virtual EnOcean switch. It uses input variables of the “P_EnOcean” program.

Figure 66 - P_EnOcean_DataMngt – Button creation for sending EnOcean switch data

4.3.2.3 Description of FB_Room_Type_Number 1. Variables used in FB_Room_Type_Number

“FB_Room_Type_Number” is a self-programmed function block which defines a set of input variables.

Figure 67 - FB_Room_Type_Number - Variables

2. Logic for 24V_LED_Red & Green

These two functions are configured to switch between a red and a green light. Only one light illuminates at a time.

Figure 68 - FB_Room_Type_Number - Logic for 24V LED

3. Logic for dimmable light

This function is configured to switch a dimmable light.

Figure 69 - FB_Room_Type_Number - Logic for dimable light

After programming is finished the sequence of the blocks has to be ordered. Right click  sequence  order everything in data flow

Figure 70 - FB_Room_Type_Number - ordering in data flow

4.3.2.4 Description of MAIN 1. Variable of the MAIN program

The main program defines a new variable with the name “FB_Room_Labor_1”. It is a function block which is of the type “FB_Room_Type_Number”.

Figure 71 - Main - Variables

2. Call up the program P_EnOcean & P_EnOcean_DataMngt

In order to start the programs “P_EnOcean” and “P_EnOcean_DataMngt” and to use their inputs and outputs they have to be called up in the main program.

Figure 72 - Main - Calling up the programs "P_EnOcean" and "P_EnOcean_DataMngt"

3. Optional: Call up the program P_EIB In order to demonstrate the interconnection between EnOcean and KNX the program “P_EIB” may get called up in order to start it and use its inputs and outputs. The following code line describes a situation where the pressing of the EnOcean switch “Switch_No1” button “bT2_ON” and button “bT2_OFF” results in switching a KNX actuator. Therefore the output of “P_EnOcean” is linked to the input of “P_EIB”.

Figure 73 - Main - Calling up the "P_EIB" program

4. Call up the Logfile programs

The program “P_GetTime()” is responsible for generating a 10 seconds and a one minute clock signal. The program “P_Logfile” is responsible for generating a logfile and for writing into it. It is called up in the program “P_IOs” where it is defined where to save the logfile and what is written in.

Figure 74 - Main - Calling up the programs "P_GetTime" and "P_IOs"

5. Create a room by using the function block “FB_Room_Type_Number”

The self defined function block “FB_Room_Type_Number” now may be used as a model for many rooms. The following code lines describe a room called “Labor 1” which is of the type “FB_Room_Type_Number”. Outputs of the program “P_EnOcean” are linked to the inputs of this function block in order to switch the lights.

Figure 75 - Main - Calling up a function block named "FB_Room_Labor_1"

4.3.2.5 Description of the Visualisation The visualisation is used for verifying the EnOcean integration. It displays the EnOcean data inputs graphically and contains a virtual switch for sending EnOcean switch data.

Figure 76 - Visualisation

4.3.3 SmartHome Software – Configuration

4.3.3.1 TwinCat PLC Control - Phase 1  Open the TwinCat PLC project which is of the data type “.pro”.  After programming is done go to”Project”  “compile all”. This will generate a “.tpy” file which will be opened in the System Manager.

Figure 77 – PLC Control- Compile project

4.3.3.2 TwinCat System Manager In config mode right click on I/O devices and then left click search for devices. A list of possible Ethernet interfaces appears. Choose the one where the bus coupler is connected. A list of connected devices appears. Then choose the appropriate bus coupler device.

Figure 78 - System Manager - Search for bus coupler and terminals

The device and its terminals appear now in the System Manager. The following figure shows the bus coupler which is of the type “BK9050” and which is also called terminal 1. For EnOcean integration terminal 2 is used which is the EnOcean Master Terminal (KL6581). Terminal 9 (KL2012) is used for switching two 24 V AC LEDs.

Figure 79 - System Manager - IO device found

Now the PLC software project may be added by right clicking on “PLC configuration” and choosing “Append PLC Project”. Now choose the “.tpy” file which has been generated before.

Figure 80 - System Manager - Add PLC project

Now the inputs of the PLC software project may be connected to the inputs of the hardware. And the outputs of the PLC software project may be connected to the outputs of the hardware.  Right click on the input “P_EnOcean.stKL6581_in” and choose “Change link”.

Figure 81 - System Manager - Change Link – EnOcean inputs

 Choose the hardware inputs of the terminal 2 (KL6581).

Figure 82 - System Manger - Choose hardware inputs

 Do the same with the software and hardware outputs.  Right click on the output “Main.Room_Labor_1.bSwitchable_24_LED_Red” and choose “Change link”.

Figure 83 - System Manager – Change link – Red LED

 Choose the hardware output of the terminal 9 (KL2012) where the red LED is connected.

Figure 84 - System Manager - - Choose hardware outputs

 Do the same with the outputs for the green LED.

 Now a mapping has to be generated by right clicking on “Mappings” and then choosing “Generate Mappings”.

Figure 85 - System Manager - Generate Mappings

Figure 86 - System Manager - Mapping generated

 Now the configuration has to be checked by choosing “Actions”  “Check Configuration” or by clicking the appropriate icon in the toolbar.

Figure 87 - System Manager - Check configuration

 If no error appears when checking the configuration the configuration has to get activated by choosing “Actions”  “activate configuration…” or by clicking the appropriate icon in the toolbar.

Figure 88 - System Manager - Activate configuration

 After activating the configuration the software automatically asks you to restart in “Running Mode”. Click  OK

Figure 89 - System Manager - Restart in Running Mode

4.3.3.3 TwinCat PLC Control – Phase 2  Before starting the program it has to be logged in. This is done by choosing „Online“  „Login in“ or by clicking the appropriate icon in the toolbar.

Figure 90 - PLC Control - Login in

 Now the program may be started by choosing “Online”  “Start” or by clicking the appropriate icon in the toolbar.

Figure 91 - PLC Control - Start program

4.3.4 SmartHome Software - Running System

4.3.4.1 PLC Control – P_EnOcean The following two figures show the “Variables Window” of the “P_EnOcean” program in running mode.  The first one illustrates the function block “fb_EnOcean_Search_1” and its variables. As can be seen the function block saves all recorded device IDs into the variable “ar_ID”. After the IDs are recorded the may be saved as a constant variable.

Figure 92 - PLC Control Running - Search function block

 The second figure illustrates all self created variables which are connected to all function blocks which are used in the “P_EnOcean” program. They may be used by other programs, for example by the Visualisation.

Figure 93 - PLC Control Running - Variable of all devices

4.3.4.2 Visualisation The components of the visualisation are directly controlled by the variables of the programs: “Main” and “P_EnOcean”. The visualisation for EnOcean integration contains of the following blocks:  “HVAC-Sensor” block: At first, it shows the outdoor temperature from the “SR65” sensor. It also shows the indoor temperature, the set point temperature, and the fan speed which was received from the “SR04PST” sensor. All blocks are connected to variables of the program “P_EnOcean”.  “Window Sensor” block: The formation which looks like a plus sign illustrates the status of the window handle “SRG01”. The formation beneath illustrates the status of the window contact “SRW01”. All blocks are connected to variables of the program “P_EnOcean”. The caution block is connected to the “Caution” variable of the program “P_EnOcean_Data_Mngt”.  “Switches for Lightcontrol” block: On the left side of the block two lamps can be seen which are toggled by the EnOcean switch “PG1”. On the right side of the block a dimmable light can be seen which may be dimmed using the EnOcean switch “PG1” or using the scrollbar. The actual brightness of the lamp is illustrated as an integer variable which reaches from 0 to 32767 and is shown inside of the lamp. By pushing the “MasterSwitch_OFF” button all lights are turned off. All blocks are connected to variables of the programs “Main” and “P_EnOcean”.  “Switch Sending” block: This block illustrates a virtual switch. By pressing the buttons the variables of the program “P_EnOcean_Data_Mngt” are toggled.

Figure 94 - SmartHome - EnOcean Visualisation

4.3.5 SRC-ADO-V3 configuration software The actuator “SRC ADO 4AO 4DO” is to be configured through the software “SRC-ADO- V3”. Therefore the software has to be installed first. The actuator must also be connected to the computer by a USB cable.

4.3.5.1 Getting started  The program is started by clicking the “SRC-ADO_V3” icon on the desktop or in the start menu.

Figure 95 - SRC-ADO-V3 software icon

 On the start screen all outputs, analogue and digital, are listed. In this example the analogue output “AO1” is to be configured. As sensor type an individual sensor was chosen. In order to configure the output the icon left to the green ”Info” icon has to be pressed.

Figure 96 - SRC-ADO-V3 - start screen

 The following figure shows the configuration options for the output “AO1”. It has to be configured which of the four data bytes to use. Also the size of the min and max output voltage and the scaling of the bits have to be configured.

Figure 97 - SRC-ADO-V3 - Analogue output 1 configuration, “parameter” view

 Next step is to change to “sensors” view in the menu bar. There a sensor type has to be chosen first. In this example the sensor type “Button 4” was chosen which stands for a switch with four buttons. In order to teach in the sensor ID the button “Teach in sensor ID” has to be pushed.

Figure 98 - SRC-ADO-V3 - Choose sensor type

 A window pops up the type of learning-in has to be chosen. In this example the second option “Learning sensor ID by learn-in button” was chosen. After clicking the “OK” button the software listens for EnOcean telegrams. At this point a button of the virtual EnOcean switch has to be bushed which was programmed in the PLC Control program before.

Figure 99 - SRC-ADO-V3 - Learn-in sensor ID

 The EnOcean ID of the switch appears now in the Sensor-ID field shown in the following figure. The ID is a combination of the ID of the EnOcean transceiver “KL6581” and the number defined in the variable “nEnOceanID” of the function block “fb_Send_RPS_Switch_No1”.

Figure 100 - SRC-ADO-V3 – sensor ID was found

A change back to “Parameters” view illustrates the effect of pushing a button. Pushing buttons of the virtual EnOcean switch “fb_Send_RPS_Switch_No1” causes changes in voltage level of the output “AO1”.

 Button1  0.6 Volt  Button2  3.1 Volt  Button3  5.6 Volt  Button4  8.2 Volt

Figure 101 - SRC-ADO-V3 and virtual switch button1

Figure 102 - SRC-ADO-V3 and virtual switch button2

Figure 103 - SRC-ADO-V3 and virtual switch button3

Figure 104 - SRC-ADO-V3 and virtual switch button4

4.4 Project evaluation The installation costs of the EnOcean devices are as low as expected because the sensors and switches could be set up and mounted anywhere and had not to be wired due to their wireless transmission.

Using 1000 Sensors which are working with energy harvesting the maintenance costs are significantly lower than using 1000 battery powered devices such as the ZigBee devices. However, since at this project not ZigBee devices where available that statement remains an assumption.

The hardest part was in fact learning the programing languages of the IEC 61131-3 standard. Once they were learned and understood the programming itself was not a problem anymore. Especially programming of the integration of EnOcean would not have gone so quickly without help. That is why I decided to participate on a course about TwinCat at Beckhoff in Bludenz. During my three-day attendance I have learned programming with TwinCat which would have taken two or three months without training. For this reason I really recommend participating on training courses for situations of this kind.

Without a room controller the switches and sensors would communicate directly with the actuator. This actuator from Thermokon is configured by connecting it with a PC where it provides a clear user interface. It does not offer as many features which are possible when using the PLC from Beckhoff as room controller.

The PLC of Beckhoff is able to handle the required number of about 1000 sensors and switches without problems. The actuator from Thermokon may only manage 15 sensors or switches. If 1000 sensors shall be used multiple sensors and switches with the same function may be combined to one virtually device by the Beckhoff PLC. With such a high number there have to be some more actuators in use anyway or the devices are controlled and connected to the PLC by wire.

After a short training phase of configuring the actuator from Thermokon with EnOcean technology, it should not be a problem to setup a Smart Home. However, a few basic skills when working with power lines should not be missed. Working with the PLC from Beckhoff I do recommend for professionals and amateur professionals only, because for this purpose programming skills and circuit design skills are required.

5 Summary & Outlook ZigBee devices run either with batteries or are connected to the power supply. They are usually cheaper than comparable EnOcean devices. There are still incompatibilities between different ZigBee profiles. The devices transmit with 868MHz and 2.4 GHz in Europe and do support encryption of wireless communications.

Those who do not care about security features in their Smart Home should take EnOcean. This is indeed a proprietary standard, but its battery-free technology is convincing. This technique is called energy harvesting and uses for example the energy from pressure, energy out of temperature differences, solar energy, etc. in order to generate energy and thus runs completely without battery. The EnOcean standard provides better compatibility between the profiles. The devices transmit at 868MHz in Europe.

While ZigBee is seen more as a developer-friendly open standard, the EnOcean devices seem to be professionally designed for ordinary consumers. As my project shows the programming with EnOcean technology is also possible and not much less complex than other implementations.

Because safety considerations in the minds of people are growing more and more ZigBee will be compared to EnOcean more accepted because of its safety features. However, if EnOcean would implement security functions, which is very difficult, EnOcean would be preferable because of its energy harvesting technology. ZigBee is also trying to integrate energy harvesting into its system and is therefore in a legal battle with EnOcean. Although it seems that EnOcean will win the legal battle but the outcome is still uncertain.

Bibliography Anders, A., & Schmidt, F. (n.d.). enocean.com. Retrieved 12 01, 2010, from http://www.enocean.com/fileadmin/redaktion/pdf/articles/perpetuum_radio_standard s_en.pdf

Beckhoff. (2007, 10 22). KL6021-0023,KL6023. Retrieved 03 30, 2011, from http://infosys.beckhoff.com/content/1033/kl6021-0023/html/bt_kl6021- 0023_title.htm?id=3743

Beckhoff. (2008, 10 02). BK9050. Retrieved 04 10, 2011, from http://download.beckhoff.com/download/Document/BusTermi/BCoupler/BK9000en. chm

Beckhoff. (2010, 07 07). KL6581,KL6583. Retrieved 03 25, 2011, from • http://download.beckhoff.com/download/Document/BusTermi/BusTermi/KL6581_KL 6583en.chm

Beckhoff. (n.d.). KL6021. Retrieved 03 30, 2011, from http://www.beckhoff.de/english/bus_terminal/kl6021_kl6041.htm?id=115184931502 2

Beckhoff. (n.d.). TwinCat_PLC_1. Retrieved 06 01, 2011, from http://infosys.beckhoff.com/content/1031/tcplccontrol/html/tcplcctrl_intro.htm?id=12 214

Beckhoff. (n.d.). TwinCat_PLC_2. Retrieved 06 01, 2011, from http://www.beckhoff.com/german/twincat/twincat_plc.htm?id=159876035060

Beckhoff. (n.d.). TwinCat_SysMgm. Retrieved 06 01, 2011, from http://www.beckhoff.com/german/twincat/SysMang.htm?id=159876032042705

Beckhoff.at. (n.d.). Retrieved 05 25, 2011, from http://www.beckhoff.at/english/beckhoff/default.htm?id=10

Davis, D. (2009, 01 07). The Basics of Ethernet Cabling. Retrieved 04 12, 2011, from http://www.petri.co.il/csc_the_basics_of_ethernet_cabling.htm digi.com. (n.d.). Retrieved 12 03, 2010, from http://www.digi.com/products/wirelessdropinnetworking/idigi-kits/x4-zb.jsp#overview digistoreeurope.com. (n.d.). Retrieved 12 04, 2010, from http://www.digistoreeurope.com/?pn=XK-Z11-IX- WE&utm_source=google&utm_medium=organic&utm_campaign=(organic) engi.elect.equi.org. (n.d.). Retrieved 12 16, 2011, from http://engineering.electrical- equipment.org/electrical-distribution/smart-grid-and-its-security.html

EnOcean.com. (2007, 04). RCM. Retrieved 10 29, 2010, from http://www.enocean.com/uploads/tx_f03enocean/RCM_110_120_User_Manual_V1 .93_04.pdf

EnOcean.com. (2009, 09 16). EDK300 Press. Retrieved 12 06, 2010, from http://www.enocean.com/de/enocean_presse_edk300/

EnOcean.com. (2010). Retrieved 11 25, 2010, from http://www.enocean.com/de/home/

EnOcean.com. (2010, 11). EDK300. Retrieved 11 25, 2010, from http://www.enocean.com/en/enocean_modules/EDK_300_Data_Sheet_Nov2010.p df/

EnOcean.com. (n.d.). EEP2.1. Retrieved 04 25, 2011, from http://www.enocean- alliance.org/fileadmin/redaktion/enocean_alliance/pdf/EnOcean_Equipment_Profile s_EEP2.1.pdf

EnOcean-Alliance.org. (2010). Retrieved 11 30, 2010, from http://www.enocean- alliance.org/de/home/

Gessler, R., & Krause, T. (2009). Wireless-Netzwerke für den Nahbereich: Grundlagen, Verfahren, Vergleich, Entwicklung (1 ed.). Wiesbaden: Vieweg +Teubner.

IEEE-Std-802.15.4. (2006, 09 08). Retrieved 11 02, 2010, from http://standards.ieee.org/getieee802/download/802.15.4-2006.pdf itwissen.info - KNX. (n.d.). Retrieved 02 20, 2012, from http://www.itwissen.info/definition/lexikon/Konnex-Bus-KNX-konnex.html jacksonemc.com. (n.d.). Retrieved 12 13, 2011, from http://www.jacksonemc.com/Smart- Meter.smartmeter.0.html joybien.com. (n.d.). Retrieved 12 15, 2011, from http://www.joybien.com

Markt&Technik. (2009, 07 24). enocean.com. Retrieved 11 17, 2010, from http://www.enocean.com/de/newsitem/?tx_ttnews[tt_news]=520

Martin, G. (2007, 09 30). enocean.com. Retrieved 11 15, 2010, from http://www.enocean.com/fileadmin/redaktion/pdf/white_paper/wp_wireless_sensor_ solutions.pdf

Schäfer, C. (2010). Effiziente Architekturen und Technologien zur Realisierung von Smart Metering im Bereich der Nahkommunikation (1 ed.). Norderstedt: GRIN Verlag.

Thermokon1_pdf. (n.d.). PG1. Retrieved 04 25, 2011, from http://www.thermokon.de/files/produktblatt-easysens-funkschalter- mini1271331392.pdf

100

Thermokon1_web. (n.d.). PG1. Retrieved 04 25, 2011, from http://www.thermokon.de/EN/easysens-31/wireless-switch--mini.html

Thermokon2_pdf. (n.d.). SRG01. Retrieved 04 26, 2011, from http://www.thermokon.de/files/produktblatt-srg011300953049.pdf

Thermokon3_pdf. (n.d.). SRW01. Retrieved 05 20, 2011, from http://www.thermokon.de/files/produktblatt-srw011271768465.pdf

Thermokon3_web. (n.d.). SRW01. Retrieved 05 20, 2011, from http://www.thermokon.de/DE/easysens/srw01--fensterkontakt.html

Thermokon4_pdf. (n.d.). SR65. Retrieved 05 21, 2011, from http://www.thermokon.de/files/produktblatt-sr651300787280.pdf

Thermokon4_web. (n.d.). SR65. Retrieved 05 21, 2011, from http://www.thermokon.de/DE/easysens/sr65--aussentemperaturfueher.html

Thermokon5_pdf. (n.d.). SR04PST. Retrieved 05 21, 2011, from http://www.thermokon.de/files/produktblatt-sr041271767000.pdf

Thermokon5_web. (n.d.). SR04PST. Retrieved 05 21, 2011, from http://www.thermokon.de/DE/easysens/sr04--raumfuehler-und-raumbediengeraete- temperatur-.html

Thermokon6_pdf. (n.d.). SRCADO. Retrieved 01 6, 2012, from http://www.thermokon.de/files/produktblatt-src-ado1306843163.pdf

Westervelt, A. (2009, 08 28). gigaom.com. Retrieved 10 30, 2010, from http://gigaom.com/cleantech/energy-harvesting-smackdown-zigbee-vs-enocean/

Wiesemann&Theis. (n.d.). wut.de. Retrieved 11 16, 2010, from http://www.wut.de/e-59610- 11-apde-000.php wiki-EnOcean. (2010, 10 06). en.wikipedia - EnOcean. Retrieved 11 05, 2010, from http://en.wikipedia.org/wiki/EnOcean wiki-ZigBee. (2010, 10 26). de.wikipedia - ZigBee. Retrieved 11 23, 2010, from http://de.wikipedia.org/wiki/ZigBee

ZigBeeAlliance. (2009, 06 29). zigbee.org. Retrieved 11 02, 2010, from http://www.zigbee.org/imwp/download.asp?ContentID=16107

ZigBee-Specification. (2007, 10 19). Retrieved 12 09, 2010, from http://zigbee.org/Products/DownloadZigBeeTechnicalDocuments.aspx

101

List of Figures Figure 1 – a simplified Smart Grid (engi.elect.equi.org) ...... 6 Figure 2 – function of a Smart Meter (jacksonemc.com) ...... 7 Figure 3 – a simplified Smart Home (joybien.com) ...... 7 Figure 4 - Star and Peer-to-Peer topology (IEEE-Std-802.15.4, 2006) ...... 10 Figure 5 - cluster tree network (IEEE-Std-802.15.4, 2006) ...... 11 Figure 6 - LR-WPAN device architecture (IEEE-Std-802.15.4, 2006) ...... 12 Figure 7 - The PHY reference model (IEEE-Std-802.15.4, 2006) ...... 13 Figure 8 - The MAC sublayer reference model (IEEE-Std-802.15.4, 2006) ...... 14 Figure 9 - Superframe structure without GTS (Typ1) (IEEE-Std-802.15.4, 2006) ...... 15 Figure 10 - Superframe structure with GTS (Typ2) (IEEE-Std-802.15.4, 2006) ...... 15 Figure 11 - Superframe structure with GTS and inactive period (IEEE-Std-802.15.4, 2006) ...... 15 Figure 12 - Communication to a coordinator, beacon-enabled (IEEE-Std-802.15.4, 2006) 16 Figure 13 - Communication to a coordinator, nonbeacon-enabled (IEEE-Std-802.15.4, 2006) ...... 16 Figure 14 - Communication from a coordinator, beacon-enabled (IEEE-Std-802.15.4, 2006) ...... 17 Figure 15 - Communication from a coordinator, nonbeacon-enabled (IEEE-Std-802.15.4, 2006) ...... 17 Figure 16 - Schematic view of the MAC- and the PHY-packet of a Beaco-frame (IEEE-Std- 802.15.4, 2006) ...... 19 Figure 17 - Schematic view of the MAC- and the PHY-packet of a Data-frame (IEEE-Std- 802.15.4, 2006) ...... 19 Figure 18 - Schematic view of the MAC- and the PHY-packet of an Acknowledgment-frame (IEEE-Std-802.15.4, 2006) ...... 20 Figure 19 - Schematic view of the MAC- and the PHY-packet of a MAC-Command-frame (IEEE-Std-802.15.4, 2006) ...... 20 Figure 20 - ZigBee stack architecture (ZigBee-Specification, 2007) ...... 23 Figure 21 - NWK layer reference model (ZigBee-Specification, 2007) ...... 24 Figure 22 - General NWK frame format (ZigBee-Specification, 2007) ...... 25 Figure 23 - Frame control field of an NPDU (ZigBee-Specification, 2007) ...... 25 Figure 24 - APS Sub-Layer reference model (ZigBee-Specification, 2007) ...... 26 Figure 25 - General APDU frame format (ZigBee-Specification, 2007) ...... 27 Figure 26 - Format of the frame control field of an APDU (ZigBee-Specification, 2007) ....27 Figure 27 - link and network key scenarios...... 29 Figure 28 - ZigBee frame with security on the NWK level (ZigBee-Specification, 2007) ....30 Figure 29 - ZigBee frame with security on the APS level (ZigBee-Specification, 2007) .....30 Figure 30 - Energy Harvesting Wireless Sensor Solution from EnOcean (EnOcean.com, 2010) ...... 33 Figure 31 - Topology of an EnOcean network (EnOcean.com, 2010) ...... 38

102

Figure 32 - EnOcean's telegram format; 1.row: Byte number; 2.row: value (hexadecimal) (Gessler & Krause, 2009) ...... 40 Figure 33 - gives an example of a home automation scenario. (EnOcean.com, 2010) ...... 42 Figure 34 - gives an example of an industrial automation scenario (EnOcean.com, 2010) 43 Figure 35 - iDigi X4 Starter Kit ZB (digi.com) ...... 48 Figure 36 - EnOcean Developer-Kit EDK 300 (EnOcean.com, EDK300, 2010) ...... 49 Figure 37 - Basic Smart Home configuration ...... 50 Figure 38 - EnOcean integration – Case 1: read only ...... 51 Figure 39 - EnOcean integration – Case 2: read and write ...... 51 Figure 40 – Smart Home project from EnOcean side ...... 52 Figure 41 - How the wiring is done (Beckhoff, KL6581,KL6583, 2010) ...... 55 Figure 42 - Connection plan of KL6581 (Beckhoff, KL6581,KL6583, 2010) ...... 56 Figure 43 - Connection plan of KL6583 (Beckhoff, KL6581,KL6583, 2010) ...... 56 Figure 44 - Connections between KL6581 and KL6583 (Beckhoff, KL6581,KL6583, 2010) ...... 57 Figure 45 - Node address switch of KL6583 (Beckhoff, KL6581,KL6583, 2010) ...... 58 Figure 46 – configuration of the termination resistor (Beckhoff, KL6581,KL6583, 2010) ....58 Figure 47 - Voltage and terminal arrangement of the terminals KL6581 and KL2012 to the BK9050/ edited picture of ... (Beckhoff, BK9050, 2008) ...... 59 Figure 48 - BK9050 and its diagnostic LEDs (Beckhoff, BK9050, 2008) ...... 60 Figure 49 - LEDs of KL6581 (Beckhoff, KL6581,KL6583, 2010) ...... 61 Figure 50 - LEDs of KL6581 (Beckhoff, KL6581,KL6583, 2010) ...... 62 Figure 51 - Structure of the project (green colored programs are not in use) ...... 65 Figure 52 - P_EnOcean - Main FB ...... 66 Figure 53 - P_EnOcean - Search FB ...... 67 Figure 54 - P_EnOcean - Switch FB...... 68 Figure 55 - P_EnOcean - Window Handle FB ...... 69 Figure 56 - P_EnOcean - 1BS FB - Window Contact ...... 70 Figure 57 - P_EnOcean - Generic FB - IndoorTemp ...... 71 Figure 58 - P_EnOcean - Conversion Functions - IndoorTemp ...... 71 Figure 59 - P_EnOcean - Generic FB - OutdoorTemp ...... 73 Figure 60 - P_EnOcean - Conversion Functions – OutdoorTemp ...... 73 Figure 61 - P_EnOcean - Switch Send FB ...... 74 Figure 62 - P_EnOcean_DataMngt - Variables ...... 75 Figure 63 - P_EnOcean_DataMngt - Calling up the P_EnOcean program ...... 75 Figure 64 - P_EnOcean_DataMngt – Called up P_EnOcean program ...... 76 Figure 65 - P_EnOcean_DataMngt - Caution! function ...... 76 Figure 66 - P_EnOcean_DataMngt – Button creation for sending EnOcean switch data ...77 Figure 67 - FB_Room_Type_Number - Variables ...... 77 Figure 68 - FB_Room_Type_Number - Logic for 24V LED ...... 78 Figure 69 - FB_Room_Type_Number - Logic for dimable light ...... 79 Figure 70 - FB_Room_Type_Number - ordering in data flow...... 80

103

Figure 71 - Main - Variables ...... 80 Figure 72 - Main - Calling up the programs "P_EnOcean" and "P_EnOcean_DataMngt" ..81 Figure 73 - Main - Calling up the "P_EIB" program ...... 81 Figure 74 - Main - Calling up the programs "P_GetTime" and "P_IOs" ...... 81 Figure 75 - Main - Calling up a function block named "FB_Room_Labor_1" ...... 82 Figure 76 - Visualisation ...... 82 Figure 77 – PLC Control- Compile project ...... 83 Figure 78 - System Manager - Search for bus coupler and terminals ...... 83 Figure 79 - System Manager - IO device found ...... 84 Figure 80 - System Manager - Add PLC project ...... 84 Figure 81 - System Manager - Change Link – EnOcean inputs ...... 85 Figure 82 - System Manger - Choose hardware inputs...... 85 Figure 83 - System Manager – Change link – Red LED ...... 86 Figure 84 - System Manager - - Choose hardware outputs ...... 86 Figure 85 - System Manager - Generate Mappings ...... 87 Figure 86 - System Manager - Mapping generated ...... 87 Figure 87 - System Manager - Check configuration ...... 87 Figure 88 - System Manager - Activate configuration ...... 88 Figure 89 - System Manager - Restart in Running Mode ...... 88 Figure 90 - PLC Control - Login in ...... 88 Figure 91 - PLC Control - Start program ...... 89 Figure 92 - PLC Control Running - Search function block ...... 89 Figure 93 - PLC Control Running - Variable of all devices ...... 90 Figure 94 - SmartHome - EnOcean Visualisation ...... 91 Figure 95 - SRC-ADO-V3 software icon ...... 92 Figure 96 - SRC-ADO-V3 - start screen ...... 92 Figure 97 - SRC-ADO-V3 - Analogue output 1 configuration, “parameter” view ...... 93 Figure 98 - SRC-ADO-V3 - Choose sensor type ...... 94 Figure 99 - SRC-ADO-V3 - Learn-in sensor ID ...... 94 Figure 100 - SRC-ADO-V3 – sensor ID was found ...... 95 Figure 101 - SRC-ADO-V3 and virtual switch button1 ...... 95 Figure 102 - SRC-ADO-V3 and virtual switch button2 ...... 96 Figure 103 - SRC-ADO-V3 and virtual switch button3 ...... 96 Figure 104 - SRC-ADO-V3 and virtual switch button4 ...... 96 Figure 105 - Bus Coupler BK9050 ...... 110 Figure 106 - Principle of the Bus Terminal (Beckhoff, BK9050, 2008) ...... 111 Figure 107 - Ethernet connection / with and without HUB (Beckhoff, BK9050, 2008) ...... 111 Figure 108 - Ethernet cable types (Davis, 2009) ...... 111 Figure 109 - KL6581 (Beckhoff, KL6581,KL6583, 2010) ...... 112 Figure 110 - KL6583 (Beckhoff, KL6581,KL6583, 2010) ...... 113 Figure 111 - EasySense PG1 switch (Thermokon1_web) ...... 114 Figure 112 - SRG01 window handle (Thermokon2_pdf) ...... 115

104

Figure 113 – SRG01 Bits of the DataByte 3 (Thermokon2_pdf) ...... 116 Figure 114 - SRW01 Window Contact (Thermokon3_web) ...... 117 Figure 115 - SR65 Outdoor Temperatur Sensor (Thermokon4_web) ...... 118 Figure 116 - SR65 setting of transmission time (Thermokon4_pdf) ...... 119 Figure 117 - SR04PST Indoor temperature sensor (Thermokon5_pdf) ...... 119 Figure 118 - SR04PST setting of transmission time (Thermokon5_pdf) ...... 120 Figure 119 - SRC-ADO 4AA/4DA EnOcean Receiver/Actuator (Thermokon6_pdf) ...... 122

105

List of Tables Table 1 - Frequency bands and data rates (IEEE Std. 802.15.4, 2006) ...... 13 Table 2 - layer model of the EnOcean standard (Gessler & Krause, 2009)...... 39 Table 3 - telegram format description (EnOcean.com, RCM, 2007) ...... 40 Table 4 - Technical comparison of EnOcean and ZigBee (Martin, 2007) ...... 46 Table 5 - EnOcean relevant component list ...... 53 Table 6 - Wiring data (Beckhoff, KL6581,KL6583, 2010) ...... 55 Table 7 - Connections points of KL6581 and KL6583 (Beckhoff, KL6581,KL6583, 2010) ..57 Table 8 - LEDs for power supply diagnosis (Beckhoff, BK9050, 2008) ...... 60 Table 9 - LEDs for K-bus diagnostics (Beckhoff, BK9050, 2008) ...... 60 Table 10 - LEDs for Ethernet diagnostics (Beckhoff, BK9050, 2008) ...... 61 Table 11 - Meaning of the KL6581 LED displays (Beckhoff, KL6581,KL6583, 2010) ...... 61 Table 12 - Meaning of the KL6583 LED displays (Beckhoff, KL6581,KL6583, 2010) ...... 62 Table 13 - Attenuation of different materials (Beckhoff, KL6581,KL6583, 2010) ...... 63 Table 14 - Impact on the range (Beckhoff, KL6581,KL6583, 2010) ...... 63 Table 15 - Component list of the whole project ...... 109 Table 16 - KL6581 technical data (Beckhoff, KL6581,KL6583, 2010) ...... 112 Table 17 - KL6583 technical data (Beckhoff, KL6581,KL6583, 2010) ...... 113 Table 18 - Technical data of EasySense PG1 (Thermokon1_pdf) ...... 114 Table 19 - RPS telegram (EnOcean.com, EEP2.1) ...... 115 Table 20 – SRG01 technical data (Thermokon2_pdf) ...... 115 Table 21 – SRW01 technical data (Thermokon3_pdf) ...... 117 Table 22 - SRW01 - 1BS EnOcean telegram (Thermokon3_pdf) ...... 117 Table 23 - SR65 technical data (Thermokon4_pdf) ...... 118 Table 24 - SR65 EnOcean telegram (Thermokon4_pdf)...... 119 Table 25 - SR04PST technical data (Thermokon5_pdf) ...... 120 Table 26 - SR04PST EnOcean telegram (Thermokon5_pdf) ...... 121 Table 27 – SRC-ADO 4AA/4DA technical data (Thermokon6_pdf) ...... 122

106

List of abbreviations AC alternating current AES advanced encryption standard AIB APS information base APDU application protocol data unit APL application layer APS application support sub-layer APS application support sub-layer APSDE APS data entity APSME APS management entity ASK amplitude shift keying BPSK binary phase shift keying CAN controller area network CAP contention access period CCA clear channel assessment CCM counter with CBC-MAC CCM* extension of CCM CFP contention free period CRC cyclic redundancy check CSMA-CA carrier sense multiple access with collision avoidance DC direct current DECT digital enhanced cordless telecommunications ED energy detection EDK EnOcean Developer-Kit EEP EnOcean Equipment Profiles etc et cetera (and so on) FCS frame check sequence FFD full-function device GND ground GSM global system for mobile communications GTS guaranteed time slots HVAC heating, ventilation and cooling I/O Input/Output ID identifier IEC International Electrotechnical Commission IEEE Institute of Electrical and Electronics Engineers ISM Industrial, Scientific and Medical KNX Konnex Bus LLC logical link control LQI link quality indicator LR-WPAN low-rate Wireless Personal Area Network MAC medium access control sublayer MCPS-SAP MAC common part sublayer SAP MFR MAC footer MHR MAC header MLME MAC sublayer management entity MPDU MAC protocol data unit MSDU MAC service data unit

107

NIB network information base NLDE NWK layer data entity NLME NWK layer management entity NPDU NWK layer protocol data unit NWK network layer OEM original equipment manufacturer O-QPSK Offset Quadrature Phase Shift Keying P2P peer-to-peer PAN Personal Area Network PD-SAP PHY data SAP PHR PHY header PHY physical layer PLC programmable logic controller PLME physical layer management entity PMR private mobile radio POS personal operating space PPDU PHY protocol data unit PSDU PHY service data unit PSSS Parallel Sequence Spread Spectrum PTM pushbutton transmitter module RCM receiver modules RF radio frequency RFD reduced-function device SAP service access point SHR synchronization header SSCS service-specific convergence sublayer STM sensor transmitter module TCM transceiver module WLAN Wireless Local Area Network WPAN Wireless Personal Area Network WSN wireless sensor network ZDO ZigBee device objects ZDP ZigBee device profile

108

A: Table of Hardware Table 15 lists the whole hardware which was used in this SmartHome project. Components which are bold written are relevant for my work.

Table 15 - Component list of the whole project

Type Quantity Description Costs in € FC9002 1 Ethernet PCI network card 198,00 BK9050 1 Bus Coupler 168,00 KL9010 1 Bus End Terminal 9,46

KL2722 = 1 Output terminals; The switching element is a triac 29,40 KL2012 KL 2751 1 dimmer Bus Terminal 62,00 KL3064 1 Analog input terminal handles signals in the range from 0-10V 169,24 KL3204 1 4-channel analog input terminal for resistance sensors 185,09 KL3403 2 3-phase power measurement terminal 304,00 Serial-Bus Terminal for processing the RS485 signals from the KL6021- 1 KL6023 wireless adapter with EnOcean radio technology 196,85 0023 (unidirectional) KL 6023 1 Wireless Adapter receives EnOcean signals (unidirectional) 92,00 KL6301 1 KNX/EIB Bus Terminal 192,00 KL6581 1 EnOcean Master Terminal (bidirectional) 185,00 KL 6583 1 EnOcean transmitter and receiver (unidirectional) 155,00 KL 6811 1 DALI/DSI master and power supply terminal 206,00

1 Temperature resistance sensor ~10

1 24V lamp - green ~10

1 24V lamp - red) ~10

2 Power transformer: 230AC  24AC ~40

109

B: Description of hardware components relevant for EnOcean integration

1) Beckhoff BK9050 - Bus Coupler The BK9050 Bus Coupler connects a PC with the modular, extendable electronic terminal blocks by the use of Ethernet. The connection is done through RJ 45 connectors. The Bus Coupler supports 10 Mbit/s and 100 Mbit/s Ethernet. One Beckhoff-system consists of one Bus Coupler, any number from 1 to 64 terminals and one end terminal. With the K-bus extension an amount of up to 255 connected Bus Terminals is possible. (Beckhoff, BK9050, 2008)

Figure 105 - Bus Coupler BK9050

Bus Coupler supply The Bus Coupler requires a 24 V DC supply for operation. The connection is done to the connectors branded as “24V” and “0V” as seen in the picture above. The supply voltage feeds the Bus Coupler electronics. It also feeds the Bus Terminals over the K-Bus. (Beckhoff, BK9050, 2008)

Input for Power Contacts The six connectors on the bottom may be used to feed the supply for the peripherals. A voltage of up to 24 V is permitted while the current must not exceed 10 A. (Beckhoff, BK9050, 2008)

110

Figure 106 - Principle of the Bus Terminal (Beckhoff, BK9050, 2008)

Ethernet Connection The connection between a PC and the Bus Coupler made via an RJ45 connector. The connection via hub or switch is done by a standard Ethernet cable (a straight through cable) while a direct connection between a PC’s Ethernet card and the BK9050 is done by an Ethernet cable in which the pairs of cores have been crossed (a crossover cable). (Beckhoff, BK9050, 2008)

Figure 107 - Ethernet connection / with and without HUB (Beckhoff, Figure 108 - Ethernet BK9050, 2008) cable types (Davis, 2009)

111

2) Beckhoff KL6581 - EnOcean-Masterterminal The KL6581 Enocean Master Terminal connects KL6583 EnOcean transceiver modules with the application (software). One KL6581 terminal is able to communicate with up to eight KL6583 transceiver modules. The KL6583 modules are connected to the KL6581 via two wires for the power supply and two wires for the data bus by which the KL6581 transmits as well as receives the EnOcean telegrams. The maximum length of the data bus between KL6581 and KL6583 is 500 m. (Beckhoff, KL6581,KL6583, 2010)

Figure 109 - KL6581 (Beckhoff, KL6581,KL6583, 2010)

Table 16 - KL6581 technical data (Beckhoff, KL6581,KL6583, 2010)

Number of outputs 1 Number of connectable KL6583s 8 Transmission standard CAN (Standard: ISO 11898) CAN connection cable maximum 500 m (line topology only) Data transfer rate 125 kbyte

Electrical isolation 500 Veff (K-bus/CAN) 24 V DC (-15 %/+20 %) via the K-bus and Power supply for the electronics through the power contacts Current consumption from K-bus typically 60 mA Bit width in process image Output: 12 bytes data, input: 12 bytes data Mounting on 35 mm mounting rail according to EN 50022 Permissible ambient temperature at 0°C... + 55°C operation

112

3) Beckhoff KL6583 - EnOcean-Receiver and Transmitter The KL6583 is a bidirectional EnOcean device which allows the transmitting as well as receiving of EnOcean signals. It receives signals from batteryless sensors and/or switches and transmits data to actuators by using an integrated antenna. The KL6583 module is power supplied by a connection to the KL6581 master terminal with 24 V. The data transmission between the KL6583 and KL6581 is performed through a 2 wire bus connection. Received EnOcean signals are forwarded to the KL6581 which makes it available to the application. The maximum length of the data bus between KL6581 and KL6583 is 500 meters. (Beckhoff, KL6581,KL6583, 2010)

Figure 110 - KL6583 (Beckhoff, KL6581,KL6583, 2010)

Table 17 - KL6583 technical data (Beckhoff, KL6581,KL6583, 2010)

Connection 2 x 2-Leiter directly to bus terminal KL6581 Transmission standard CAN (Standard: ISO 11898) Data transfer rate 125 kByte Power supply for electronic via KL6581 (24 VDC) Current consumption typical 20 mA (24 VDC) Wave band 868.35 MHz 300 m at free field, Transmission range 30 m in buildings depends on sensor type (32 Bit sensor id Radio telegram number, number of useful bytes not limited), send and receive Antenna integrated al housing Permissible ambient temperature at 0°C ... + 55°C operation

113

4) EasySense PG1 (switch) The switch produces a wireless signal when pressing and releasing a button. The power generation is done by a maintenance-free electrodynamic energy generator. The switch is a 4-channel light- or jalousie-switch. (Thermokon1_web)

Figure 111 - EasySense PG1 switch (Thermokon1_web)

Table 18 - Technical data of EasySense PG1 (Thermokon1_pdf)

Integrated radio transmitter EnOcean PTM 200 Energy harvesting source electrodynamic energy generator, maintenance-free Radio technology EnOcean 868 MHz Transmission range RPS Type 2 / 300 m free field, typ. 30 m within buildings Rocker variation 4 channels (= 2 rockers) Humidity 0-95% r.h., non-condensing (for dry environment only) Temperature range (operation) -25...+65°C

The EnOcean PTM200 device has its own telegram type which is called RPS telegram. RPS stands for Repeated Switch Communication and is only used by switches. The table below shows the Bits which are typical for RPS telegrams. In the table headers and footers are missing. The table gives only an overview of the 4 channel version.

114

Table 19 - RPS telegram (EnOcean.com, EEP2.1)

ORG / RORG 0x05 / 0xF6 Telegram type: RPS (Telegram type) 0b000 (Button AI: "Switch light on") Bit 7… Bit 5 0b001 (Button A0: "Switch light off") (Rocker 1st 0b010 (Button BI: “Switch light on”) action) 0b011 (Button B0: “Switch light off”) Bit 4 0b0 (Button released) DB_3 (Energy Bow) 0b1 (Button pressed) (Data Byte 3) 0b000 (Button AI: "Switch light on") Bit 3… Bit 1 0b001 (Button A0: "Switch light off") (Rocker 2nd 0b010 (Button BI: “Switch light on”) action) 0b011 (Button B0: “Switch light off”) Bit 0 0b0 (No 2nd action) (2nd Action) 0b1 (2nd action valid) Bit 5 0b1 (Switch with 2 rockers) (T21) STATUS (U-message: 3 or more buttons Bit 4 0b0 are pressed simultaneously) (NU) 0b1 (N-message)

5) EasySense SRG01 (switch) When operated, the SRG01 window handle sends its current position which means it tells the receiver the opening status of the corresponding window. By turning the window handle energy is generated which is used for processing and sending the data. (Thermokon2_pdf)

Programming Before mounting the device to the window it should be programmed. Therefore, put the receiver into the learn mode. Afterwards, turn the window handle from the closed position to the opened position and back again. (Thermokon1_web)

Table 20 – SRG01 technical data (Thermokon2_pdf) Antenna Internal sending antenna Frequency 868,3 MHz Transmitter power max. 10mW EIRP Ambiet temperature -20...60°C

Figure 112 - SRG01 window handle (Thermokon2_pdf)

115

SRG01 telegram As the switch PG1 also the SRG01 uses RPS telegram. It only uses the third data byte for sending data. Figure 113 – SRG01 Bits of the DataByte 3Figure 113 illustrates the possible positions of the window handle and their binary notations. Bits marked with “X” should not be checked. They can be “1” or “0” and are not important for evaluation. (Thermokon2_pdf)

Figure 113 – SRG01 Bits of the DataByte 3 (Thermokon2_pdf)

116

6) EasySense SRW01 – Window Contact (sensor) The SRW01 is a batteryless radio window contact which transmits the position of windows and doors whether it is open or closed. Energy is generated by an integrated solar cell. (Thermokon3_pdf)

Figure 114 - SRW01 Window Contact

(Thermokon3_web)

Table 21 – SRW01 technical data (Thermokon3_pdf)

Technology EnOcean, STM250 Transmitting range approx. 30m in buildings, approx. 300m upon free propagation Measuring value detection change of internal reed contact Sending interval If contact changes or every 5...30 minutes (typ. 15 minutes) periodic Energy generator Solar cell, internal goldcap, maintenance-free Ambient temperature -25…+65°C

Table 22 - SRW01 - 1BS EnOcean telegram (Thermokon3_pdf)

ORG 6 dec. always (EnOcean module type “1BS”) Bit D3 Learn Button (0=Button pressed) Data_byte3 Bit D0 State reed contact (0= contact open, 1= contact close) ID_Byte3 device identifier (Byte3) ID_Byte2 device identifier (Byte2) ID_Byte1 device identifier (Byte1) ID_Byte0 device identifier (Byte0)

117

7) EasySense SR65 – Outdoor Temperature Sensor (sensor) The SR65 is an outdoor temperature sensor which works batteryless and transmits wireless by using EnOcean wireless technology. Energy is generated by an integrated solar cell. (Thermokon4_pdf)

Figure 115 - SR65 Outdoor Temperatur Sensor (Thermokon4_web)

Table 23 - SR65 technical data (Thermokon4_pdf)

Technology EnOcean, STM Transmitting range approx. 30m in buildings approx. 300m upon free propagation Temperature detection -20°C…+60°C Measuring value detection every 100 seconds Sending interval …every 100 seconds with changes >1,6°C …every 1000 seconds with changes <1,6°C Energy generator Solar cell, internal goldcap, maintenance-free Ambient temperature -25…+65°C

Frequency of transmission 1. event controlled by pressing the learn button 2. time controlled Every time the timer “T_wake up” starts again the measuring value for temperature is detected. If the temperature change is more than 2% (> 1,6°C) a telegram is sent immediately. If there is no change in temperature (< 1,6°C) a telegram is sent after expiration of the fixed sending time “T_send”. (Thermokon4_pdf)

118

T_send = T_wake up * T_intervall  (Range 1s – 10000s)

Figure 116 - SR65 setting of transmission time (Thermokon4_pdf)

Table 24 - SR65 EnOcean telegram (Thermokon4_pdf)

ORG 7 dec. Always (EnOcean module type “4BS”) Data_byte1 Temperature -20...60°C, linear n=255...0 Data_byte0 Bit D3 Learn Button (0=Button pressed) ID_Byte3 device identifier (Byte3) ID_Byte2 device identifier (Byte2) ID_Byte1 device identifier (Byte1) ID_Byte0 device identifier (Byte0)

8) EasySense SR04PST - Indoor temperature sensor (sensor)

The SR04PST is a room sensor for temperature and ventilation control which works batteryless and transmits wireless by using EnOcean wireless technology. Energy is generated by an integrated solar cell. The device consists of a temperature sensor, a rotary knob for set point adjustment, a rotary knob for fan speed adjustment, and a presence key. (Thermokon5_pdf)

Figure 117 - SR04PST Indoor temperature sensor (Thermokon5_pdf)

119

Table 25 - SR04PST technical data (Thermokon5_pdf)

Technology EnOcean, STM Transmitting range approx. 30m in buildings approx. 300m upon free propagation Temperature sensor Range: 0°C…+40°C Measuring value detection every 100 seconds Sending interval …every 100 seconds if changes >0,8°C, or >5° angle of rotation, or switch step rotary switch …every 1000 seconds if changes <0,8K, or <5° angle of rotation Energy generator Solar cell, internal goldcap, maintenance-free Ambient temperature -25…+65°C Set point adjustment P Range: 0…270° angle of rotation Resolution: 1,1° Rotary switch S Number of switching steps: 5 (A, 0, I, II, III) Button T Normal open

Frequency of transmission 1. event controlled by pressing the learn button 2. time controlled Every time the timer “T_wake up” starts again the measuring value for temperature is detected. If the temperature change is more than 2% (> 0,8°C) a telegram is sent immediately. If there is no change in temperature (< 0,8°C) a telegram is sent after expiration of the fixed sending time “T_send”. (Thermokon5_pdf)

T_send = T_wake up * T_intervall  (Range 1s – 10000s)

Figure 118 - SR04PST setting of transmission time (Thermokon5_pdf)

120

Table 26 - SR04PST EnOcean telegram (Thermokon5_pdf)

ORG 7 dec.Always (EnOcean module type “4BS”) Fan speed stage: Stage Auto = n>210 Stage 0 = 190

121

9) EasySense SRC-ADO 4AA/4DA Typ1 (actuator) The SRC-ADO 4AA/4DA receives and processes EnOcean telegrams. The measured values of the sensors may be assigned to up to 4 analogue (0-10V) and / or up to 4 digital outputs. The included software allows the configuration of the outputs, the learning and saving of the sensors and diagnostic capabilities. (Thermokon6_pdf)

Figure 119 - SRC-ADO 4AA/4DA EnOcean Receiver/Actuator (Thermokon6_pdf)

Table 27 – SRC-ADO 4AA/4DA technical data (Thermokon6_pdf)

Power supply: 230VAC (+- 10%) 50/60Hz Power consumption: max. 5VA Outputs: 4 analog outputs 0-10V (load max. 10mA) 4 relay outputs:  AC: max. 5A @ 230V AC (resistive load)  DC: max. 5A @ 24V DC (resistive load) Antenna: External receiving antenna with magnetic holding Ambient temperature: 0...60°C

122

C: Background technologies

AES Advanced Encryption Standard (AES) is a symmetric encryption standard which uses the key lengths 128, 192 and 256 Bit. For more details see the following links:  http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf  http://www.itwissen.info/definition/lexikon/advanced-encryption-standard-AES-AES- Verschluesselung.html

ASK The amplitude shift keying (ASK) method is a modulation method where the carrier amplitude is changing. For more details see the following links:  http://standards.ieee.org/getieee802/download/802.15.4-2006.pdf  http://www.itwissen.info/definition/lexikon/amplitude-shift-keying-ASK- Amplitudenumtastung.html

Asymmetrical encryption In the case of asymmetric encryption one key is used for encrypt and another key for decryption. For more details see the following link:  http://www.itwissen.info/definition/lexikon/Asymmetrische-Verschluesselung-asymmetrical- encryption.html

BPSK The binary phase shift keying (BPSK) method is a modulation method where the carrier frequency can have the two phase positions 0° and 180°. For more details see the following links:  http://standards.ieee.org/getieee802/download/802.15.4-2006.pdf  http://www.itwissen.info/definition/lexikon/Zweiphasenumtastung-BPSK-binary-phase-shift- keying.html

CCM* CCM* is an extension of Counter with CBC-MAC (CCM). It is an authenticated encryption method which works together with AES. For more details see the following links:  http://tools.ietf.org/html/rfc3610  http://www.itwissen.info/definition/lexikon/advanced-encryption-standard-counter-mode-and- CBC-MAC-AES-CCM.html

CRC Cyclic redundancy checksum (CRC) is an error detection method. For more details see the following links:  http://www.xilinx.com/support/documentation/application_notes/xapp209.pdf  http://www.itwissen.info/definition/lexikon/Zyklische-Blockpruefung-CRC-cyclic-redundancy- checksum.html

123

CSMA/CA The carrier-sense multiple-access-with-collision-avoidance (CSMA /CA) method allows multiple accesses (multiple devices) on a network and avoids collisions. The avoidance of collisions is done by using a priority scheme in which the privilege is signalled by the stations. For more details see the following links:  http://standards.ieee.org/getieee802/download/802.11-2007.pdf  http://www.itwissen.info/definition/lexikon/carrier-sense-multiple-access-with-collision- avoidance-CSMA-CA-CSMA-CA-Zugangsverfahren.html

DECT DECT (Digital Enhanced Cordless Telecommunications) is a European standard for cordless telephony. For more details see the following links:  http://pda.etsi.org/pda/queryform.asp --> DECT  http://www.itwissen.info/definition/lexikon/digital-enhanced-cordless-telecommunications- DECT.html

Duty cycle Duty cycle describes the temporal relationship between the pulse duration to pulse period. In relation to ZigBee: how long is radio transmission turned on or off in one period. For more details see the following link:  http://www.itwissen.info/definition/lexikon/Tastverhaeltnis-duty-cycle.html

EIRP The Equivalent Isotropically Radiated Power (EIRP) is a quality criterion of the radiation performance of antennas. The transmit power is stated in watts. For more details see the following links:  http://standards.ieee.org/findstds/interps/802.11-1999.html  http://www.itwissen.info/definition/lexikon/equivalent-isotropically-radiated-power-EIRP.html

GSM Global system for mobile communications (GSM) is a standard for all-digital mobile networks. For more details see the following links:  http://www.gsmworld.com/technology/index.htm  http://www.itwissen.info/definition/lexikon/Groupe-Speciale-Mobile-global-system-mobile- GSM-GSM-Standard.html

ISM Band The ISM-band (Industrial, Scientific and Medical) specifies frequency ranges that can be used by high-frequency devices. For more details see the following links:  http://www.itu.int/ITU-R/terrestrial/faq/index.html#g013  http://www.itwissen.info/definition/lexikon/ISM-Band-ISM-industrial-scientific-and- medical.html

124

O-QPSK Offset Quadrature Phase Shift Keying (OQPSK) is a modulation method where four different level values are assigned to four phasings. For more details see the following links:  http://standards.ieee.org/getieee802/download/802.15.4-2006.pdf  http://www.itwissen.info/definition/lexikon/offset-quadrature-phase-shift-keying-OQPSK.html

Orthogonal Orthogonally means square or rectangular. In radio engineering multiplexing is according to its orthogonality divided into time-division multiplexing, frequency division multiplexing and code division multiplexing. For more details see the following links:  http://standards.ieee.org/getieee802/download/802.15.4-2006.pdf  http://www.itwissen.info/definition/lexikon/Orthogonal-orthogonal.html

PMR For the private mobile radio (PMR) a frequency range at 446 MHz has been released. For more details see the following links:  http://www.bundesnetzagentur.de/cln_1912/EN/Areas/Telecommunications/TelecomsRegul ation/FrequencyManagement/FrequencyAssignment/PrivateMobileRadioPMR/PrivateMobil eRadioPMR_Basepage.html  http://www.itwissen.info/definition/lexikon/private-mobile-radio-PMR.html

PSSS Parallel Sequence Spread Spectrum (PSSS) is a radio-technical process based on the direct sequence spread spectrum technology. PSSS overlays several cyclically shifted spreading sequences. For more details see the following links:  http://standards.ieee.org/getieee802/download/802.15.4-2006.pdf  http://www.itwissen.info/definition/lexikon/parallel-sequence-spread-spectrum-PSSS.html

Symmetrical encryption In the case of symmetric encryption the same key is used for encrypt and decryption. For more details see the following link:  http://www.itwissen.info/definition/lexikon/Symmetrische-Verschluesselung-symmetrical- encryption.html

WLAN Wireless LANs (WLAN) are local area networks (LAN) where data is transmitted wirelessly. For more details see the following links:  http://standards.ieee.org/about/get/802/802.11.html  http://www.itwissen.info/definition/lexikon/wireless-LAN-WLAN-Funk-LAN.html

125