Traduit de English par IA ·
Nous faisons tourner un service Go sur un boîtier edge dans une centrale solaire ; il lit les onduleurs et publie vers Hermetry via MQTT en QoS 1. La liaison passe par un routeur 4G qui coupe quelques fois par jour, en général de 30 s à quelques minutes.Mon modèle mental vient de l’exploitation de notre propre Mosquitto il y a quelques années : le broker persiste les messages QoS 1 sur disque, le client se reconnecte avec clean session = false, et tout ce qui est en file d’attente est livré. J’ai donc défini CleanSession à false sur le client et supposé que Hermetry conserve les données dans les deux sens pour nous.En consultant l’historique après une coupure, je constate des trous exactement de la durée de la panne. Le broker de Hermetry ne persiste-t-il pas les messages ? Faut-il activer un paramètre, ou la mise en tampon relève-t-elle de ma responsabilité ?Ce que j’ai déjà vérifié : l’onglet Log de l’appareil affiche la déconnexion avec keepalive_timeout puis une reconnexion quelques minutes plus tard, comme prévu. Nos journaux client indiquent que les publications effectuées pendant la panne ont renvoyé sans erreur, ce qui m’a fait penser que le broker les avait reçues. Les mesures des onduleurs sont envoyées toutes les 30 s, avec un ts pris sur l’horloge propre de l’onduleur (synchronisée par NTP), au format {« ts »: …, « values »: {…}}. Nous avons besoin d’un historique complet car le propriétaire du site facture à partir de celui-ci chaque mois ; quelques minutes manquantes par jour ont donc un coût réel.
We run a Go service on an edge box at a solar site that reads inverters and publishes to Hermetry over MQTT with QoS 1. Link is a 4G router that drops a few times a day, usually for 30 s to a few minutes.
My mental model came from running our own Mosquitto years ago: the broker persists QoS 1 to disk, client reconnects with clean session = false, everything queued gets delivered. So I set CleanSession false on the client and assumed Hermetry holds things for us both ways.
Looking at the history after a drop I see gaps of exactly the outage length. Is Hermetry’s broker not persisting? Do I need to switch some setting on, or is the buffer my job?
What I checked so far: the device’s Log tab shows the disconnect with keepalive_timeout and a reconnect a few minutes later, as expected. Our client logs say the publishes during the outage returned without error, which is what made me think the broker had them. Inverter readings are every 30 s with a ts we take from the inverter’s own clock (NTP synced), sent as {« ts »: …, « values »: {…}}. We need the history to be complete because the site owner bills from it monthly, so a few minutes missing per day actually costs money.
Traduit de English par IA ·
Des trous correspondant exactement à la durée de la panne ressemblent à une absence totale de publication pendant la panne, et non à une perte de messages par le broker. Votre client met-il au moins en file d’attente les messages pendant la déconnexion ?
Gaps of exactly the outage length sounds like nothing was published at all during the outage, not like the broker lost them. Is your client even queuing while disconnected?
Traduit de English par IA ·
Bien vu. Paho Go utilise le store en mémoire par défaut. J’avais supposé qu’il mettait les messages en file d’attente pendant la déconnexion.
Good point. Paho Go with the default in-memory store. I’d assumed it queues while offline.
Traduit de English par IA ·
Du côté direction : notre intégrateur nous a dit la même chose au sujet des trous de données, ils ont fini par ajouter du stockage sur le boîtier. Je ne peux pas vous donner les détails, désolé.
From the management side: our integrator told us the same thing about gaps, they ended up adding storage on the box. Can’t tell you the details, sorry.
Traduit de English par IA ·
Clean session false ne servira de toute façon à rien avec Hermetry. Je suis à peu près certain que la documentation indique qu’il est traité comme clean session.
Clean session false won’t help on Hermetry anyway. I’m fairly sure the docs say it’s served as a clean session.
Traduit de English par IA ·
Kevin a raison, et ce n’est que la moitié de la réponse. Nous avons rencontré le même problème sur un site éolien.Le MQTT de Hermetry est en 3.1.1, et un CONNECT avec clean session à false est traité comme clean. Rien n’est mis en file d’attente pour un appareil hors ligne, sauf les commandes envoyées en mode persistant. Il n’y a donc aucun état de session à reprendre, dans aucun sens pour la télémétrie.Ce que Hermetry garantit concerne le sens entrant : le PUBACK n’est envoyé qu’une fois le message mis en file d’attente de manière sûre de leur côté. Si le message ne peut pas être mis en file, vous ne recevez pas de PUBACK, la session se ferme, et le client doit renvoyer le message après reconnexion. Les doublons portant le même appareil, la même clé et le même horodatage ne sont stockés qu’une fois, donc renvoyer est sans risque.Le tampon est donc de votre ressort, et le schéma est le suivant :
- Écrire chaque mesure dans un stockage local (nous utilisons un fichier SQLite) avec son propre ts en ms.
- Publier depuis le stockage, et ne supprimer une ligne que lorsque son PUBACK arrive.
- Après reconnexion : s’abonner, demander les attributs partagés, puis envoyer le retard avant les données en direct.
Envoyez le retard sous forme de tableaux {ts, values} pour qu’il arrive aux bons moments. Le profil dispose d’une limite distincte, Messages de relecture par seconde, pour les messages dont tous les enregistrements datent de plus d’une minute, donc un long retard se résorbe progressivement. Ne paniquez pas si tout n’apparaît pas d’un coup.La page MQTT contient la section sur les accusés de réception, à lire une fois.
Kevin’s right, and that’s half of it. We hit the same thing on a wind site.
Hermetry’s MQTT is 3.1.1 and a CONNECT with clean session false is served as clean. Nothing is queued for a device while it’s offline, apart from commands that were sent as persistent. So no session state to resume, in either direction for telemetry.
What Hermetry does promise is on the way in: the PUBACK goes out only after the message is safely queued on their side. If it can’t be queued you get no PUBACK and the session closes, and the client is expected to resend after reconnecting. Duplicates of the same device, key and timestamp are stored once, so resending is safe.
So the buffer is yours, and the pattern is:
- Write every reading to a local store (we use a SQLite file) with its own ts in ms.
- Publish from the store, delete a row only when its PUBACK arrives.
- After reconnect: subscribe, ask for shared attributes, then send the backlog before live data.
Send the backlog as arrays of {ts, values} so it lands at the right times. The profile has a separate Replay messages per second limit for messages whose records are all older than a minute, so a long backlog drains over a while. Don’t panic when it doesn’t all appear at once.
The MQTT page has the acknowledgement section, worth reading once.
Traduit de English par IA ·
Oui. Le stockage en mémoire de Paho jetait tout à la déconnexion, donc l’intuition de Maria était également juste. J’ai placé un fichier bbolt devant le publisher, suppression à la réception de PUBACK, puis j’ai débranché l’antenne 4G pendant 5 minutes pour tester : le retard est apparu dans l’historique avec les bons horodatages environ 20 s après la reconnexion. J’ai aussi supprimé la ligne CleanSession=false, car elle ne servait à rien.
Yep. The Paho memory store was throwing everything away on disconnect, so Maria’s guess was spot on too. Put a bbolt file in front of the publisher, delete on PUBACK, and pulled the 4G antenna for 5 minutes as a test: backlog showed up in history with the right timestamps about 20 s after reconnect. Removed the CleanSession=false line as well since it did nothing.
Traduit de English par IA ·
Un point à ajouter : limitez le stockage local. Un site est resté hors ligne pendant 9 days une fois et le disque s’est rempli. Les mesures plus anciennes que votre rétention sont de toute façon refusées.
One thing to add: cap the local store. We had a site offline for 9 days once and the disk filled up. Readings older than your retention get refused anyway.
- 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.