Shelly BLU fcd2-Pakete verstehen: So kommst du von BLE-Daten zu echten Messwerten
Bluetooth-basierte Shelly BLU-Geräte wie H&T, Motion oder Door/Window senden ihre Sensordaten nicht über WLAN, sondern über BLE-Broadcasts. Wer die Daten später über ein eigenes Gateway – z. B. ESP32 oder Shelly Gateway/Plug S – in eine Datenbank übertragen möchte, muss zunächst verstehen, wie diese BLE-Pakete aufgebaut sind.
Ein zentrales Element dabei ist die Kennung fcd2.
In diesem Beitrag zeige ich, was sich dahinter verbirgt, wie der Payload aussieht und wie du Temperatur- und Feuchtigkeitswerte aus den Bytes extrahierst.
Warum das fcd2-Paket wichtig ist
Im BLE-Advertising stehen nicht nur „Wer bin ich?“-Informationen, sondern auch direkt die Sensordaten. Shelly nutzt für diese Informationen ein eigenes Service-Kennzeichen:
UUID 0xFCD2
Sobald ein Gerät diese UUID aussendet, weiß man:
Das folgende Datenpaket enthält Shelly-BLU-Sensordaten.
Gerade wenn du die Werte später über HTTP/POST an eine eigene MySQL-Datenbank sendest, ist es entscheidend, die fcd2-Payload korrekt umzuwandeln.
Was bedeutet fcd2?
fcd2 ist eine 16-Bit Bluetooth Service-UUID, die exklusiv zur Identifikation der Shelly BLU-Service-Daten genutzt wird.
Ein BLE-Advertising-Paket enthält dann z. B.:
03 03 d2 fc # UUID-Liste (0xFCD2)
17 16 d2 fc [Payload…] # Shelly Service Data mit Sensor-Payload
Der entscheidende Teil ist:
16 d2 fc [Payload]
Hier beginnt die eigentliche Shelly-Datenstruktur.
Aufbau der fcd2-Payload
Shelly verwendet ein kompaktes binäres Format, das unabhängig vom Gerät identisch strukturiert ist.
Typischer Aufbau:
Byte Bedeutung
0 Protokollversion + Flags
1 Device Type (z. B. H&T = 0x03)
2–n Sensordaten (Key/Value-Blöcke)
Für den Shelly BLU H&T sieht ein reales Beispiel so aus:
41 03 01 64 02 0f a0
Aufschlüsselung:
Byte(s) Bedeutung
41 Version/Flags
03 Device Type (H&T)
01 64 Temperatur
02 0f a0 Feuchtigkeit
Temperatur und Feuchte dekodieren
Temperatur
Shelly kodiert die Temperatur als Integer mit Faktor 0,1.
Beispiel: 01 64 –> Hex 0x0164 = Dezimal 356 –> 356 / 10 = 35,6 °C
Feuchtigkeit
Die Luftfeuchtigkeit wird als Integer mit Faktor 0,01 übertragen.
Beispiel: 0f a0 –> Hex 0x0FA0 = Dezimal 4000 –> 4000 / 100 = 40,00 %
Übersicht in Tabellenform:
| Feld | Bytes | Rohwert | Skalierung | Ergebnis |
|---|---|---|---|---|
| Temperatur | 0164 | 356 | / 10 | 35,6 °C |
| Luftfeuchtigkeit | 02 0f a0 | 4000 | / 100 | 40,00 % |
Beispiel: Dekodierung im eigenen Gateway (ESP32 oder Shelly Plug)
Für eigene Projekte genügt ein kleiner Umrechner.
Temperatur
float decodeTemperature(uint8_t high, uint8_t low) {
int16_t raw = (high << 8) | low;
return raw / 10.0;
}
Feuchte
float decodeHumidity(uint8_t high, uint8_t low) {
uint16_t raw = (high << 8) | low;
return raw / 100.0;
}
Nach der Dekodierung kannst du die Werte gezielt als HTTP-Request an deinen Webserver schicken und dort in PHP/MySQL weiterverarbeiten – genau wie bei deinen anderen Sensornodes.
Allerdings ist es auch möglich die Ressourcen des Shelly zu schonen und den Payload einfach zu senden. Die Dekodierung muss dann der Server im PHP-Skript übernehmen.
Einordnung in ein Gesamtsystem
Der Weg vom BLU-Sensor bis in eine Datenbank sieht typischerweise so aus:
BLU Sensor sendet BLE-Advertising mit fcd2.
Ein Shelly Plug oder ESP32 empfängt das Advertising.
Die fcd2-Payload wird dekodiert.
Die umgerechneten Werte (z. B. 23.7 °C, 41.2 % rF) werden per HTTP/POST weitergeleitet.
PHP nimmt die Daten an und speichert sie in MySQL.
Dieser Aufbau ermöglicht eine komplett cloudfreie Lösung, da weder Shelly-Cloud noch Bluetooth-Pairing erforderlich sind.
Fazit
fcd2 ist die Service-UUID, unter der Shelly BLU seine Sensordaten im BLE-Advertising sendet.
Temperatur und Feuchte sind Integerwerte mit festen Skalierungsfaktoren.
Mit wenigen Zeilen Code lassen sich die Rohwerte dekodieren und wie gewohnt an deinen Webserver weiterleiten.
Das Verfahren eignet sich ideal als Ergänzung zu bestehenden HTTP- und Datenbankprojekten.