System Specification

EnOcean Equipment Profiles
V 3.1

Approved for release: Nov 21, 2019
San Ramon, CA, USA

EXECUTIVE SUMMARY
EnOcean Equipment Profiles (EEP’s) are the fundament of interoperability between EnOcean
devices of all different manufacturers. They define the coding of the data to be exchanged. EEP’s
are located at the application level of the EnOcean communication layers.
This document specifies the rules how EEP’s shall be designed and used. It explains the different
telegram types, coding and decoding of data to be transmitted, and their Teach-In data andprocesses. Ideally, the devices are interoperable when using the same EEP.
The various EEP’s already defined are listed in the former xml EEP-Specification 2.6.8 which stillis valid for the EEP descriptions. New profiles released, are available in the Alliance portal.
This document is owned by the Technical Working Group (TWG) of the EnOcean Alliance. It is
maintained and will be progressed within the authority of the Chairman of the TWG.
Changes to this document have to be proposed to the EAC for review and to the TWG for
decision.
Submitted to the TWG:
Approved by TWG for release:
Approved by BoD for release:

EnOcean Equipment Profiles

Aug 21, 2019
Oct 30, 2019
Nov 21 2019

Page 1/36

System Specification

REVISION HISTORYVer.

EditorChange

Date

2.6.8

NM

Last xml edition of the EEP-Specification

Dec 31, 2017

3.0

AP

Copied all editorial content of the EEP-Specification 2.6.8 Jun 27, 2019and rearranged the chapters.

3.1

TR

Incorporated TWG review comments

Aug 21, 2019
Sep 10, 2019

Chapter “Timing of EnOcean Result Messages” added

Jun 5, 2020

Copyright © EnOcean Alliance Inc. (2020). All rights reserved.
DISCLAIMER
The information within this document is the property of the EnOcean Alliance and its use anddisclosure are restricted. Elements of the EnOcean Alliance specifications may also be subject tothird party intellectual property rights, including without limitation, patent, copyright ortrademark rights (such a third party may or may not be a member of the EnOcean Alliance.)
The EnOcean Alliance is not responsible and shall not be held responsible in any manner for
identifying or failing to identify any or all such third party intellectual property rights. This
document and the information contained herein are provided on an “as is” basis and the
EnOcean Alliance disclaims all warranties express or implied, including but not limited to(1) any warranty that the use of the information herein will not infringe any rights of third parties(including any intellectual property rights, patent, copyright or trademark rights, or(2) any implied warranties of merchantability, fitness for a particular purpose, title or noninfringement.
In no event will the EnOcean Alliance be liable for any loss of profits, loss of business, loss of useof data, interruption of business, or for any other direct, indirect, special or exemplary,incidental, punitive or consequential damages of any kind, in contract or in tort, in connection
with this document or the information contained herein, even if advised of the possibility ofsuch loss or damage. All Company, brand and product names may be trademarks that are thesole property of their respective owners.
The above notice and this paragraph must be included on all copies of this document that are
made.

EnOcean Equipment Profiles

Page 2/36

System Specification

The EnOcean Alliance “EnOcean Equipment Profiles Specification” and the “EnOcean Equipment
Profiles definitions” are available free of charge to companies, individuals and institutions for all
non‐commercial purposes (including educational research, technical evaluation anddevelopment of non‐commercial tools or documentation.)
This specification includes intellectual property („IPR“) of the EnOcean Alliance and joint
intellectual properties („joint IPR“) with contributing member companies. No part of thisspecification may be used in development of a product or service for sale without being aparticipant or promoter member of the EnOcean Alliance and/or joint owner of the appropriate
joint IPR.
These errata may not have been subjected to an Intellectual Property review, and as such, may
contain undeclared Necessary Claims.

EnOcean Alliance Inc.
c/o Global Inventures
5000 Executive Parkway, Suite 302
San Ramon, CA 94583
USA
Graham Martin
Chairman & CEO EnOcean Alliance

EnOcean Equipment Profiles

Page 3/36

System Specification

Table of Content
1. Introduction .................................................................................................................. 6
1.1. General .................................................................................................................. 6
1.2. Viewing of profile data .......................................................................................... 8
1.3. Terms & Abbreviations .......................................................................................... 9
1.4. References ........................................................................................................... 10
2. EEP Approval Process ................................................................................................. 11
2.1. Profile definition (duration: up to the submitter) ............................................... 112.2. Profile review (duration: approx. 4 weeks) ......................................................... 122.3. Profile approval (duration: approx. 4 weeks) ...................................................... 122.4. Official release ..................................................................................................... 13
3. Telegram types ........................................................................................................... 14
3.1.1. RPS/1BS ..................................................................................................................... 14
3.1.2. 4BS ............................................................................................................................. 15
3.1.3. VLD ............................................................................................................................ 15
3.1.4. MSC............................................................................................................................ 15
3.1.5. SMART Acknowledge ................................................................................................. 16

3.2. Teach-In ............................................................................................................... 17
3.2.1. RPS Teach-In .............................................................................................................. 18
3.2.2. 1BS Teach-In .............................................................................................................. 18
3.2.3. 4BS Teach-In .............................................................................................................. 19
3.2.4. SMART Acknowledge Teach-in .................................................................................. 21
3.2.5. UTE – Universal Uni- and Bidirectional Teach-in ....................................................... 23

3.3. Interoperability with High Security of EnOcean Networks ................................. 27
4. Timing of EnOcean Result Messages .......................................................................... 29
4.1. Use Case #1: Result Messages Triggered by Addressed Communication ........... 29
4.2. Use Case #2: Result Messages Triggered by Broadcast Communication ............ 29
4.3. Definition of Timing of EnOcean Result Messages .............................................. 30
4.3.1. Triggered by Addressed Messages ............................................................................ 30
4.3.2. Triggered by Broadcast Messages............................................................................. 30

5. EEP-Guideline ............................................................................................................. 32
5.1. Common requirements ....................................................................................... 32
5.2. Recommendations ............................................................................................... 32
EnOcean Equipment Profiles

Page 4/36

System Specification

5.3. Restrictions .......................................................................................................... 33
5.4. Definition of enumerations ................................................................................. 33
5.5. Usage of scales .................................................................................................... 34
5.6. Bi-directionality ................................................................................................... 35
5.6.1. Communication variants ........................................................................................... 35
5.6.2. Directions................................................................................................................... 36

EnOcean Equipment Profiles

Page 5/36

System Specification

1. Introduction
1.1. General
The EnOcean Radio Protocol (ERP) is optimized to transmit information with utmost reliability
using extremely little power while ensuring that the products of customers applying EnOcean
technology are compatible with each other. Only the very shortest transmission period (< 1ms)
for an EnOcean telegram allows the design of, for example, a battery-free radio switch, which
can produce a full radio command with just approx. 50 μWs (50 μJ) of energy. At the same time,
the reliability of the system increases, as the possibility of data collision is strongly reduced.
Every data bit in the radio telegram is essential. For each ‘0’ or ‘1’ state, content descriptions aredefined, which must be followed by the sender and the receiver likewise.
The ERP specification defines the structure of the entire radio telegram. The user data
embedded in this structure is defined by the EEP (EnOcean Equipment Profiles).
EEPs are one of the EnOcean Alliance’s “languages” applied by devices communicating with eachother. An EEP:

describes the technical characteristics of a device,is optimized to transmit information with utmost reliability using extremely little power,
defines the user data (payload) depending on the telegram type and the function of thedevice,is available to you as a machine-readable xml-file and a derived pdf-file

The objective of interoperability is easier to reach with as less profiles as required. Therefore, it
is EnOcean Alliance’s goal to configure each profile as universally as possible, to target aspectrum of devices in the building automation sector for all manufacturers.
It is of high interest to the EnOcean Alliance that Alliance members verify new devices or newly
joined companies verify their products against the existing EEP’s and adopt these during testing.
Every newly defined EEP would increase diversity and therefore decrease interoperability.
The technical characteristics of a device define three profile elements, which make up theorganizational 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)

