Yapay zekâ tarafından English dilinden çevrildi ·
Sulama kuyularında her biri ESP32 ve SIM7600 LTE modemi olan 22 pompa kontrolcümüz var; SIM’ler ortak 500 MB/ay pakette. Her 5 dakikada bir okuma (debi, basınç, pompa durumu) gönderiyorlar; MQTT/TLS üzerinden Hermetry’ye bağlanıyorlar ve bağlantıyı keepalive 60 ile açık tutuyorlar.Geçen ay havuz 24. günde tükendi. SIM başına bu, çok küçük olması gereken yükler için yaklaşık 25 MB/ay demek; kabaca her 5 dakikada 80 bayt JSON. Bir iş arkadaşım “sürekli bağlı olmak” sorun ve her seferinde bağlan, yayınla, bağlantıyı kes yapmalıyız diyor. Bir diğeri ise TLS yüzünden bunun daha kötü olacağını söylüyor.Kim haklı? Bunu ölçen olduysa sayıları görmek isterim. Bir de değişiklik yaparsak Hermetry kuyuları gönderimler arasında çevrimdışı olarak gösterecek mi?
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?
Yapay zekâ tarafından English dilinden çevrildi ·
Meslektaşınız #2 muhtemelen haklı. Tam bir TLS el sıkışması kilobaytlarca veri harcar, keepalive ping’i ise çok küçüktür.
Your colleague #2 is probably right. A full TLS handshake costs kilobytes, a keepalive ping is tiny.
Yapay zekâ tarafından English dilinden çevrildi ·
Bunu geçen yıl römork takip cihazlarımızda ölçtüm, çünkü operatör faturamız çok saçmaydı. SIM7600 üzerinde, TLS 1.2 ile platformun broker’ı kullanılarak paket yakalamalarından alınan kaba değerler:
- tam yeniden bağlantı (TCP + sertifika zincirli TLS el sıkışması + CONNECT + SUBSCRIBE’lar): yaklaşık 5 ila 6 KB
- bir keepalive gidiş-dönüşü (TLS içinde PINGREQ/PINGRESP, artı TCP/IP başlıkları ve ACK’ler): yaklaşık 150 ila 200 bayt
- 80 baytlık okumanız, TLS içinde PUBACK ile QoS 1 publish olarak: yine birkaç yüz bayt
Yani her 5 dakikada bir yeniden bağlanmak ayda yaklaşık 8.640 el sıkışma, 45+ MB demek. Çok daha kötü. Keepalive 60 ayda 43.200 ping, yaklaşık 8 MB demek. Bu, 25 MB’lik kotanızın büyük bir kısmı.Bizde işe yarayan yöntem:Keepalive’ı 300 s’ye kadar çıkarın (broker, maksimumunun üzerindeki değerleri zaten 300 olarak kabul ediyor). Bu, ping sayısını beşte bire indirir. Operatörünüzün boşta kalan NAT oturumlarını daha hızlı düşürmediğini kontrol edin; bizimki 6 dakika tuttu, bazıları 2 ila 4 dakikada düşürüyor. Cihazın Log sekmesinde keepalive_timeout görürseniz değeri aşağı çekin.Toplu gönderim. Her 5 dakikada bir publish yerine, 3 okumayı tamponlayın ve zaman damgalarıyla tek bir dizi olarak gönderin (ESP32’de NTP var, bu yüzden ts kullanmak sorunsuz):
[{"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}}]Veri aynı, tek publish, ayrıca aylık kotaya üç mesaj yerine tek mesaj olarak sayılır.Gereksiz trafik kaynaklarına bakın. Bizde en kötüsü, firmware’in her publish’te istemci özniteliklerini (IP, RSSI, firmware sürümü) göndermesiydi. Bunları yalnızca değiştiğinde gönderin.Çevrimdışı durumu hakkında: Çevrimiçi kuralı olarak Live connection kullanıldığında, MQTT oturumu açık olduğu sürece cihazlar çevrimiçi kalır; dolayısıyla keepalive 300 iken hiçbir şey değişmez. Eğer bağlan-gönder-bağlantıyı kes yöntemine geçerseniz, cihazları Recent message olan bir profile geçirin; aksi halde gönderimler arasında çevrimdışı görünürler.
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.
Yapay zekâ tarafından English dilinden çevrildi ·
İki haftanın sonuçları geldi. Keepalive 300 (taşıyıcımız buna sorun çıkarmıyor, Log sekmesinde zaman aşımı yok), 3’lü gruplar halinde gönderim, öznitelikler yalnızca değiştiğinde. SIM başına aylık tahmini ~9 MB, önceki 25 MB’dan düştü. Sürpriz, öznitelik trafiğiydi: firmware’imiz her okumayla birlikte lan.ip ve cell.rssi değerlerini öznitelik olarak yayınlıyordu. rssi’yi bunun yerine her 15 dakikada bir telemetri olarak taşıdık. Kevin, teşekkürler; bu ölçümler bana bir haftalık iş kazandırdı.
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.
Yapay zekâ tarafından English dilinden çevrildi ·
Güzel. Pompaların bir ara komut alması gerekirse, 15 dakikada toplu gönderilen bir okumanın bunları geciktirmeyeceğini aklınızda tutun; komutlar açık oturum üzerinden gelir.
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.
- Bu konuyu yanıtlamak için giriş yapmış olmalısınız.
Sohbete katılın
Soru sormak ve yanıtlamak, yararlı gönderileri beğenmek ve sorununuzu çözen yanıtı işaretlemek için oturum açın. Her katkı puan ve seviye kazandırır.