1. Overview

EnOcean EnOcean is a patented energy harvesting wireless technology for use in building automation, smart home and Internet of Things.

This guide includes:

  1. A description of the terms and abbreviations used in the guide.
  2. Information on EnOcean.
  3. A description of the EnOcean Radio Protocol and the use of repeaters.
  4. Information on EnOcean Equipment Profiles
  5. A description of the Edge One™ EnOcean module, and
  6. The Edge One™ EnOcean Module Data Structure.

To learn how to configure the Edge One™ EnOcean module, please refer to the EnOcean Getting Started Guide.

Terms and Abbreviations

TERM DECRIPTION
1BS Enocean 1 Byte Communication
4BS EnOcean 4 Byte Communication
ASK Amplitude-shift keying (ASK) is a form of modulation that represents digital data as variations in the amplitude of a carrier wave.
BAS Building Automation System
Bit A bit (a contraction of binary digit) is the basic capacity of information in computing and telecommunications. A bi represents either 1 or 0 (one or zero) only.
BT or BT Product BT is a product, where B is the 3dB bandwidth of the filter and T is the symbol duration.
Byte In this document, a byte is equal to an octet. An octet is a unit of digital information in computing and telecommunications that consists of eight bits.
Carrier Leakage Emission The emission of a carrier if no signal is intended to emit. E.g., the synthesizer is running but the driver and power amplifiers are switched off.
Choice Unique identification of EnOcean radio telegram types (RPS, 1BS, 4BS,…); equivalent to RORG
Client Bidirectional Smart Ack Device
Data Payload of ERP telegrams or ESP packets
Data_DL Consists of the data that shall be transmitted via the Data Link Layer.
Data_PL Consists of the data that shall be transmitted via the Physical Layer.
Data Rate This term describes the number of bits transmitted during one second.
Endianness Defines whether the MSB (Most significant bit or Big endianness), or the LSB (least significant bit, Little endianness) is transmitted first.
EEP EnOcean equipment profiles
ERP EnOcean radio Protocol.
ESP EnOcean Serial Protocol
FSK Frequency-shift keying (FSK) is a frequency modulation scheme in which digital information is transmitted through discrete frequency changes of a carrier wave.
LSB Abbreviation for “Least Significant Bit”
MSB Abbreviation for “Most Significant Bit”
MSC Manufacturer Specific Communication
ORG Organisational number for EnOcean radio telegram types (out-dated for EEP 2.1; used for ESP2 interface).
OSI Model The Open Systems Interconnection (OSI) model is a product of the Open Systems Interconnection effort at the International Organization for Standardization. It is a prescription of characterizing and standardizing the functions of a communications system in terms of abstraction layers. Similar communication functions are grouped into logical layers. A layer serves the layer above it and is served by the layer below it.
RORG Radio ORG = organization number for EnOcean radio telegram types (new with EEP 2.1); equivalent to ‘Choice’.
RMCC Remote Management Control Commands
RPC Remote Procedure Call
RPS EnOcean telegram type for Repeated Switch Communication
Smart Ack Smart Acknowledge EnOcean standard for energy-optimized bidirectional transmission
UART Universal Asynchronous Receiver Transmitter
VLD EnOcean Variable Length Data telegram
XML Extensible Markup Language. Designed to transport and store data
XSL Extensible Stylesheet Language. XML based language to visualize XML (data)

Back to Top

About EnOcean

EnOcean is a well-established wireless standard (ISO/ IEC 14543-3-1X) optimized for use in buildings, since an indoor radio range of 30m is possible. Interoperable products from various manufacturers are available at 868 MHz for Europe and China, 902 MHz for North America and 928 MHz for Japan.

EnOcean was invented by EnOcean, the company which offers its technical platform to manufacturers (OEMs) to enable them developing their system ideas for buildings, industry and the Internet of Things. EnOcean is a Promoter member of the EnOcean Alliance, which is an international consortium of nearly 400 companies worldwide, which develop and promote solutions based on the EnOcean energy harvesting wireless standard in the sub 1 GHz band.

EnOcean’s combination of miniaturized energy harvesting devices with ultra-low power radio technology is the basis for innovative maintenance-free wireless sensor solutions. The self-powered wireless switches and sensors do not require any wires or batteries and add significant flexibility to time savings and energy efficiency, while minimizing investment and operating costs.

EnOcean Alliance solutions make use of energy generated from slight changes in motion, light or temperature. Powered by motion, light or heat; no cables or batteries are required for switching or for collecting sensor information such as temperature, water sensing or presence detection.

Back to Top

The EnOcean Radio Protocol