EnOcean Equipment Profiles

Page 6/36

System Specification

Therefore, every EEP has a number, reflecting these three components:

Every field is represented by a hexadecimal number, where the maximum value is limited by theavailable bits.

From EEP 3.0 we define all fields with 8 bits. This has impact for 4BS Teach-In, if FUNC > 3F, or
TYPE >7F, and in Remote Management, but will be explained there.

EnOcean Equipment Profiles

Page 7/36

System Specification

1.2. Viewing of profile data
The following example illustrates the HTML-view of the XML-data of a 4BS telegram (= payloadof 32 bits).

Data ranges unused are displayed in the table as white rows.
The ’Bitrange’ column displays the starting-point and the end-point of the respective data. As
this is redundant to ‘Offset’ and ‘Size’, the column ‘Bitrange’ is no longer available in newer
profiles.
The ’Valid range’, ’Scale’ and ’Unit’ columns are displayed separately only for measurement
values. However, these three columns are merged into one if the data comes from anenumeration (enum).
Assuming a linear conversion between the value to be measured and the ‘valid range’ of data
the resolution can be calculated as follows:

EnOcean Equipment Profiles

Page 8/36

System Specification

1.3. Terms & Abbreviations
1BS – EnOcean 1 Byte Communication
4BS – EnOcean 4 Byte Communication
Choice – Unique identification of EnOcean radio telegram types (RPS, 1BS, 4BS ...); equivalent
with RORG
Client – Bidirectional SMART ACK Device
Data – Payload of ERP telegrams or ESP packets
EAC – EnOcean Equipment Profiles Approval Committee
EEP – EnOcean Equipment Profiles
ERP – EnOcean Radio Protocol
ESP – EnOcean Serial Protocol
EURID – EnOcean Unique Radio Identifier, a unique and non-changeable identification number
assigned every EnOcean transmitter during its production process.
HTML – Hyper Text Markup Language; HTML can be displayed using a internet browser
MMI – Man Machine Interface
MSC – Manufacturer Specific Communication
ORG – Organizational number for EnOcean radio telegram types (out-dated with EEP 2.1; used
for ESP2 interface)
RECOM – Remote Commissioning
REMAN – Remote Management
RMCC – Remote Management Control Commands
RORG – Radio ORG = organization number for EnOcean radio telegram types (new with EEP 2.1);
equivalent with ’Choice’
RPC – Remote Procedure Calls, used in Remote Management
RPS – EnOcean telegram type for Repeated Switch Communication
SMART ACK – SMART Acknowledge EnOcean standard for energy-optimized bidirectional transmission
TWG – EnOcean Alliance Technical Working GroupVLD – 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)

EnOcean Equipment Profiles

Page 9/36

System Specification

1.4. References[1] EnOcean Equipment Profiles 2.6.8, EnOcean Alliancehttps://www.enocean-alliance.org/eep/[2] Smart Acknowledge specification, EnOcean Alliancehttps://www.enocean-alliance.org/smartack/[3] Security of EnOcean Networks specification, EnOcean Alliancehttps://www.enocean-alliance.org/sec/[4] Remote Management, EnOcean Alliancehttps:// www.enocean-alliance.org/reman/

EnOcean Equipment Profiles

Page 10/36

System Specification

2. EEP Approval Process

Definition

Review

Design a new
profile or family
member of an
existing profile
with the EEP-Tool.
Submit to EAC.

EAC reviews,
provide change
requests, contacts
submitter, evaluatechanges, makes
recommendation
to TWG

Submitter

EAC

