Generic Language for EnOcean Networks With Generic Profiles, the EnOcean Alliance has further developed the standardized interoperable communication of energy harvesting wireless solutions. It allows multi-functional products that flexibly adapt to a variety of applications.

Marian Hönsch, Generic Profiles Team Leader, Technical Working Group, EnOcean Alliance

A core task of the EnOcean Alliance is to ensure the interoperability of EnOcean-based devices. For this, the Alliance’s Technical Working Group (TWG) has defined and maintains application profiles (EnOcean Equipment Profiles, EEP) that enable a device from vendor A to communicate with a sensor from vendor B and to connect to a gateway from vendor C. This seamless data exchange gives the users the freedom of choice to create an individual automation system according to specific requirements – independently from the manufacturer.

Increasing application variants

The variety of energy harvesting wireless products and applications has continuously increased. That’s why the TWG was looking for an addition to EEPs which is particularly suitable for new product designs that are intended to describe the energy harvesting wireless data encoding independently of the application.  This addition is called “Generic Profiles”. It is the first generic language for the communication of energy harvesting wireless solutions. Both, EnOcean Equipment Profiles and Generic Profiles, describe the data communication of products utilizing the EnOcean radio protocol to enable manufacturers to develop interoperable products. The key strength of Generic Profiles is to allow devices to have self-described dynamic communication.

Generic Profiles define the grammatical rules for all options of data encoding for ultra-low power and energy harvesting radio communication. Due to this generic language, the same product can be mapped dynamically to different applications. As a result, Generic Profiles offer a standardized path for future applications.

Layer approach

Similar to the OSI model (Open Systems Interconnection), Generic Profiles communication define part of the application and presentation layers. Excluding the session and transport layer, serial or any other communication type (e.g. TCP/IP) can exchange the Generic Profiles messages independently from the radio and its frequencies. Computer network protocols are using abstraction layers for hiding implementation details for a particular set of functionality. To confine this, abstraction layers for Generic Profiles communication are applied as well.

Covering all parameters

The data sent over the air is generally the result of an analogue-to-digital conversion, the state of a counter in the transmitting device or similar information. To conserve energy, these raw measurements are transmitted directly, using only as many bits as the native conversion produces. To determine the actual value, it is necessary to have a set of parameters to transform the pure digital values into physical units. Declaring this set of parameters will enable the receiver to recalculate the originally measured value as a preparation for further processing.

Generic Profiles include a language definition with a parameter selection that covers every possible measured value to be transmitted. Therefore, the approach does not only define parameters for the value recalculation algorithm but also includes specific signal definition (e.g. physical units).

Self-description of communication

For every measurement, the set of parameters has to be transmitted before the first operational data exchange. This is done during the teach-in process. Here, devices exchange for one-time information about how to interpret data which will be exchanged in the data communication. Using this process, the device describes its future communication itself.

Therefore, a generic teach-in procedure allows a device to connect to different radio partners. The teach-in process has a bidirectional character and consists of two consecutive messages: After the receiver has been switched into the learn mode, the transmitter broadcasts a teach-in request message. If the receiver has bidirectional communication capabilities, then it can send a teach-in response addressed to the transmitter as confirmation. This is required to enable commissioning devices to see and document the teach-in result.

Automated processing of digital data is only possible if all information about the acquisition type of the received data is available. Through this classification, a value can be combined with its physical unit. Therefore, three different main parameters (channel type, signal type, value type) have to be communicated. The interpretation of received data messages is based on two conditions: First, the message has to be accepted. That means that it has to carry a valid EnOcean ID that is known by the receiver or it can address the receivers EnOcean ID. Secondly, the receiver has to be aware of the user data structure. As this structure is almost infinitely variable due to the generic approach, the transmitter has to transmit its channel characteristics before the data communication in the teach-in process. Following the guidelines of the defined communication layers and Generic Profiles, every generic EnOcean device can exchange data with compatible devices.

Freedom of choice

[an error occurred while processing this directive] OEMs still have the freedom of choice to integrate specific EEPs, Generic Profiles or both. Networks can combine EEP-based devices with products using Generic Profiles. In this case, only the receiving side, e.g. a controller solution, needs to cover both data interfaces. Wired systems that process batteryless radio don’t need any change as the data interface remains transparent. This brings unique flexibility to new batteryless product developments and ensures the future-proof characteristics of existing ones.

In the future, new product developments can use the generic system specification for seamless interoperable communication. This applies above all to dynamic solutions, such as temperature sensors which can be used in warm or cold environments. Here, the sensors need the flexibility to cover different ranges of temperature.

Using Generic Profiles, multi-purpose sensors, which measure temperature, humidity and presence, can now send their future data communication format in the teach-in telegram to the receiving system. There, the data is connected on the application level. The application automatically adjusts to this generic definition and sends back the information to the sensors, which values it accepts or can process. If devices work bidirectionally, they can negotiate the accepted channels in a dialogue.

Generic Profiles is the first generic language for the communication of energy harvesting wireless solutions. They take the interoperability of EnOcean-based devices to the next level and ensure that future solutions of different vendors can communicate with each other – even with increasing application and function varieties.

Future-proof interoperability

Generic Profiles are a new communication convention that adds to the interoperability principle of the EEPs. This generic language definition is particularly suitable for new product designs, which are intended to be mapped dynamically to different applications. In this case, OEMs can insert the generic language definition instead of several profiles for the various use cases. Finally, Generic Profiles allow easier and faster product development but meet stronger certification requirements. They mark a significant leap in ensuring the interoperability of future energy harvesting wireless solutions – even when the variations of application increase.

Editor's note: This article respresents a major evolution in control languages. For insight and perspective you may wish to reread the following summary of the evolution of control languages.

“The Past and Future of Control Languages”  A call to the industry to speed their evolution to open protocol for control languages.

Why do we need change?

The problem as I see it is that all large building automation vendors only allow changes to their internal control languages using their proprietary software.  Just because they all use BACnet or Lon or EnOcean has no effect on the access to the control language which controls the relationship of how the open standards interact.

This creates a problem when global strategies are implemented such as DR (Demand Response). These global implementations not only involve all of the vendors' proprietary control languages but all of their installing partners who have written the strategies.

This article sets the mold for other protocols to get on with development of their Generic Network Control Languages and the ability to do protocol conversion on the fly. Great work EnOcean.

About the Author

Marian Hönsch is Product Manager and Software Architect at EnOcean. In this position, he is responsible for EnOcean software products and security concepts. In the EnOcean Alliance, he actively contributes to the Technical Working Group, where he led the Generic Profiles team. In addition, he is member of the Alliance’s EEP Approval Committee. Marian holds a bachelor in Informatics and a Master of Science magna cum laude in Software Engineering.

[an error occurred while processing this directive]
[Click Banner To Learn More]

[Home Page]  [The Automator]  [About]  [Subscribe ]  [Contact Us]