MQTT auf LTE offen halten oder für jedes Senden neu verbinden? Wir wollen unsere Datenkosten senken
Von English mit KI übersetzt ·
Wir haben 22 Pumpensteuerungen an Bewässerungsbrunnen, jede mit einem ESP32 und einem SIM7600-LTE-Modem, die SIM-Karten nutzen einen gemeinsamen Tarif mit 500 MB/Monat. Sie senden alle 5 Minuten einen Messwert (Durchfluss, Druck, Pumpenstatus) über MQTT/TLS an Hermetry und halten die Verbindung mit Keepalive 60 offen.Letzten Monat war das Datenvolumen am 24. aufgebraucht. Pro SIM sind das etwa 25 MB/Monat für eigentlich winzige Nutzdaten, etwa 80 Byte JSON alle 5 Minuten. Ein Kollege sagt, „dauerhaft verbunden“ sei das Problem, wir sollten jedes Mal verbinden, veröffentlichen und die Verbindung trennen. Ein anderer meint, das sei wegen TLS schlechter.Wer hat recht? Ich hätte gern Zahlen, falls jemand das gemessen hat. Und wenn wir es ändern: Zeigt Hermetry die Brunnen zwischen den Sendungen als offline an?
We have 22 pump controllers on irrigation wells, each with an ESP32 and a SIM7600 LTE modem, SIMs on a pooled 500 MB/month plan. They send one reading every 5 minutes (flow, pressure, pump state) to Hermetry over MQTT/TLS and keep the connection open with keepalive 60.
Last month the pool ran out on day 24. Per SIM that’s about 25 MB/month for what should be tiny payloads, roughly 80 bytes of JSON every 5 minutes. A colleague says „always connected“ is the problem and we should connect, publish, disconnect every time. Another says that’s worse because of TLS.
Who’s right? I’d like numbers if anyone has measured it. And if we change it, will Hermetry show the wells as offline between sends?
Von English mit KI übersetzt ·
Ihr Kollege #2 hat wahrscheinlich recht. Ein vollständiger TLS-Handshake kostet Kilobytes, ein Keepalive-Ping ist winzig.
Your colleague #2 is probably right. A full TLS handshake costs kilobytes, a keepalive ping is tiny.
Von English mit KI übersetzt ·
Ich habe das letztes Jahr an unseren Anhänger-Trackern gemessen, weil unsere Mobilfunkrechnung absurd war. Grobe Werte aus Paketmitschnitten auf einem SIM7600, TLS 1.2, dem Broker der Plattform:
- vollständige Neuverbindung (TCP- + TLS-Handshake mit Zertifikatskette + CONNECT + SUBSCRIBEs): etwa 5 bis 6 KB
- ein Keepalive-Roundtrip (PINGREQ/PINGRESP innerhalb von TLS, dazu TCP/IP-Header und ACKs): ungefähr 150 bis 200 Byte
- Ihr 80-Byte-Messwert als QoS-1-Publish innerhalb von TLS mit PUBACK: ebenfalls ein paar hundert Byte
Eine Neuverbindung alle 5 Minuten würde also etwa 8.640 Handshakes im Monat kosten, 45+ MB. Deutlich schlechter. Keepalive 60 ergibt 43.200 Pings im Monat, rund 8 MB. Das ist ein großer Teil Ihrer 25 MB.Was bei uns funktioniert hat:Keepalive bis 300 s (der Broker setzt alles darüber ohnehin auf 300). Das reduziert die Pings auf ein Fünftel. Prüfen Sie, ob Ihr Provider inaktive NAT-Sitzungen nicht schneller trennt; bei uns hielten 6 Minuten, bei manchen werden sie nach 2 bis 4 Minuten getrennt. Wenn Sie keepalive_timeout im Log-Tab des Geräts sehen, senken Sie den Wert.Batching. Statt alle 5 Minuten einen Publish zu senden, puffern Sie 3 Messwerte und senden sie als ein Array mit Zeitstempeln (der ESP32 hat NTP, daher ist ts unproblematisch):
[{"ts":1762336800000,"values":{"flow":12.1,"pressure":2.4,"pump":1}},
{"ts":1762337100000,"values":{"flow":12.3,"pressure":2.4,"pump":1}},
{"ts":1762337400000,"values":{"flow":11.9,"pressure":2.3,"pump":1}}]
Gleiche Daten, ein Publish, und es zählt zudem als eine Nachricht auf das Monatskontingent statt drei.Suchen Sie nach unnötigem Datenverkehr. Bei uns war das Schlimmste, dass die Firmware bei jedem Publish Client-Attribute (IP, RSSI, Firmware-Version) mitgeschickt hat. Senden Sie diese nur bei Änderung.Zum Offline-Status: Mit Live connection als Online-Regel bleiben die Geräte online, solange die MQTT-Sitzung offen ist, bei Keepalive 300 ändert sich also nichts. Falls Sie jemals auf Verbinden-Senden-Trennen umstellen, wechseln Sie zu einem Profil mit Recent message, sonst werden sie zwischen den Sendungen als offline angezeigt.
I measured this on our trailer trackers last year because our carrier bill was silly. Rough numbers from packet captures on a SIM7600, TLS 1.2, the platform’s broker:
- full reconnect (TCP + TLS handshake with certificate chain + CONNECT + SUBSCRIBEs): about 5 to 6 KB
- one keepalive round trip (PINGREQ/PINGRESP inside TLS, plus TCP/IP headers and ACKs): roughly 150 to 200 bytes
- your 80-byte reading as a QoS 1 publish inside TLS with PUBACK: also a couple of hundred bytes
So reconnecting every 5 minutes would cost about 8,640 handshakes a month, 45+ MB. Way worse. Keepalive 60 is 43,200 pings a month, around 8 MB. That’s a big chunk of your 25 MB.
What worked for us:
Keepalive up to 300 s (the broker serves anything above its maximum at 300 anyway). That cuts pings by five. Check your carrier doesn’t drop idle NAT sessions faster; ours held 6 minutes, some drop at 2 to 4. If you see keepalive_timeout in the device’s Log tab, step it down.
Batch. Instead of one publish every 5 minutes, buffer 3 readings and send them as one array with timestamps (ESP32 has NTP, so ts is fine):
[{"ts":1762336800000,"values":{"flow":12.1,"pressure":2.4,"pump":1}},
{"ts":1762337100000,"values":{"flow":12.3,"pressure":2.4,"pump":1}},
{"ts":1762337400000,"values":{"flow":11.9,"pressure":2.3,"pump":1}}]
Same data, one publish, and it also counts as one message against the monthly quota instead of three.
Look for chatty extras. In our case the worst was the firmware sending client attributes (IP, RSSI, firmware version) on every publish. Only send them on change.
On offline: with Live connection as the online rule they stay online as long as the MQTT session is open, so with keepalive 300 nothing changes. If you ever do go connect-send-disconnect, switch them to a profile with Recent message, otherwise they’d show offline between sends.
Von English mit KI übersetzt ·
Nach zwei Wochen liegen die Zahlen vor. Keepalive 300 (unser Anbieter hat damit kein Problem, keine Timeouts im Log-Tab), Batches zu je 3, Attribute nur bei Änderung. Hochgerechnet ~9 MB pro SIM und Monat, nach zuvor 25. Überraschend war der Attribut-Verkehr: Unsere Firmware veröffentlichte lan.ip und cell.rssi bei jeder Messung als Attribute. rssi verschieben wir jetzt alle 15 Minuten in die Telemetrie. Danke, Kevin, diese Messungen haben mir eine Woche Arbeit erspart.
Numbers are in after two weeks. Keepalive 300 (our carrier is fine with it, no timeouts in the Log tab), batches of 3, attributes only on change. Projected ~9 MB per SIM per month, down from 25. The attribute chatter was the surprise: our firmware was publishing lan.ip and cell.rssi as attributes with every reading. Moved rssi into telemetry every 15 minutes instead. Thanks Kevin, those measurements saved me a week.
Von English mit KI übersetzt ·
Gut. Falls die Pumpen jemals Befehle benötigen, bedenkt: Ein über 15 Minuten gebündelter Messwert verzögert diese nicht, sie kommen über die offene Sitzung.
Nice. If the pumps ever need commands, keep in mind a reading batched for 15 minutes doesn’t delay those, they come down the open session.
- Du musst angemeldet sein, um auf dieses Thema antworten zu können.
Mitdiskutieren
Melde dich an, um Fragen zu stellen und zu beantworten, hilfreiche Beiträge mit „Gefällt mir“ zu markieren und die Antwort zu kennzeichnen, die dein Problem gelöst hat. Jeder Beitrag bringt Punkte und Stufen.