Approval
Submitter presents
profile in TWG call.
TWG discusses.
Review period of 4
weeks starts.
Approval, change
request or refusal.

TWG

ReleaseWhen approved,
EEP proposal will
be available in thestorage of all new
EEPs

TWG-Chair

The normal processing time for an approval process is, at best, about 8 weeks. For this reason,
it is recommended to specify a new EEP as early as possible and send it to the EAC team. The
EAC team then has sufficient time to verify the new profile and can optionally support thesubmitter if changes need to be done to get the profile to the TWG for the review phase.
The argument that the product is "ready to ship" will not shorten the review and approval phase.
For this reason, the EEP should be submitted at least 10 weeks before the start of production.
During holiday seasons (N. Hemisphere Summer, end of year season) there may be a delay inprofile approval period.

2.1. Profile definition (duration: up to the submitter)
Specify your application in detail.
Before the definition of a new profile, existing profiles should be checked first for suitability. A
new profile is to be defined only if the existing profiles would not be adequate. Check thelatest EEP Specification as well as new EEPs in the pipeline issued for existing profiles that
could be used for your application (If there is a suitable EEP, the process ends here).
Design a new profile or a new family member of an existing profile with the EEP-Tool according
to your requirements following the EEP proposal guidelines. The EEP-Tool is a web-based
application which helps companies designing and submitting a new EEP according to therequirements of a new or redesigned EnOcean device.
The EEP-Tool can be found here:
http://tools.enocean-alliance.org/web/eeptool0/index.php#

EnOcean Equipment Profiles

Page 11/36

System Specification

As EEPs are the fundament of interoperability between EnOcean devices of all different
manufacturers, profile definitions within the EEP Specification have to be clear andunderstandable.
The tool guides the user through the design of the EEP with the goal to reduce the workload for
him and the approval process. Xml-data required for automated reading by gateways ordevelopment tools will be generated as well as a representation in a pdf file, the test containers
and the IP representation.
Save your work in order to make any requested corrections later on!
Once a new profile is to be developed, it should be submitted to the EnOcean EEP ApprovalCommittee (EAC) via e-mail (eep-proposal@enocean-alliance.org).
Kindly submit the generated .pdf, .xml and saved work files. Incomplete submissions will berejected or significantly delayed!

2.2. Profile review (duration: approx. 4 weeks)
The EAC will review the profile proposal and:
 …contact the submitter to discuss the proposal.
 …provide change requests if necessary.
 …evaluate made changes.
 …make a recommendation for the profile presentation to the TWG.
After that, the EAC will forward the profile proposal to the TWG-Chair.

2.3. Profile approval (duration: approx. 4 weeks)
The TWG will review and ratify the profile. Following the recommendation by the TWG the BoD
will disapprove or approve the profile.
1.
2.
3.
4.
5.

The submitter presents the profile during an official TWG conference call.
The EAC recommends the profile for approval (or rejection).
The TWG discusses the presented EEP proposal(s).
The official TWG review phase (4 weeks) commences.
Every TWG member is allowed to provide questions, remarks or objections during thereview phase, which are then forwarded to the submitter for response.
6. The review phase ends with:a. The approval (no objections, no change requests) => the profile can be applied
officially.
b. A change request => the profile is returned to the submitter and must be resubmitted.
c. A refusal => the profile is not accepted and may NOT be applied officially.

EnOcean Equipment Profiles

Page 12/36

System Specification

2.4. Official release
An approved profile will be added to the ‘specification/new EEPs since 2.6.8’ folder on the
EnOcean Alliance platform. The pdf and xml files are stored in the respective subfolders. In
each subfolder the approved EEPs are sorted according to their profile number.

EnOcean Equipment Profiles

Page 13/36

System Specification

3. Telegram types
The various Radio-Telegram types are grouped ORGanizationally.
The following RORG’s are used:
Telegram

RORG

Description

RPS

F6

Repeated Switch Communication

1BS

D5

1 Byte Communication

4BS

A5

4 Byte Communication

VLD

D2

Variable Length Data

MSC

D1

Manufacturer Specific Communication

ADT

A6

Addressing Destination Telegram

SM_LRN_REQ

C6

SMART ACK Learn Request

SM_LRN_ANS

C7

SMART ACK Learn Answer

SM_REC

A7

SMART ACK Reclaim

SYS_EX

C5

Remote Management

SEC

30

Secure telegram

SEC_ENCAPS

31

Secure telegram with RORG encapsulation

SEC_MAN34

Maintenance Security message

SIGNAL

D0

Signal telegram

UTE

D4

Universal Teach In

Structure of the telegram types

3.1.1. RPS/1BS

The RPS and the 1BS telegrams offer only 1-byte user data. These two telegrams differ in therespective learning operations (the 1BS has a LRN bit), and in the way the status byte is used.
Comment for RPS status bits:
T21 = 0 = PTM switch module of type 1 / synonymous for module PTM1xx T21 = 1 = PTM switch
module of type 2 / synonymous for module PTM2xx NU = 1 = N-message (N = normal)
NU = 0 = U-message (U = unassigned)

EnOcean Equipment Profiles

Page 14/36

System Specification

3.1.2. 4BS
A 4BS telegram carries a payload of 4 bytes. The sequence of the 4 data bytes is historicallyreversed, so that DB_3 appears first and DB_0 last on the radio interface. The bits are addressedin the sequence of the data flow, however (offset). Hence, DB_3.BIT_7 has the offset position 0
and DB_0.BIT_3 (LRN bit) has the offset position 28. The actual content-bits in a byte are notaffected by this, i.e., they are described from right (2H0) to left (2H7) in the ascending order.
The example of a 10-bit temperature profile (see below) illustrates the binary valuation of theindividual bits, so that a number range from 0 ... 1023 can be addressed.

