Von English mit KI übersetzt ·
Kevin hat recht, und das ist nur die halbe Antwort. Wir hatten dasselbe Problem auf einer Windkraftanlage.Hermetry verwendet MQTT 3.1.1, und ein CONNECT mit clean session false wird wie clean behandelt. Während ein Gerät offline ist, wird nichts für es in eine Warteschlange gestellt, außer Befehlen, die als persistent gesendet wurden. Es gibt also keinen Sitzungszustand, der fortgesetzt werden könnte, und zwar für Telemetrie in keiner Richtung.Was Hermetry in Eingangsrichtung zusagt, ist Folgendes: Das PUBACK wird erst gesendet, nachdem die Nachricht auf deren Seite sicher in die Warteschlange gestellt wurde. Kann sie nicht eingereiht werden, bekommst du kein PUBACK, die Sitzung wird geschlossen, und der Client soll nach dem Wiederverbinden erneut senden. Duplikate mit demselben Gerät, Schlüssel und Zeitstempel werden nur einmal gespeichert, daher ist erneutes Senden sicher.Der Puffer liegt also bei dir, und das Muster sieht so aus:
- Jeden Messwert in einen lokalen Speicher schreiben (wir nutzen eine SQLite-Datei) mit seinem eigenen ts in ms.
- Aus dem Speicher veröffentlichen und eine Zeile erst löschen, wenn ihr PUBACK eintrifft.
- Nach dem Wiederverbinden: abonnieren, gemeinsame Attribute abfragen und dann den Rückstau vor den Live-Daten senden.
Sende den Rückstau als Arrays von {ts, values}, damit die Werte zu den richtigen Zeiten ankommen. Das Profil hat ein separates Limit für Wiedergabenachrichten pro Sekunde für Nachrichten, deren Datensätze alle älter als eine Minute sind, daher leert sich ein langer Rückstau über einen gewissen Zeitraum. Keine Panik, wenn nicht alles auf einmal erscheint.Die MQTT-Seite enthält den Abschnitt zur Bestätigung, einmal lesenswert.
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.