<< Click to Display Table of Contents >>

Motivation

A connectivity of the EnOcean standard to the TCP/IP world is one of the foundations for a successful integration of EnOcean in the emerging Internet of Things. One of the challenges in designing an IP Interface is to resolve the complexity of the EnOcean Equipment Profiles (EEP) in each case so that the presentation on the IP-side is simple and yet consistent in itself. In order to achieve this, it is important to process the content specified in the EnOcean profiles so that little to no knowledge of the EnOcean protocol is needed on the IP side to operate the respective devices.

For the representation of the "things" in the "Internet of Things" (IoT) the Representational State Transfer method (REST and RESTful) has proven to be useful over many similar implementations across and even within the large IoT alliances. That is why we propose such a RESTful API in JSON notation to represent the EnOcean functions over IP.

 

General Guidelines

For a meaningful representation of the EnOcean components and functionalities in the IP world, certain requirements must be met. These requirements come out out of limitations of the EnOcean specification, where compromises within the protocol have to be made due to energy harvesting, but also from the requirements of control systems, which are connected to a variety of systems over IP. The most important requirements are listed briefly:

 

Consistent API

The IP - representation of EnOcean devices across all telegrams and functions must be consistent. This means that the syntax of all existing EEP (2.6.3. , as of September 2015) is displayed in the same way by the API. It should be noted in particular that the attributes, functions and values ​​of the two channels of communication "from" and "to" should be identical. (eg " SetPoint " is always " SetPoint " and not "set point " , " Temp SetPoint " , " SET_POINT " , etc. ) .

This consistency should also be applied to the transmitted units, which should always be of the same type. I.E. power should always be given out in Watt, never in mW., MW, KW, etc ...

 

Persistent representation of the states of all EnOcean devices

The design of the EnOcean protocol doesn´t necessarily forsee to ask devices for their current state, as opposed to other bus systems such as KNX. Therefore, an IP representation should keep the state of all devices and deliver it on request. Especially as complex EnOcean profiles hold many different states, individual state storage is an important task.

 

Atomic addressing of device functions

The current EnOcean specification requires the transmission of full telegrams between EnOcean participants. With the transition to IP, it should be possible for the IP side to be able to address individual values and functions of a device directly. Thus, assembling and validating of full EnOcean EEPs is a task of the IP Interface For example a change in a ramp time of an actuator must not force the IP participant to create the entire EnOcean telegram of the actuator.

 

 

Dependency resolution in the EEP

Complex EnOcean Equipment Profiles often have dependencies in themself, which must be resolved during the transition to the IP world. Related profile functions which are spread over several databytes and/or telegrams have to be aggregated and delivered on one central position. Databytes with ambiguous meaning for the IP client have to be separated in individual functions. (For example, "If position A = 0, then unit watts; if Position A = 1 , then Unit = liters / hour) .

 

Programmable API

The IP Interface should be able to deliver the syntax of the communication of all EnOcean devices (all EEP) on request to the IP participant. Thus, it meets the requirement of a "friendly" presentation of the possibilities of EnOcean devices and facilitates its implementation.