3.1.3. VLD
VLD (Variable Length Data) telegrams carry a variable payload between 1 and 14 bytes,
depending on their design.
The following example displays a VLD telegram with 6 bytes user data. DB_5.BIT_7 is the firsttransmitted bit with offset 0.

3.1.4. MSC
Communication over MSC (Manufacturer Specific Communication) telegrams can always be
used when bigger data volumes are to be transmitted, and at the same time, a closed system
EnOcean Equipment Profiles

Page 15/36

System Specification

structure is to be created. This can be the case if e.g., the controller system backbone isexpanded to include radio components, or if safety-related controls require proprietary data
structures.
Such communication must not affect any interoperable EEP-based communication and should
be identifiable as MSC.
Interoperability Conditions:
A device using MSC in addition to other EEPs may be marked with the EnOcean ingredient logo,
as long as it complies with the rules defined by the EnOcean Alliance for such markings. A device
using MSC may be marked with the EnOcean ingredient logo even though the manufacturer
does not disclose any or all information regarding the MSC payload. However, all otherfunctionality of such a device shall comply with the latest EEP specification and such a device
shall support at least one additional EEP. The manufacturer must clearly state which EEP(s) the
device complies with. To safeguard interoperability, if there is sufficient justified doubt within
the EnOcean Alliance TWG, a specific unit using MSC can be assessed by the TWG and if foundto breach the interoperability intentions, the TWG may then decide (majority vote) to adapt therules for the usage of the interoperability logo.
The MSC telegram has the same structure as a VLD telegram. The only difference is that the
RORG Number is different and the payload specification is missing.

The following points are to be noted:
1. The usage of the Multi User Manufacturer ID (0x7FF) shall not be allowed.
2. Each user may send MSC telegrams under his own Manufacturer ID. The Manufacturer ID
should not be left out.

3.1.5. SMART Acknowledge
SMART ACK is a bidirectional communication protocol between a self-powered device and a linepowered controller. Data transmission in both directions is controlled by the sensor/client, as
the limited energy budget requires an exact synchronization of the sent and the received
messages. This pre-defined time interval allows a very short activation of the energy-intensive
receiver electronics on the client.
Bidirectional VLD profiles may use SMART Acknowledge as the communication protocol. Pleaserefer to the corresponding profile description.
Please refer to [2] for more details on SMART Acknowledge.
EnOcean Equipment Profiles

Page 16/36

System Specification

3.2. Teach-In
The ‘Teach-in’ defines the mutual communication between wireless devices in a radio network.
The ‘Teach-in’ defines to which transmitter(s) a receiver needs to listen to.
For this purpose of a determined relationship between transmitter and receiver, eachtransmitting device has a unique Sender-ID (EURID), which is part of each radio telegram. The
receiving device detects from the Sender-ID whether the device is known, i.e., was alreadylearned, or unknown. A telegram with unknown Sender-ID is disregarded.
The teach-in method that a device uses depends on many factors, including whether or not thedevice uses security. If EEP’s do not dictate whether a device uses security or not they must also
not dictate the Teach-in method that a device shall use. The Teach-in section from former EEP
documents can be ignored and for new EEP’s will not be specified.
Also, some manufacturers may choose to use Teach-in methods that do not involve the EnOcean
radio at all, i.e. NFC or QR-Code. But if the device supports Teach-in by EnOcean radio, the Teachin process of this chapter has to be applied to ensure interoperability.
The ‘Teach-in’ process is different for each telegram type (RPS, 1BS, 4BS, SMART ACK), but thefollowing points are valid for all telegrams:First, the receiver must be switched into learning mode. Now, the Sender-ID of anarriving telegram is interpreted as an authorized information source, and will be stored
at the receiver. The further steps of ‘teach-in’ are defined by the device type or the
telegram type. Thus, normal data telegrams or special teach-in telegrams can be used.
Frequently, a learn button triggers the teach-in process.
The telegram of the respective transmitter should be triggered at least once (by pressing
the desired switch rocker or triggering a sensor).
The bits of the payload (data bytes) can have multiple functions depending on theinterpretation set by identification or status bits. Only in the 1BS and 4BS telegram the'LRN BIT' DB_0.BIT_3 is reserved exclusively and must not be used elsewhere.

The following issues are relevant for a number of application but not mandatory for specification
perspective:

To prevent unwanted devices from being learned the input sensitivity of the receiver isoften restricted, and thus an IN-ROOM operation is created. Typically, the device to belearned is placed close by the receiver.
Transmitters can also be switched into the learn-mode via a remote management
command. To avoid inadvertent learning the RPS telegrams have to be triggered 3 times
within 2 seconds.

EnOcean Equipment Profiles

Page 17/36

System Specification

3.2.1. RPS Teach-In

The RPS telegram can only send data and has no special telegram modification to teach-in thedevice. Therefore, the teach-in procedure takes place manually on the actuator/controller
through a normal data telegram. The EEP profile must be manually supplied to the controller
per sender ID.
In learn mode, the receiving actuator reduces the input sensitivity in order to fade out weakly
received data telegrams. This helps avoid inadvertently teaching-in sensors.

3.2.2. 1BS Teach-In

The 1BS telegram has its own teach-in telegram, which can signal the teach-in command throughthe DB_0.BIT_3 data bit.
Offset Size Bitrange
4

1

DB0.3

EnOcean Equipment Profiles

Data
LRN Bit

Valid Range

Scale

Unit

Enum:
0:

Teach-in telegram

1:

Data telegram

Page 18/36

System Specification

3.2.3. 4BS Teach-In

The 4BS telegram also has its own teach-in telegram, however with more teach-in variations:
Variation 1: Unidirectional profile-less
The profile-less unidirectional teach-in procedure works according to the same principle as the
1BS telegram: if the data bit DB_0.BIT_3 = 0, then a teach-in telegram is sent. This includes the'LRN TYPE' DB_0.BIT_7 = 0 data bit. Then no EEP profile identifier and no manufacturer ID aretransferred.
Offset Size Bitrange

