EnOcean Equipment Profiles (EEP): Understanding A5, D5, F6 Profile Families
The EnOcean Equipment Profile (EEP) is a 3-byte identifier that defines the complete telegram format for an EnOcean device: what data bytes are transmitted, how they are encoded, and what physical quantity each byte represents. Any EnOcean receiver that knows a sender's EEP can decode every telegram from that device — regardless of which manufacturer produced it.
EEP structure: RORG-FUNC-TYPE
Every EEP code consists of three bytes expressed in hexadecimal and written as a hyphen-separated triplet. Each byte carries a distinct meaning:
EEP byte structure
EEP: A5 - 04 - 01
↑ ↑ ↑
RORG FUNC TYPE
RORG (Radio ORGanization, byte 1):
Defines telegram structure and payload length
0xA5 = 4BS (4 data bytes)
0xD5 = 1BS (1 data byte)
0xF6 = RPS (1 data byte, rocker/pushbutton)
0xD2 = VLD (variable length, up to 14 bytes)
0xD1 = MSC (manufacturer-specific, variable)
FUNC (Function, byte 2):
Sub-category within RORG family
A5-04 = Temperature and Humidity sensors
A5-07 = Occupancy sensors
A5-06 = Light, temperature and occupancy sensor
A5-12 = Automated meter reading
TYPE (Type, byte 3):
Specific variant within FUNC category
A5-04-01 = Range 0–40°C, 0–100%RH
A5-04-02 = Range -20–60°C, 0–100%RH
A5-04-03 = Range -20–60°C, 0–100%RH (extended)EEP is not transmitted in normal data telegrams. The RORG byte is embedded in the telegram header (it is the telegram type identifier), but FUNC and TYPE are not sent in regular data telegrams. They are only transmitted during the teach-in sequence. This is why gateways require the EEP to be manually configured — or captured during teach-in — for each sensor channel.
RORG families overview
The RORG byte determines the telegram structure. Most building automation sensors use 4BS (0xA5) for multi-value measurements and RPS (0xF6) for rocker switches. VLD (0xD2) is used for actuators and devices with bidirectional communication.
| RORG | Hex | Payload | Typical use |
|---|---|---|---|
| 1BS (1-Byte Sensor) | 0xD5 | 1 byte (8 bits) | Door/window contact, simple binary sensor |
| 4BS (4-Byte Sensor) | 0xA5 | 4 bytes (32 bits) | Temperature, humidity, occupancy, illuminance, energy meter |
| RPS (Repeated Switch) | 0xF6 | 1 byte (8 bits) | Rocker switch, push-button, window handle position |
| VLD (Variable Length Data) | 0xD2 | 1–14 bytes | Actuators, bidirectional devices, HVAC valves |
| MSC (Manufacturer-Specific) | 0xD1 | Variable | Proprietary datapoints, requires manufacturer decoder |
| ADT (Addressing Destination) | 0xA6 | Variable | Point-to-point addressed telegrams (bidirectional) |
Key EEPs for building automation
The profiles below cover the majority of EnOcean sensors deployed in commercial building automation. Verify exact TYPE byte from the physical sensor label — temperature range and measurement resolution vary between TYPE variants.
| EEP | Description | Key datapoints | KNX DPT |
|---|---|---|---|
| F6-02-01 | 2-rocker push-button (4 actions) | AI/BI up/down pressed/released | DPT 1.001, 1.008 |
| D5-00-01 | Single contact, door/window | Contact open (1) / closed (0) | DPT 1.009 |
| A5-02-05 | Temperature sensor 0–40°C | Temperature (8-bit, 0.16°C res) | DPT 9.001 |
| A5-04-01 | Temp (0–40°C) + humidity (0–100%) | DB2=temp, DB1=humidity, DB0=LRN bit | DPT 9.001, 9.007 |
| A5-07-01 | Occupancy sensor (PIR, 3-axis) | Occupancy bit + supply voltage | DPT 1.001 |
| A5-06-01 | Illuminance (300–30000 lux) | DB3=lux range, DB2=supply, DB1=lux val | DPT 9.004 |
| A5-12-01 | Automated meter reading (pulse) | DB3–DB1=24-bit pulse count, DB0=divisor | DPT 12.001 |
| A5-09-04 | CO₂ concentration (0–2550 ppm) | DB3=CO₂, DB2=humidity, DB1=temperature | DPT 9.008 |
Manufacturer-specific profiles: MSC (0xD1)
The MSC RORG (0xD1) is reserved for manufacturer-specific datapoints that do not fit within the standardised EEP framework. The payload format is proprietary — only the manufacturer's SDK or decoder library can extract meaningful values from the telegram. MSC telegrams cannot be decoded by generic EnOcean gateways without a manufacturer-provided ETS6 plugin or firmware extension.
MSC profile identification
MSC telegram structure:
Byte 0: 0xD1 (RORG = MSC)
Byte 1: MID high byte (manufacturer ID, 11-bit)
Byte 2: MID low byte
Byte 3–n: Manufacturer-specific payload
Manufacturer IDs (examples):
0x002 = EnOcean GmbH
0x00D = Eltako
0x019 = Siemens
0x028 = Thermokon
Full list: EnOcean Alliance manufacturer registry
When MSC is encountered:
1. Read MID from bytes 1–2
2. Identify manufacturer from EnOcean Alliance registry
3. Obtain manufacturer decoder:
— ETS6 plugin (manufacturer download portal)
— SDK library for custom software integration
— Firmware update for gateway with MSC support
4. Do NOT configure gateway with standard EEP for MSC sensor
— Standard EEP will produce garbage decoded valuesPrefer standard EEP sensors for new installations.MSC sensors create a dependency on a single manufacturer's toolchain. If the ETS6 plugin is discontinued or incompatible with a future ETS version, MSC sensors become undecodable. Standard EEP sensors (A5, D5, F6, D2) are decodable by any EnOcean gateway indefinitely.
EEP decoding tools
Several tools support EnOcean telegram capture and EEP decoding during commissioning, troubleshooting, and system validation.
FT4 Analyzer (EnOcean)
- Free download from EnOcean (Dolphin View)
- Works with EnOcean USB 300 receiver
- Displays raw telegram hex + decoded EEP values
- RSSI measurement per telegram
- EEP assignment for automatic decode
Wireshark + EnOcean plugin
- EnOcean Serial Protocol (ESP3) dissector
- PCAP capture for logging all telegrams
- Useful for density analysis (how many senders active)
- Export to CSV for commissioning records
- Filter by Sender ID or RORG type
EVCC / openHAB / Fhem
- Open-source home automation with EnOcean binding
- Real-time telegram display on screen
- Configurable EEP per sender ID
- Useful for pre-commissioning sensor verification
- Fhem: set enocean learningMode on/off
Dipswitch EEP decoder
- Online tool: enocean-tools.com
- Enter EEP code → see full payload bit map
- Enter raw hex telegram → decoded values
- Useful for verifying scaling formulas
- Covers all EnOcean Alliance published EEPs
EEP database and reference
The complete EEP specification is maintained by the EnOcean Alliance and published as a free PDF document. New EEPs are added with each specification revision as new sensor types enter the market. Always download the latest version when working with sensors whose EEP is not in your gateway's firmware.
EEP reference sources
Official EEP document: EnOcean Alliance EEP specification v3.1 (latest) URL: enocean-alliance.org/enocean-equipment-profiles/ Free registration required for download Published as PDF: ~300 pages, full bit-level specifications Online decoder tool: enocean-tools.com/en/eep-viewer Enter EEP code → interactive bit-field diagram Enter raw telegram hex → decoded value output ETS6 product database (for KNX gateways): Weinzierl: weinzierl.de/en/products (import .knxprod) MDT: mdt.de/ETS_Download.html EEP coverage varies by firmware version Check release notes for newly supported EEPs Community resources: openHAB EnOcean binding documentation Fhem EnoceanBinding wiki Home Assistant enocean integration
Interoperability: the core EEP guarantee
The fundamental value of the EEP framework is manufacturer-independent interoperability. Any EnOcean-certified receiver or gateway can decode any EnOcean-certified sensor that uses a standard published EEP — regardless of which company manufactured either device. This is the key architectural advantage over proprietary RF protocols where sensors and receivers must come from the same vendor.
What EEP guarantees
- Telegram payload bit layout is standardised
- Value scaling (min/max/resolution) is defined
- Unit of measurement is fixed by the spec
- Any certified receiver can decode any certified sender
- Gateways updated via firmware as new EEPs are published
What EEP does not guarantee
- Transmission interval (manufacturer-defined)
- Energy harvesting lifetime (device-specific)
- RF range (antenna design varies by manufacturer)
- Security level (not all sensors use AES-128)
- Sub-datapoint naming (cosmetic variation in UIs)
Practical implication:if a specific sensor model is discontinued, it can be replaced with any other manufacturer's sensor using the same EEP code without reconfiguring the gateway channel — only the sender ID needs updating. This makes EnOcean installations resilient to product lifecycle changes across a 20–30 year building automation system lifetime.
Need EnOcean sensors specified with correct EEP codes for your project?
We select and verify EnOcean sensor EEPs for each application, configure gateway channels with correct DPT mapping, and deliver panels with full EEP documentation — sensor label photos, sender IDs, and group address assignments included.
Request a quote →