The EnOcean Radio Protocol (ERP) is specifically designed to support ultra-low power devices and energy harvesting applications in building and home automation. For optimal RF effectiveness, the radio protocol uses sub 1 GHz frequency bands. RF reliability is assured because wireless signals are less than one millisecond in duration and are transmitted at a data rate of 125 kilobits per second. Although transmitted power is up to 10 mW, the wireless transmission used by EnOcean only has an energy requirement of 50 µWs for a single telegram. That is about the same as the power needed to lift a weight of 1 gram by 5 millimeters. The short telegram is randomly repeated twice in the space of about 40 milliseconds to prevent transmission errors.

The ERP specification defines the structure of the entire radio telegram. The user data embedded in this structure is defined by the EnOcean Equipment Profile (EEP).

EnOcean published version 2 of the protocol (ERP2) in 2017 to improve performance and to enable implementation on a wide variety of RF transceiver architectures.

The following key changes versus the EnOcean Radio Protocol 1 (ERP1) were introduced to achieve this goal:

  • Use of Frequency Shift Keying (FSK) modulation versus Amplitude Shift Keying (ASK) in ERP1.
  • Use of a longer Preamble and a longer Sync Word (formerly known as Start of Frame SOF) to increase detection reliability.
  • Change in the telegram structure where the End of Frame (EoF) field is used as data length field instead to allow variable length telegrams at minimal overhead.

The architecture layers of ERP1 and ERP2 are shown in Figures 1 and 2, below.

EnOcean Communications Stack1

Figure 1. ERP1 OSI Layer Architecture.

EnOcean Communications Stack2

Figure 2. ERP2 OSI Layer Architecture.

The communication protocol is packet based and the data units can be of three different types:

  • Frame
  • Subtelegran
  • Telegram

A Frame is the representation of the encoded data on the physical layer. It includes control and synchronization information for the receiver. A frame is transmitted as a bit by bit serial sequence. A subtelegram is the result of a decoding process, in which this control (PRE, SOF, INV and EOF) and synchronization information are removed from the frame. The reverse mechanism to get a frame from a subtelegram is the encoding process.

The subtelegrams are handled in the data link layer. The ERP protocol is designed to work mostly as a unidirectional protocol without handshaking. To ensure transmission reliability three identical subtelegrams are transmitted within a certain time range. Each transmitted subtelegram is an atomic unit and contains all the information the composed telegram contains.

ERP uses only 7 bytes of protocol overhead for the transmission of 1 byte of sensor data. This protocol length is sufficient for the wireless transmission of a measured value while it needs very low power only. This meets the requirements and capabilities for wireless sensors and enables simple deployment of maintenance-free, intelligent nodes.

The data structure of a subtelegram is shown in Figure 3.

Subtelegram structure

Figure 3. Structure of a subtelegram.

The universal fields are:

  • RORG/CHOICE – identifies the subtelegram type.
  • DATA – the payload of the transmitted subtelegram.
  • TXID/SourceID – identifies the transmitter, each having a unique 4-byte identity.
  • STATUS – identifies if the subtelegram is transmitted from a repeater and the type of integrity control mechanism used. This field is not present in a switch telegram.
  • HASH/Checksum – data integrity check value of all the bytes.
  • The length of the subtelegram is not transmitted in the subtelegram structure. The length is determined by counting the number of bytes starting with RORG and ending with HASH.

EnOcean modules transmit data packets at random intervals to ensure that the probability of collision and interference is extremely small. As a result, a range of switches and sensors using the sub 1 GHz frequency band can be operated in close proximity to each other. Besides this, each EnOcean standard module comes with a unique 4-byte (32-bit) identification number (TXID/SourceID), which cannot be changed or copied and, therefore, protects against duplication. This authentication method offers field-proven secure and reliable communication in building automation. For applications requesting additional data security, e.g., in smart home systems, EnOcean protects battery-less wireless communication in sub 1 GHz with enhanced security measures to prevent replay or eavesdropping attacks and forging of messages. These features include a maximum 24-bit rolling code (RC) incremented with each telegram and state-ofthe-art encryption using the AES algorithm with a 128-bit key.

Radio model

Figure 4. EnOcean Radio Communications Model.

The use of repeaters is allowed as described in the next sub-section.

Details on the ERP Physical Layer, Frame specification, Data Link layer, and Network Layer can be found in the EnOcean Radio Protocol version 1 Specification, and in the ERP 2 specification.

Back to Top

EnOcean Equipment Profiles

The ERP specification defines the structure of the entire radio telegram. The user data embedded in this structure is defined by the EnOcean Equipment Profile (EEP).

The objective of interoperability is easier with as few profiles as required. Therefore, the EnOcean Alliance has the goal to configure each profile as universally as possible to target a spectrum of devices in the building automation sector for all manufacturers.

The technical characteristics of a device define three profile elements, which make up the organizational description of all profiles:

  1. The ERP radio telegram type (RORG)
  2. Basic functionality of the data content (FUNC)
  3. Type of device in its individual characteristics (TYPE)

Every EEP has a number, reflecting these three components.

EEP Components

Figure 5. EnOcean Equipment Profile v2.0 and v2.5 components.