Data

Valid Range

24

1

DB0.7

LRN Type Enum:

28

1

DB0.3

LRN Bit

0:

Scale

Unit

telegram without EEP and Manufacturer ID

Enum:
0:

Teach-in telegram

1:

Data telegram

Variation 2: Unidirectional with profile
For the unidirectional profile teach-in procedure, it is preferred in opposite to variation 1, as theteach-in telegram contains both the complete EEP number and the manufacturer ID. The device
is therefore clearly identifiable as ready-to-use and can be securely executed in a complex
system environment or by foreign systems. In this case, the 'LRN TYPE' data bit is DB_0.BIT_7 =1. For FUNC > 3F or TYPE > 7F UTE has to be used instead of 4BS Teach-In.
Offset Size Bitrange

Data

Valid Range

24

1

DB0.7

LRN Type Enum:

28

1

DB0.3

LRN Bit1:

EnOcean Equipment Profiles

Scale

Unit

telegram with EEP number and Manufacturer ID

Enum:
0:

Teach-in telegram

1:

Data telegram

Page 19/36

System Specification

Variation 3: Bidirectional
During the bidirectional teach-in procedure, further bits are required from the DB_0, in order todevelop the mutual teach-in between two communication partners. For this, the procedure ismade up of 2 teach-in telegrams, which are exchanged on both sides. The following UML
diagram is used to illustrate this:

Offset Size Bitrange
24

1

DB0.7

Data

Valid Range
0:

25

26

27

28

1

1

1

1

DB0.6

DB0.5

DB0.4

DB0.3

Scale

Unit

LRN Type Enum:EEP
ResultLRN
ResultLRN
StatusLRN Bittelegram without EEP and Manufacturer ID

1:telegram with EEP number and Manufacturer
ID
Enum:
0:

EEP not supported

1:

EEP supported

Enum:
0:

Sender ID deleted/not stored

1:

Sender ID stored

Enum:
0:

Query

1:

Response

Enum:
0:

Teach-in telegram

1:

Data telegram

For FUNC > 3F or TYPE > 7F UTE has to be used instead of 4BS Teach-In

EnOcean Equipment Profiles

Page 20/36

System Specification

3.2.4. SMART Acknowledge Teach-in
SMART Acknowledge is a bidirectional communication protocol between a self-powered device
and a line-powered controller.
Under SMART Acknowledge (SA), the teach-in procedure is more complex as, alongside the SA
client and SA controller, a Postmaster must also be established to prepare a mailbox for eachtaught-in SA client. The Postmaster is normally found in the controller.

EnOcean Equipment Profiles

Page 21/36

System Specification

If a repeater comes into operation, the SA_LEARN_REQUEST telegram sent by the SA client (withan EEP No., Manufacturer ID, Sender EURID) is completed on the repeater with the RSSI value(in dBm) and the Repeater EURID, and sent to the controller.

From the reception strength of the RSSI, the controller can recognize which repeater is best for
the task of postmaster.

Please refer to [2] for more details on SMART Acknowledge.

EnOcean Equipment Profiles

Page 22/36

System Specification

3.2.5. UTE – Universal Uni- and Bidirectional Teach-in
GeneralThere are different teach-in procedures available for:






RPS communication (EnOcean ID + rocker/channel information, unidirectional)
1BS communication (LRN telegram, w/o EEP and MID, unidirectional)
4BS communication (LRN telegram, w FUNC+TYPE and MID, unidirectional)
4BS communication (LRN telegram, w FUNC+TYPE and MID, bidirectional)
SMART ACK communication (self-powered devices, bidirectional)

For uni- and bidirectional EEP communication that does not fit into SMART ACK communication
principles but is based on e.g. MSC and VLD messages no teach-in procedure is defined.
Therefore, this chapter describes the universal teach-in procedure that allows handling of teachin and teach-out requirements for EEP based communication of all different RORG. UTE shall be
understood as an alternative to SMART ACK teach-in for devices where SMART ACK is notapplicable.
RORG to be used: 0xD4 Universal Teach-in, EEP based (UTE)
FUNC and TYPE are represented as 8-bit parameters, both with a value range from 0x00 … 0xFF.
This aligns UTE with the EEP representation defined for SMART ACK teach-in.
REMARK 1:
Even though the Universal Tech-In Procedure is able to cover EEPs based on RPS, 1BS and 4BS
messages as well, it is not intended to replace the existing RPS, 1BS and 4BS teach-in / teach-out
procedures for unidirectional and the existing 4BS teach-in / teach-out procedures forbidirectional communication.
However, it is recommended that with the acceptance of the Universal Tech-In Procedure all
new bidirectional 4BS applications shall use it for teach-in and teach-out as well.
REMARK 2:
The Universal Tech-In Procedure is dedicated to EEP based EnOcean communication. It does
neither compete with nor shall it interfere with the teach-in process of the Generic EnOcean
Communication.

EnOcean Equipment Profiles

Page 23/36

System Specification

Communication – Principles and Definitions

BIDIRECTIONAL EEP-BASED COMMUNICATION
Bidirectional EnOcean communication means a point-to-point communication relationshipbetween two enabled EnOcean devices. It requires all parties involved to know the unique
EnOcean ID of their partners.
Such point-to-point communication relationship is established with the completion of a
successful teach-in process and it is deleted with the completion of a successful teach-out
process.
To get a maximum reliable teach-in process with a minimum consumption of energy andresources, a simple query -response mechanism is used: the device that is intended to be taughtin broadcasts a query message and gets back an addresses response message, containing its own
EnOcean ID as the transmission target address.
In case there is more than one device ready to accept teach-in query messages at the same time
and within the same radio range, the device with the quickest response time will be acceptedby the device to be taught-in. Second and further devices will respond as well but they will not
be accepted by the device to be taught-in. This will result in a configuration situation that iscommon to today’s EEP based unidirectional teach-in processes.

