EEP · RORG · 4BS A5 · RPS F6 · 1BS D5 · VLD D2 · EnOcean Alliance · 8 Min. Lesezeit

EnOcean Equipment Profiles (EEP): Verständnis der A5-, D5- und F6-Profilfamilien

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-Struktur: RORG-FUNC-TYPE

Jeder EEP-Code besteht aus drei Bytes, die hexadezimal dargestellt und als durch Bindestriche getrenntes Triplett geschrieben werden. Jedes Byte hat eine eigene Bedeutung:

EEP-Byte-Struktur

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 wird in normalen Datentelegrammen nicht übertragen. Das RORG-Byte ist im Telegramm-Header eingebettet (es ist der Telegrammtyp-Identifikator), aber FUNC und TYPE werden in regulären Datentelegrammen nicht gesendet. Sie werden nur während der Teach-in-Sequenz übertragen. Aus diesem Grund müssen Gateways für jeden Sensorkanal die EEP manuell konfigurieren oder während des Teach-ins erfassen.

Übersicht der RORG-Familien

Das RORG-Byte bestimmt die Telegrammstruktur. Die meisten Gebäudeautomationssensoren verwenden 4BS (0xA5) für Mehrwertmessungen und RPS (0xF6) für Wippschalter. VLD (0xD2) wird für Aktoren und Geräte mit bidirektionaler Kommunikation verwendet.

RORGHexNutzlastTypische Verwendung
1BS (1-Byte-Sensor)0xD51 Byte (8 Bit)Tür-/Fensterkontakt, einfacher Binärsensor
4BS (4-Byte-Sensor)0xA54 Bytes (32 Bit)Temperatur, Luftfeuchtigkeit, Anwesenheit, Beleuchtungsstärke, Energiezähler
RPS (Repeated Switch)0xF61 Byte (8 Bit)Wippschalter, Drucktaster, Fenstergriffstellung
VLD (Variable Length Data)0xD21–14 BytesAktoren, bidirektionale Geräte, HVAC-Ventile
MSC (Herstellerspezifisch)0xD1VariabelProprietäre Datenpunkte, erfordert Hersteller-Decoder
ADT (Adressierungsziel)0xA6VariabelPunkt-zu-Punkt adressierte Telegramme (bidirektional)

Wichtige EEPs für die Gebäudeautomation

Die folgenden Profile decken die meisten EnOcean-Sensoren ab, die in der kommerziellen Gebäudeautomation eingesetzt werden. Überprüfen Sie das genaue TYPE-Byte auf dem physischen Sensorlabel – Temperaturbereich und Messauflösung variieren je nach TYPE-Variante.

EEPBeschreibungWichtige DatenpunkteKNX DPT
F6-02-012-Wippen-Taster (4 Aktionen)AI/BI auf/ab gedrückt/losgelassenDPT 1.001, 1.008
D5-00-01Einzelkontakt, Tür/FensterKontakt offen (1) / geschlossen (0)DPT 1.009
A5-02-05Temperatursensor 0–40°CTemperatur (8-Bit, 0,16°C Auflösung)DPT 9.001
A5-04-01Temp (0–40°C) + Feuchte (0–100%)DB2=Temp, DB1=Feuchte, DB0=LRN-BitDPT 9.001, 9.007
A5-07-01Präsenzmelder (PIR, 3-Achsen)Präsenzbit + VersorgungsspannungDPT 1.001
A5-06-01Beleuchtungsstärke (300–30000 Lux)DB3=Luxbereich, DB2=Versorgung, DB1=LuxwertDPT 9.004
A5-12-01Automatische Zählerstandsablesung (Impuls)DB3–DB1=24-Bit-Impulszähler, DB0=TeilerDPT 12.001
A5-09-04CO₂-Konzentration (0–2550 ppm)DB3=CO₂, DB2=Feuchte, DB1=TemperaturDPT 9.008

Herstellerspezifische Profile: 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-Profilidentifikation

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 values