Each field is represented by a hexadecimal number, where the maximum value is limited by the available bits.

Before the definition of a new profile, existing profiles must be checked first for suitability. A new profile is to be defines only if the existing profiles would not be accurate. New profiles need to be submitted to the TWG of the EnOcean Alliance which may approve or disapprove the profile.

In ERP2, the various Radio-Telegram types are grouped ORGanizationally. The specifications of ERP and of ESP group telegram types by CHOICE number. RORG in EEP 2.1 (2.5) corresponds to CHOICE. The following RORG are used in EnOcean Equipment Profiles (EEP) 2.5:

Telegram RORG ORG
RPS F6 05 Repeated Switch Communication
1BS D5 06 1 Byte Communication
4BS A5 07 4 Byte Communication
VLD D2 =RORG Variable Length Data
MSC D1 =RORG Manufacturer Specific Communication
ADT A6 =RORG Addressing Destination Telegram
SM_LRN_REQ C6 =RORG Smart Ack Learn Request
SM_LRN_ANS C7 =RORG Smart Ack Learn Answer
SM_REQ A7 =RORG Smart Ack Reclaim
SYS_EX C5 =RORG Remote Management
SEC 30 =RORG Secure telegram
SEC_ENCAPS 31 =RORG Secure telegram with R=ORG encapsulation

For compatibility reasons the old ORG values on the serial ESP2 interfaces remain valid. However, on the air interface, each ESP2 telegram is transported with the appropriate RORG (=CHOICE).

Here are some sample profiles:

Telegram Profile Type Profile Example
F6: RPS Telegram F6-02: Rocker Switch, 2 Rocker F6-02-01: Light and Blind Control - Application Style 1
F6-02-04: Light and blind control ERP2
D5: 1BS Telegram D5-00: Contacts and Switches D5-00-01: Single Input Contact
A5: 4BS Telegram A5-02: Temperature Sensors A5-02-01: Temperature Sensor Range -40°C to 0°C
A5-02-0A: Temperature Sensor Range +50°C to +90°C
D2: VLD Telegram D2-01: Electronic switches and dimmers with Energy management and Local Control D2-01-01: Type 0x01

Back to Top

Repeaters

Repeaters are necessary when the distance between sender and receiver is too large to establish an adequate wireless connection. For bigger distances it is possible to place a maximum of two repeaters in a row. The job of the repeater is to receive the telegram from the sender or another repeater and send it again, so that the receiver of the message can get it. But before it is resent, the repeater modifies the STATUS byte of the telegram. To limit the amount of repeated telegrams in an environment with more repeaters we differ between two repeater levels:

  • Level 1 Repeaters repeat only received original subtelegrams.
  • Level 2 Repeaters repeat only received original or once repeated subtelegrams.

If a level 2 repeater receives an original and also an once repeated subtelegram originating from the same transmitter, it will only repeat once with 3 subtelegrams.

The repeating methods are the same in ERP1 and ERP2.

Back to Top

Edge One™ EnOcean Module

The Edge One™ EnOcean module is supplied as a container that enables bi-directional communications and read/write operations of the Edge One™ platform with EnOcean devices. Data collected from EnOcean field devices can be processed locally by the optional Edge One™ Flows module, by a SmartPlug™ application or another containerized application, and it is then sent to the CloudPlugs cloud, or a supported public cloud.

The Edge One™ EnOcean module publishes values supplied by EnOcean devices into CloudPlugs channels making them available to other devices and applications subscribing to those channels. All the communications with supervisory applications in the cloud are encrypted, event driven and asynchronous, resulting in substantial traffic savings.

A single Edge One™ deployment can operate multiple projects if more than one EnOcean electrical is available on the gateway running the Edge One™ module. Most installations, have a single built-in or USB electrical interface.

Back to Top

EnOcean Module Data Structure

The Edge One™ EnOcean Module uses the standard data representation of all Edge One™ modules.

Device data is stored in JSON, key-value pairs in which the key is the register address and the value is the value of the register.

EnOcean devices need to be associated with an Edge One™ Group in order for their data to become accessible to Edge One™.

  • Group Name, a string that represents the custom name that is entered for the group of devices.
  • Group ID, a number that will be used to identify the group inside the Edge One™ data structure.

The MQTT topics carrying EnOcean payloads have the following structure:


topic:  EnOcean/PID/GID

where,

	EnOcean  indicates that this is a EnOcean module.
	PID		a number or Project ID that identifies the EnOcean project generating data
	GID		a number or Group ID as indicated above

The data inside this topic is a JSON such as:

{ 
   "100": 25,
   "200": 34
}

Register address 100 has a value of 25, and register address 200 has a value of 34.

Data can be read locally or sent to a remote MQTT server or cloud such as CloudPlugs IoT using the Message Router

Back to Top

Still need help? Get in touch!
Last updated on 29th Apr 2020