UNIDIRECTIONAL EEP-BASED COMMUNICATION
Unidirectional EnOcean communication means a point-to-multipoint communication
relationship between enabled EnOcean devices. In this case of broadcasting the device to betaught-in to other devices does not know the unique EnOcean ID of those communication
partners.
The Universal Teach-In Procedure supports unidirectional EnOcean communication thru related
configuration bits in the query message.
However, for specific applications – e.g. configuration feedback - it is also possible to combine abidirectional teach-in process with a unidirectional EEP based communication during the regular
operation of a device.

EnOcean Equipment Profiles

Page 24/36

System Specification

EEP Teach-In Query - UTE Message (Broadcast / CMD: 0x0)
This message is sent by the EEP based EnOcean device that is intended to be taught-in to anotherdevice (which has been set into LRN-mode before either manually or thru a ReMan command).

Offset Size
01

Description
Communication during EEP operation

Valid Range

Scale

Unit

Enum:
0b0: Unidirectional
0b1: Bidirectional

1

1

EEP Teach-In-Response message
expectation

Enum:

Request typeEnum:0b0: Response expected0b1: No Teach-In-Response220b00: Teach-In request
0b01: Teach-In deletion request
0b10: Teach-In or deletion of Teach-in, not specified
0b11: Not used
44Command identifier (CMD)

Enum:

8

8

Number of individual channel to betaught in

0x00…0xFE

0x0: EEP Teach-In Query
0x00…0xFE

Channel No.

Enum:
0xFF: Teach-In of all channels supported by the device
16

8

Manufacturer-ID (8 LSB)24

5

Not used (=0)

0x00…0xFF

29

3

Manufacturer-ID (3 MSB)

0x00…0x07

32

8

TYPE

0x00…0xFF

40

8

FUNC

0x00…0xFF

48

8

RORG

0x00…0xFF

Response Timing:
If a response is expected it shall be received within a maximum of 700ms from the time oftransmission of this message. In case no such response is received within this period, the query
action shall be treated as completed with negative result. If no response is expected, each query
action has to be treated as completed with positive result.

EnOcean Equipment Profiles

Page 25/36

System Specification

EEP Teach-In Response - UTE Message (Broadcast / CMD: 0x1)
This message is the reply to an EEP Teach-In Query message. It is sent by the EEP based EnOcean
device that has been set into LRN-mode before (either manually by HMI or thru a ReMan
command).

Offset Size
01

Description
Communication during EEP
operation

Valid Range

Scale

Unit

Enum:
0b0: Unidirectional
0b1: Bidirectional

1

1

Not used (=0)

22Request typeEnum:
0b00: Request not accepted, general reason
0b01: Request accepted, Teach-in successful
0b10: Request accepted deletion of Teach-in successful
0b11: Request not accepted, EEP not supported

44Command identifier (CMD)

Enum:

8

8

Number of individual channel
to be taught in

0x00…0xFE

0x1: EEP Teach-In Response
0x00…0xFE

Channel No.

Enum:
0xFF: Teach-In of all channels supported by the device
16

8

Manufacturer-ID (8 LSB)24

5

Not used (=0)

0x00…0xFF

29

3

Manufacturer-ID (3 MSB)

0x00…0x07

32

8

TYPE

0x00…0xFF

40

8

FUNC

0x00…0xFF

48

8

RORG

0x00…0xFF

Remark: DB5.7 to DB0.0 has same structure as Teach-in-Query and contents are echoed back.
Response Timing:
If a response is requested this message shall be sent within a maximum of 500ms from the timeof reception of the EEP Teach-In Query message. This limit shall give sufficient time to decide on
the teach-in request and answer accordingly (e.g., when requests need to be processes by database systems connected asynchronously).

EnOcean Equipment Profiles

Page 26/36

System Specification

3.3. Interoperability with High Security of EnOcean Networks
The Specification “Security of EnOcean Networks” [3] defines two new telegram types for highsecurity EnOcean telegrams in operational mode:

RORG = 0x30 = SEC
RORG = 0x31 = SEC_ENCAPS

Secure telegram
Secure telegram with RORG encapsulation

To make sure that interoperability is warranted, both telegrams may be used for telegram
transmission with existing EEP’s. Because the profile of the device is known, the data of the SEC
or SEC_ENCAPS telegram contains the same information as described in the profile, but it may
be encrypted defined by the SLF (Security level format) of the device. When the device uses
more than one RORG’s in operational mode, the SEC_ENCAPS telegram has to be applied toensure the correct original RORG after converting from high security to basic telegram.
Example for converting a telegram from basic to high secure and back:
Basic:High Security:
Basic:The data of the known profile will be applied in the basic telegram after the conversion fromhigh secure to basic telegram.
Example for converting a telegram from basic to high secure and back with encapsulated RORG:
Basic:High Security:
Basic:

After conversion from high secure to basic telegram, the encapsulated RORG will be applied in
the telegram. The data of the profile of the encapsulated RORG will be applied.
Specifying the security level in the EEP would lead to the submission and creation of EEP’s thatare identical to existing EEP’s except that they require a different security level. This would lead
to less reuse of EEP’s.
All EEP’s therefore potentially support all security levels (including basic), and that no EEP’s
require high security or a particular security level. The references to “Encryption supported”,“Encryption required”, or “Security Level Format” from existing EEP’s in former revisions of the
EEP specification shall be ignored.

EnOcean Equipment Profiles

Page 27/36

System Specification

