Traduit de English par IA ·
Nous avons 22 contrôleurs de pompes sur des puits d’irrigation, chacun avec un ESP32 et un modem LTE SIM7600, avec des SIM sur un forfait mutualisé de 500 Mo/mois. Ils envoient une mesure toutes les 5 minutes (débit, pression, état de la pompe) à Hermetry via MQTT/TLS et gardent la connexion ouverte avec un keepalive de 60.Le mois dernier, le forfait s’est épuisé le 24. Par SIM, cela représente environ 25 Mo/mois pour des charges utiles qui devraient être minuscules, soit environ 80 octets de JSON toutes les 5 minutes. Un collègue affirme que « rester connecté en permanence » est le problème et qu’il faut se connecter, publier, puis se déconnecter à chaque fois. Un autre dit que c’est pire à cause de TLS.Qui a raison ? J’aimerais des chiffres si quelqu’un a mesuré. Et si nous changeons, Hermetry affichera-t-il les puits comme hors ligne entre les envois ?
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?
Traduit de English par IA ·
Votre collègue #2 a probablement raison. Un handshake TLS complet coûte des kilo-octets, un ping keepalive est minuscule.
Your colleague #2 is probably right. A full TLS handshake costs kilobytes, a keepalive ping is tiny.
Traduit de English par IA ·
J’ai mesuré cela l’an dernier sur nos trackers de remorques, parce que notre facture d’opérateur était absurde. Chiffres approximatifs issus de captures de paquets sur un SIM7600, TLS 1.2, le broker de la plateforme :
- reconnexion complète (poignée de main TCP + TLS avec chaîne de certificats + CONNECT + SUBSCRIBEs) : environ 5 à 6 Ko
- un aller-retour keepalive (PINGREQ/PINGRESP dans TLS, plus en-têtes TCP/IP et ACK) : environ 150 à 200 octets
- votre relevé de 80 octets sous forme de publish QoS 1 dans TLS avec PUBACK : également quelques centaines d’octets
Donc se reconnecter toutes les 5 minutes coûterait environ 8 640 poignées de main par mois, soit plus de 45 Mo. Bien pire. Un keepalive de 60 représente 43 200 pings par mois, environ 8 Mo. C’est une grosse part de vos 25 Mo.Ce qui a fonctionné chez nous :Keepalive jusqu’à 300 s (le broker ramène de toute façon toute valeur supérieure à son maximum, soit 300). Cela divise les pings par cinq. Vérifiez que votre opérateur ne coupe pas les sessions NAT inactives plus vite ; chez nous elles tenaient 6 minutes, certaines coupent entre 2 et 4 minutes. Si vous voyez keepalive_timeout dans l’onglet Log de l’appareil, réduisez la valeur.Regroupement. Au lieu d’un publish toutes les 5 minutes, mettez en tampon 3 relevés et envoyez-les dans un seul tableau avec horodatages (l’ESP32 dispose de NTP, donc ts convient) :
[{"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}}]Mêmes données, un seul publish, et cela ne compte qu’un message sur le quota mensuel au lieu de trois.Repérez les éléments superflus. Chez nous, le pire était que le firmware envoyait les attributs client (IP, RSSI, version du firmware) à chaque publish. Ne les envoyez qu’en cas de changement.Concernant le statut hors ligne : avec Live connection comme règle de connexion, les appareils restent en ligne tant que la session MQTT est ouverte, donc avec un keepalive de 300 rien ne change. Si vous passez un jour en mode connexion-envoi-déconnexion, basculez-les vers un profil avec Recent message, sinon ils apparaîtront hors ligne entre les envois.
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.
Traduit de English par IA ·
Les chiffres sont disponibles après deux semaines. Keepalive 300 (notre opérateur n’a aucun problème avec cela, aucun timeout dans l’onglet Log), lots de 3, attributs uniquement en cas de changement. Projection d’environ 9 Mo par SIM et par mois, contre 25 auparavant. La surprise venait du trafic d’attributs : notre firmware publiait lan.ip et cell.rssi comme attributs à chaque mesure. Nous avons déplacé rssi vers la télémétrie toutes les 15 minutes. Merci Kevin, ces mesures m’ont fait gagner une semaine.
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.
Traduit de English par IA ·
Bien. Si les pompes doivent un jour recevoir des commandes, gardez à l’esprit qu’une mesure regroupée sur 15 minutes ne retarde pas celles-ci : elles arrivent par la session ouverte.
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.
- Vous devez être connecté pour répondre à ce sujet.
Rejoignez la discussion
Connectez-vous pour poser et répondre à des questions, aimer les messages utiles et marquer la réponse qui a résolu votre problème. Chaque contribution rapporte des points et des niveaux.