Nach dem Empfang eines EnOcean-Telegramms ist der Dateninhalt zu interpretieren, der Aufbau eines Telegramms muss daher genau bekannt sein. Das EnOcean Radio Protocol 1 beschreibt die Bit-Übertragung. Wichtiger ist jedoch das EnOcean Serial Protocol 3 (ESP3), das die Kommunikation zwischen Hosts und EnOcean-Empfangsmodulen definiert, was für den Empfang von Telegrammen relevant ist. Das ESP beschreibt die Kommunikation zwischen einem EnOcean-Empfangsmodul und einem Host über eine UART-Schnittstelle. Bei der Kommunikation werden Datenpakete gesendet, die eine feste Struktur aufweisen (Bild 3). Die Nutzdaten, etwa Messwerte eines Sensorknotens, werden vom Sender in diese Struktur eingebettet.
Ein Paket beginnt stets mit einem Synchronisationsbyte (0x55h). Wird dieser Wert aus der UART-Schnittstelle gelesen, könnte es sich um den Beginn eines Paketes handeln. Um sicher zu gehen, wird eine zyklische Redundanzprüfung auf den Header angewendet und das Ergebnis mit dem Prüfbyte CRC8H verglichen. Bei einer Übereinstimmung handelt es sich bei dem Wert tatsächlich um das Synchronisationsbyte, woraufhin der Empfang eines neuen Paketes beginnt.
Der Header besteht immer aus drei Feldern, die zusammen vier Byte lang sind. Diese Felder enthalten die Länge der Daten, die Länge der optionalen Daten und den Pakettyp. Da die Anzahl an Bytes bei den Daten und den optionalen Daten variabel ist, findet sich die Länge dieser Daten im Header. Das Feld für die Länge der Daten ist zwei Byte, und die anderen beiden Felder sind jeweils ein Byte groß. Mit den Informationen aus dem Header wird die gesamte Länge des Paketes berechnet. Diese beträgt grundsätzlich 7 + Länge der Daten + Länge der optionalen Daten.
Die Felder CRC8H und CRC8D sind Prüfbytes, die vor der Übertragung mit der zyklischen Redundanzprüfung berechnet wurden. Das Prüfbyte CRC8H wird dabei aus den vier Byte des Headers und CRC8D aus den Bytes der Daten und der optionalen Daten berechnet.
Der Pakettyp im Header gibt an, um welche Art von Paket es sich handelt. Für Messdaten ist der Pakettyp RADIO_ERP1 von Bedeutung. Andere Pakettypen sind für Kommandos (COMMON_COMMAND), Ereignisse (EVENT) oder Antworten (RESPONSE) vorgesehen. Die Struktur der Daten und der optionalen Daten wird vom Pakettyp vorgegeben, was folgend anhand des Typs RADIO_ERP1 erläutert wird. Die Daten bestehen aus vier Feldern (Bild 4). Das ein Byte lange Feld R-ORG gibt den Datentyp der Nutzdaten an. Die gebräuchlichsten Datentypen sind RPS (Repeated Switch Communication), 1BS (1 Byte Communication), 4BS (4 Byte Communication) und VLD (Variable Length Data). Diese Datentypen unterscheiden sich lediglich in der Länge der eingebetteten Nutzdaten, die eine Länge von einem bis zu maximal 14 Byte aufweisen können. Alle Adressen zur Identifizierung sind vier Byte lang und für jedes Gerät einzigartig. In Bild 5 ist als Beispiel das Telegramm eines PTM210-Schaltmoduls dargestellt.
Neben den Nutzdaten enthalten empfangene Telegramme zwar auch Informationen über den Absender, jedoch lassen sich aus den Daten keinerlei Rückschlüsse auf deren Interpretation ziehen. Die 32 bit lange Adresse eines jeden Senders ist einzigartig, sodass man den Sender eindeutig identifizieren kann. Für die Gerätebestimmung pflegt EnOcean mit den Partnerfirmen eine Liste ausgewählter Geräte in Form von Profilen, den EnOcean Equipment Profiles (EEP). Diese Profile decken die Anwendungsschicht im OSI-Modell ab, während die unteren drei OSI-Schichten (Physical, Data Link, Network) dem ISO/IEC-Standard (14543-3-10) gehorchen.
Die EEP wird als PDF-, aber auch als XML-Datei zur Verfügung gestellt, sodass sich diese Daten in einer Anwendung leicht integrieren lassen. Mithilfe der EnOcean-Visualisierungssoftware DolphinView Basic (Bild 6) können Anwender (neuen) Geräten, die anhand ihre eindeutigen Adresse identifiziert werden, ein Profil zuweisen.