High Security Teach-In procedure: (only if done by EnOcean radio)
1. Send secure Teach-In (SEC_TI) telegram(s) with basic security level to transmit SLF, secretkey and RLC.
2. Send EEP-Teach-In with encapsulated R-ORG (SEC_ENCAPS) with high security (applying
former transmitted SLF, key, RLC) to transmit the EEP profile number. Important is totransmit with encapsulated R-ORG, otherwise the receiver is not informed about the R-ORG.

EnOcean Equipment Profiles

Page 28/36

System Specification

4. Timing of EnOcean Result Messages
EnOcean Result Messages are sent by certain EnOcean devices either to communicate a statuschange that occurred during regular device operation or to answer a request message received
from another device. EnOcean Result Messages are defined in several EEPs representing thecommunication of device status and measurement result data, but they are not limited to EEP
based EnOcean communication.
EnOcean Installations may consist of a larger number of devices, e.g. actuators, which are allcontrolled by other devices that transmit addressed messages, e.g. gateways, or broadcast
messages, e.g. rocker pushbutton switches.
If such controlled devices transmit Result Messages based on the reception of addressed or
broadcasted messages, transmit timing needs to be thoroughly controlled to achieve best
achievable communication performance and user experience.
EnOcean Messages related to SMART ACK, REMAN and RECOM communication are not coveredby this chapter.

4.1. Use Case #1: Result Messages Triggered by Addressed Communication
In case one gateway controls several actuators through addressed messages, e.g. using EEP D201-00, response timing of each actuator should be as short as possible, thus, to allow for a
feedback driven step-by-step execution of a switching scene related device list at maximum
execution speed.
Maximum execution speed combined with correct status representation creates the best user
experience, especially when working on a graphical man machine interface.
The same is true if a gateway or centralized controller needs to request status of each device
taught-in after an MMI request, operational reset or power-up, using an EEP compliant numberof individual addressed request messages.

4.2. Use Case #2: Result Messages Triggered by Broadcast Communication
In case one rocker pushbutton switch, defined as CENTRAL ON /OFF functionality, controls
several actuators through broadcasted messages, e.g. using EEP F6-02-01, response timing ofeach actuator should be spread over time. This is, because status messages transmitted by theactuators in parallel will jam each other, plus they will block the radio channel for the original
broadcast control message, especially if radio coverage is achieved using standard repeaters.
Optimized communication performance and user experience in this use case means, allactuators execute CENTRAL ON/OFF reliably on a first and single pushbutton press.

EnOcean Equipment Profiles

Page 29/36

System Specification

If a gateway controls the same actuators in parallel, the communication timing should make itpossible for the gateway to derive correct status representation from the actuators status
messages received.
The same is true if a gateway or centralized controller requests status of each device taught-in
after an MMI request, operational reset or power-up, using an EEP compliant broadcast request
message.

4.3. Definition of Timing of EnOcean Result Messages
For EnOcean Devices affected by this specification and introduced to the market firstafter January 1st, 2021, the following provisions shall apply.

In case definitions in EEPs contradict with provisions of this specification, this specification
shall prevail.

4.3.1. Triggered by Addressed Messages
An EnOcean device receiving an addressed message that causes a reply, shall send such Result
Message within 60ms from receipt of the addressed message.
If an EnOcean device can handle multiple messages triggering a reply in parallel, the following
provisions shall apply:
In case a subsequent addressed message is received, which causes the same reply, prior to the
Result Message of the before received message has been transmitted by the device, such first
Result Message shall be cancelled and the addressed message received last shall be handledaccording to the definitions of this paragraph.
In case a subsequent broadcasted message is received, which causes the same reply, prior to
the Result Message of the before received message has been transmitted by the device, suchfirst Result Message shall be cancelled and the definitions of paragraph 4.3.2. shall apply.

4.3.2. Triggered by Broadcast Messages
An EnOcean device receiving a broadcasted message that causes a reply, shall send such Result
Message within a time frame of 200ms … 10,000ms from receipt of the broadcasted message.
As an option, the Result Message may be repeated one or two times within the defined timeframe. Transmit time(s) shall be spread randomly over this time frame and the data sent shallcorrespond with the to be sent data valid at the time of transmission.
If an EnOcean device can handle multiple messages triggering a reply in parallel, the following
provisions shall apply:
EnOcean Equipment Profiles

Page 30/36

System Specification

In case a subsequent broadcast message is received, which causes the same reply, prior to the
Result Messages (1 … 3) of the before received message have been transmitted by the device,
such first Result Messages shall be cancelled and the time frame timer shall be retriggeredwith a random value.
In case a subsequent addressed message is received, which causes the same reply, prior to the
Result Messages (1 … 3) of the before received message have been transmitted by the device,
such first Result Messages shall be cancelled and the definitions of paragraph 4.3.1. shallapply.

EnOcean Equipment Profiles

Page 31/36

System Specification

5. EEP-Guideline
This chapter shows what is to consider, when developing devices using EEP’s or designing new
EEP’s.

5.1. Common requirements
Every submitted EEP is subject to change by the EAC, and may be turned down by the TWG.
The unique profile number (i.e. the combination of R-ORG, FUNC, and TYPE) will be defined by
the EAC. The EEP-tool’s defaults are FF.
New profiles within the 1BS EEP family are not permitted and are not supported by the EEPtool. RPS profiles are exclusively reserved for energy harvesting applications. If required, apply
the old template to submit a RPS profile, please. 4BS profiles should not be created, as theuser data is limited to 4 bytes. New profiles should therefore use VLD.
Configuration parameters for commissioning, or the application setup, have to be part of
Remote Commissioning and not of the EEP data definitions.
For battery or energy level parameters, it is mandatory to use the Signal telegram. Such levelparameters are not acceptable in new EEP proposals.
Every EEP constitutes an application. Profiles are not meant to combine different applications.
Every application using a certain profile has to support all defined commands and parameters.
Certain parameters within a profile can be optional as their values are not permanently
available during runtime. Furthermore, it is possible to declare a parameter as ‘not supported’
if the application wants to show that the value is not only temporarily unavailable. Therefore, aparameter should include status information coded like this: ‘valid’ (value is valid), ‘invalid’(value is temporarily invalid), ‘not supported’ (value is permanently invalid).
Profiles dealing with similar applications and data are bundled in EEP families (i.e. same FUNC).
Within these EEP families, commands and parameters are used in the same way and new
TYPEs can be added by defining a new combination of parameters and/or adding newcommands or parameters.

