Traducido del English por IA ·
Tenemos 22 controladores de bombas en pozos de riego, cada uno con un ESP32 y un módem LTE SIM7600, con SIM en un plan compartido de 500 MB/mes. Envían una lectura cada 5 minutos (caudal, presión, estado de la bomba) a Hermetry por MQTT/TLS y mantienen la conexión abierta con keepalive 60.El mes pasado el plan se agotó el día 24. Por SIM son unos 25 MB/mes para cargas que deberían ser muy pequeñas, unos 80 bytes de JSON cada 5 minutos. Un compañero dice que el problema es «estar siempre conectado» y que deberíamos conectar, publicar y desconectar cada vez. Otro dice que eso es peor por culpa de TLS.¿Quién tiene razón? Me gustaría ver números si alguien lo ha medido. Y si cambiamos, ¿Hermetry mostrará los pozos como desconectados entre envíos?
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?
Traducido del English por IA ·
Tu compañero #2 probablemente tiene razón. Un handshake TLS completo consume kilobytes, un ping keepalive es muy pequeño.
Your colleague #2 is probably right. A full TLS handshake costs kilobytes, a keepalive ping is tiny.
Traducido del English por IA ·
Lo medí el año pasado en nuestros rastreadores de remolques, porque la factura de la operadora era absurda. Cifras aproximadas a partir de capturas de paquetes con un SIM7600, TLS 1.2 y el broker de la plataforma:
- reconexión completa (handshake TCP + TLS con cadena de certificados + CONNECT + SUBSCRIBEs): unos 5 a 6 KB
- un ida y vuelta de keepalive (PINGREQ/PINGRESP dentro de TLS, más cabeceras TCP/IP y ACKs): entre 150 y 200 bytes aproximadamente
- su lectura de 80 bytes como publicación QoS 1 dentro de TLS con PUBACK: también un par de cientos de bytes
Así que reconectar cada 5 minutos costaría unos 8.640 handshakes al mes, más de 45 MB. Mucho peor. Un keepalive de 60 son 43.200 pings al mes, unos 8 MB. Eso es una parte importante de sus 25 MB.Lo que nos funcionó:Keepalive de hasta 300 s (el broker sirve cualquier valor por encima de su máximo como 300 de todos modos). Eso reduce los pings a una quinta parte. Compruebe que su operadora no cierra las sesiones NAT inactivas más rápido; las nuestras aguantaban 6 minutos, algunas se cierran a los 2 o 4. Si ve keepalive_timeout en la pestaña Log del dispositivo, bájelo.Agrupar. En lugar de una publicación cada 5 minutos, almacene 3 lecturas y envíelas como un único array con marcas de tiempo (el ESP32 tiene NTP, así que ts es válido):
[{"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}}]Los mismos datos, una sola publicación, y además cuenta como un mensaje frente a la cuota mensual en lugar de tres.Busque extras que generen tráfico innecesario. En nuestro caso lo peor era que el firmware enviaba atributos de cliente (IP, RSSI, versión de firmware) en cada publicación. Envíelos solo cuando cambien.Sobre el estado sin conexión: con Live connection como regla de conexión, los dispositivos permanecen en línea mientras la sesión MQTT esté abierta, así que con keepalive 300 no cambia nada. Si alguna vez pasa al esquema conectar-enviar-desconectar, cámbielos a un perfil con Recent message; de lo contrario, aparecerán como desconectados entre envíos.
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.
Traducido del English por IA ·
Los números ya están listos tras dos semanas. Keepalive 300 (nuestro operador no tiene problema con ello, sin timeouts en la pestaña Log), lotes de 3, atributos solo cuando cambian. Proyección de ~9 MB por SIM al mes, frente a los 25 anteriores. La sorpresa fue el tráfico de atributos: nuestro firmware publicaba lan.ip y cell.rssi como atributos con cada lectura. Pasamos rssi a telemetría cada 15 minutos. Gracias Kevin, estas mediciones me ahorraron una semana.
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.
Traducido del English por IA ·
Genial. Si alguna vez las bombas necesitan comandos, ten en cuenta que una lectura agrupada durante 15 minutos no los retrasa, llegan por la sesión abierta.
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.
- Debes estar registrado para responder a este debate.
Únete a la conversación
Inicia sesión para preguntar y responder, dar me gusta a las publicaciones útiles y marcar la respuesta que resolvió tu problema. Cada aportación suma puntos y niveles.