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.