Für Neuinstallationen Standard-EEP-Sensoren bevorzugen.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-Decodierungswerkzeuge

Mehrere Werkzeuge unterstützen die Erfassung von EnOcean-Telegrammen und die EEP-Decodierung während der Inbetriebnahme, Fehlersuche und Systemvalidierung.

FT4 Analyzer (EnOcean)

  • Kostenloser Download von EnOcean (Dolphin View)
  • Funktioniert mit EnOcean USB 300 Empfänger
  • Zeigt rohes Telegramm Hex + dekodierte EEP-Werte an
  • RSSI-Messung pro Telegramm
  • EEP-Zuordnung für automatische Dekodierung

Wireshark + EnOcean Plugin

  • EnOcean Serial Protocol (ESP3) Dissector
  • PCAP-Erfassung zur Protokollierung aller Telegramme
  • Nützlich für die Dichteanalyse (wie viele Sender aktiv sind)
  • Export nach CSV für Inbetriebnahmeprotokolle
  • Filter nach Sender-ID oder RORG-Typ

EVCC / openHAB / Fhem

  • Open-Source-Hausautomation mit EnOcean-Bindung
  • Echtzeit-Telegrammanzeige auf dem Bildschirm
  • Konfigurierbarer EEP pro Sender-ID
  • Nützlich für die Sensorüberprüfung vor der Inbetriebnahme
  • Fhem: set enocean learningMode on/off

DIP-Schalter EEP-Decoder

  • Online-Tool: enocean-tools.com
  • EEP-Code eingeben → vollständige Nutzlast-Bitmap anzeigen
  • Rohes Hex-Telegramm eingeben → decodierte Werte
  • Nützlich zur Überprüfung von Skalierungsformeln
  • Deckt alle von der EnOcean Alliance veröffentlichten EEPs ab

EEP-Datenbank und Referenz

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-Referenzquellen

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

Interoperabilität: die Kern-Garantie von EEP

Der grundlegende Wert des EEP-Rahmenwerks ist die herstellerunabhängige Interoperabilität. Jedes EnOcean-zertifizierte Empfangsgerät oder Gateway kann jeden EnOcean-zertifizierten Sensor decodieren, der ein standardmäßig veröffentlichtes EEP verwendet – unabhängig davon, welches Unternehmen das jeweilige Gerät hergestellt hat. Dies ist der entscheidende architektonische Vorteil gegenüber proprietären HF-Protokollen, bei denen Sensoren und Empfänger vom selben Anbieter stammen müssen.

Was EEP garantiert

  • Das Bit-Layout der Telegrammnutzdaten ist standardisiert
  • Wertskalierung (Min/Max/Auflösung) ist definiert
  • Maßeinheit ist durch die Spezifikation festgelegt
  • Jeder zertifizierte Empfänger kann jeden zertifizierten Sender decodieren
  • Gateways werden per Firmware aktualisiert, sobald neue EEPs veröffentlicht werden

Was EEP nicht garantiert

  • Übertragungsintervall (herstellerdefiniert)
  • Energy-Harvesting-Lebensdauer (gerätespezifisch)
  • RF-Reichweite (Antennendesign variiert je nach Hersteller)
  • Sicherheitsstufe (nicht alle Sensoren verwenden AES-128)
  • Sub-Datenpunkt-Benennung (kosmetische Variation in Benutzeroberflächen)

Praktische Auswirkung: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.

Benötigen Sie für Ihr Projekt EnOcean-Sensoren mit korrekten EEP-Codes?

Wir wählen und verifizieren EnOcean-Sensor-EEPs für jede Anwendung, konfigurieren Gateway-Kanäle mit korrektem DPT-Mapping und liefern Schaltschränke mit vollständiger EEP-Dokumentation – inklusive Fotos der Sensor-Etiketten, Sender-IDs und Gruppenadresszuweisungen.

Angebot anfordern →
Lade ...
Zum Seitenanfang