Blog · 4. August 2026
Warum bei einem Batteriegerät das Protokoll über die Laufzeit entscheidet
Bei einem Gerät an der Steckdose ist die Wahl des Protokolls eine Frage der Architektur. Bei einem Batteriegerät ist sie eine Frage der Lebensdauer: Dieselben Messwerte, über verschiedene Protokolle verschickt, können den Unterschied zwischen Monaten und Jahren Laufzeit ausmachen. Wir haben ein batteriebetriebenes Sensorgerät über Mobilfunk in Serie gebracht — hier ist, worauf es dabei ankam.
Die Grundregel: Das Funkmodul ist der Verbraucher, nicht der Prozessor
In einem batteriebetriebenen Funkgerät entfällt der größte Teil des Energiebudgets nicht auf das Rechnen, sondern auf die Zeit, in der das Funkmodul sendet, empfängt oder auf Antwort wartet. Jedes Byte, das über die Luft geht, und jede Sekunde, die die Verbindung offen bleibt, kostet Batterie. Ein Protokoll ist deshalb umso besser, je weniger Bytes es um die Nutzdaten herum verschickt und je schneller es wieder Ruhe gibt.
Die drei Kandidaten
| Protokoll | Charakter | Für Batteriegeräte |
|---|---|---|
| HTTP | Anfrage und Antwort über TCP, textbasierte Kopfzeilen | Der teuerste Weg: Verbindungsaufbau, TLS-Aushandlung und geschwätzige Kopfzeilen fallen bei jeder einzelnen Übertragung an. Brauchbar, wenn selten und viel auf einmal übertragen wird |
| MQTT | Leichter Nachrichtenbroker über TCP, Verbindung bleibt stehen | Effizient, wenn die Verbindung gehalten werden kann — die Kopfzeilen je Nachricht sind klein. Aber das Halten selbst kostet: Keep-Alive-Pakete wecken das Funkmodul. Stark, wenn das Gerät auch Befehle empfangen soll |
| CoAP | Für eingeschränkte Geräte entworfen, läuft über UDP | Der sparsamste Weg für kurze Meldungen: kein Verbindungsaufbau, binäre Kopfzeilen von wenigen Bytes, senden und schlafen. Der Preis ist eigene Sorgfalt bei Zustellbestätigung und Sicherheit (DTLS) |
Die ehrliche Antwort auf „welches ist das beste" lautet: Es hängt davon ab, wie Ihr Gerät kommuniziert — wie oft es sendet, wie viel Daten je Meldung, und ob es nur melden oder auch jederzeit erreichbar sein muss. Ein Gerät, das alle zwanzig Minuten drei Messwerte meldet und danach schläft, fährt mit CoAP oder einer kurz aufgebauten MQTT-Sitzung gut. Ein Gerät, das ständig erreichbar sein muss, braucht die stehende Verbindung — und zahlt dafür.
Der unterschätzte Hebel: die Nutzlast selbst
Das Protokoll ist nur die Hälfte der Rechnung. Die andere ist, was verschickt wird. Ein Messwert als JSON — mit Feldnamen, Anführungszeichen und Klammern — ist schnell zehnmal so groß wie derselbe Wert binär kodiert. In der Serie haben wir deshalb Protobuf eingesetzt: Die Felder sind binär und nummeriert statt benannt, und aus einer Meldung von mehreren hundert Bytes JSON werden wenige Dutzend Bytes. Bei zehntausenden Übertragungen im Gerätleben summiert sich das zu Stunden an eingesparter Funkzeit.
Dazu kommt die Transportsicherung: TLS beziehungsweise DTLS gehört auch in ein Batteriegerät — aber die Aushandlung ist teuer, und wer sie bei jeder Übertragung neu bezahlt, verschenkt Laufzeit. Sitzungswiederaufnahme statt Voll-Handshake ist hier der Unterschied, den man im Strommessgerät sieht.
Was wir aus der Serie mitgenommen haben
- Erst das Kommunikationsverhalten festlegen, dann das Protokoll wählen. Wie oft sendet das Gerät, wie viel je Übertragung, und muss es auch empfangen? Die Antwort entscheidet — nicht die Beliebtheit des Protokolls.
- Die Nutzlast binär halten. Der Wechsel von Text auf Protobuf war der größte Einzelgewinn, größer als jeder Protokolltausch.
- Messen statt schätzen. Die Stromaufnahme je Übertragung gehört auf den Tisch — mit einem Batteriesimulator, nicht mit einem Datenblattwert. Die Differenz zwischen Rechnung und Messung war jedes Mal lehrreich.
Und bei Ihnen?
Welches Protokoll fährt Ihr Batteriegerät — und wissen Sie, was eine einzelne Übertragung kostet? Schreiben Sie uns — uns interessiert, wie oft und wie viel Ihre Geräte da draußen wirklich senden.
Transparenzhinweis: Dieser Beitrag wurde mit Unterstützung künstlicher Intelligenz erstellt und vor der Veröffentlichung fachlich geprüft.