5.2. Recommendations
Sophisticated applications should use the Generic Profiles approach.
Profile titles, descriptions and parameters should use common terms (e.g. from existing
profiles) to keep the profile documentations as simple as possible. Abstract parameter names(e.g. tint level) should be explained briefly.
The bits and bytes order should follow the data transmission order and alignment.
EnOcean Equipment Profiles

Page 32/36

System Specification

5.3. Restrictions
The data content of new profiles should be unique. For this reason, new profiles may not include
different scaling of data in different data bytes, where the valid scaling/data byte only is marked
by a bit.

5.4. Definition of enumerations
An enumeration in an EEP parameter is an ordered listing of all the items in a collection. The set
must be finite. The size of the enumeration is not limited. It is possible, that not all enumerations
are used and so the unused ones are reserved.
OffsetSize

IP keyDescription…

3

Fanspeed

Fanspeed

Valid
Scale
Range
Enum:
0: Auto1: Speed 0 / OFF
2: Speed 1
3: Speed 2
4: Speed 3
5 ... 7: Reserved

Unit

It is allowed that enumerations are defined in ranges of values.
OffsetSize

IP keyDescription…

8

PIR_state

PIR Status

Valid
Scale
Range
Enum:
0...127: PIR off
128...255: PIR on

Unit

The combination of enumerations with parameters having a valid range and scale are allowed.
But they are required to have two different IP keys.
Offset…

Size

IP keyDescription

Position

Current vertical
position

Position_
Unknown

Position
unknown

Valid
Range
0...100

Scale

Unit

0...100%

7Enum:
127: Position unknown

Each enumeration IP-Key is unique over all EEPs. It is not allowed to use the same IP-Key namewith different enumeration values and meanings.
It is allowed to extend reserved values of an existing enumeration. The size and the previous
defined values remain unchanged and the reserved values will be occupied.
A device may use only a sub set of the defined enum values. In the following example, a device
is allowed to use enum 2 and 3 if the device supports only two speeds of the fan.
EnOcean Equipment Profiles

Page 33/36

System Specification

OffsetSize

IP keyDescription…

3

Fanspeed

Fanspeed

Valid
Scale
Range
Enum:
0: Auto1: Speed 0 / OFF
2: Speed 1
3: Speed 2
4: Speed 3
5: Speed 4
6 ... 7: Reserved

Unit

5.5. Usage of scales
Scales define the minimum and maximum value of a measurement an EEP can transmit. In thisexample, the sensor measures the temperature from 0 to 50 °C and the humidity from 0 to
100 %.
OffsetSize

IP keyTemperature

08Status_Temperature

8

Description

Valid
Range

Temperature
StatusTemperature
Sensor0..250of

Humidity

Relative Humidity(linear)Status_Humidity

Status of Humidity
Sensor8

Scale
Linear,0...50

Unit

°C

Enum:
250..254: reserved
255: error
0…200

0…100

% RH

201…254: reserved
255: error

If the used sensor HW is not able to measure the whole scale because of HW restrictions it isallowed to use a subset of the defined scale of the EEP. In this example it would be allowed tobuild a sensor which is only able to measure values from 5 °C to 40 °C or 10 to 95 %RH. The
values the sensor cannot measure will never transmitted.
It is not allowed to extend the scale limits of the EEP by using overflowed values.

EnOcean Equipment Profiles

Page 34/36

System Specification

5.6. Bi-directionality
5.6.1. Communication variants
At present, 3 different communication variants having the existing XML structure can bemapped, which approximate the principles of a bi-directional data transfer. The teach-inprocedure required for this is described in the same chapter.
The original terminology 'transmit mode / receive mode' was not taken over, as no uniqueassignment to device type and hence to transmission direction can be derived there from. A
neutral number (Direction 1 / 2) or the state of a bit should allow the required free space to theindividual application.

Variant 1:

In Variant 1, there is no data-technical differentiation option in the 4BS telegram between
Direction 1 and Direction 2, but only a documentation-related direction specification. No
transmission direction can be detected if the telegrams are monitored on the radio stretch.

Variant 2:

EnOcean Equipment Profiles

Page 35/36

System Specification

In Variant 2, three bits are provided in the 4BS telegram, which allow up to eight different datainterpretations of the same EEP Profile No. through bit combination. One bit is used for direction(with the instruction text 'message source') and two bits for the Message ID.

Variant 3:

In Variant 3, the SMART ACK technology normally offers multiple use options of bidirectional
data transmission. SMART ACK clients can therefore be energy self-sufficient devices. The used
VLD telegrams allow a payload of up to 14 bytes (12.5 bytes with Manufacturer ID). Contents
can thus be structured more individually.

5.6.2. Directions
For EEP commands, a direction has to be specified.
There are two valid directions: “FROM” and “TO”. This is defined by the device that sent theteach-in request.

Teach-in request
Teach-in response (optional)“TO““FROM“Device on the left is typically an actuator or a sensor. Device on the right is typically a gateway.
FROM:
mainly used for ‘response’ or ‘status’ messages
TO:mainly used for ‘set’ or ‘get/query’ messages

EnOcean Equipment Profiles

Page 36/36