1. Overview

	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

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.

Figure 1. ERP1 OSI Layer Architecture.

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.

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.

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.

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