Von English mit KI übersetzt ·
Wir betreiben einen Go-Dienst auf einem Edge-Box an einem Solarstandort, der Wechselrichterausliest und über MQTT mit QoS 1 an Hermetry veröffentlicht. Die Verbindung läuft über einen 4G-Router, der mehrmals täglich abbricht, meist für 30 s bis einige Minuten.Mein Denkmodell stammt von unserem eigenen Mosquitto vor einigen Jahren: Der Broker speichert QoS-1-Nachrichten auf der Festplatte, der Client verbindet sich mit clean session = false neu, und alles in der Warteschlange wird zugestellt. Deshalb habe ich CleanSession beim Client auf false gesetzt und angenommen, dass Hermetry die Daten in beide Richtungen für uns vorhält.Wenn ich nach einem Abbruch den Verlauf ansehe, finde ich Lücken genau in der Länge des Ausfalls. Speichert der Hermetry-Broker nicht persistent? Muss ich eine Einstellung aktivieren, oder ist die Pufferung meine Aufgabe?Was ich bisher geprüft habe: Der Log-Tab des Geräts zeigt die Trennung mit keepalive_timeout und einen Wiederverbindungsversuch einige Minuten später, wie erwartet. Unsere Client-Logs zeigen, dass die Veröffentlichungen während des Ausfalls ohne Fehler zurückkamen, weshalb ich dachte, der Broker habe sie erhalten. Die Wechselrichterwerte werden alle 30 s gesendet, mit einem ts aus der eigenen Uhr des Wechselrichters (NTP-synchronisiert), im Format {„ts“: …, „values“: {…}}. Wir brauchen den Verlauf vollständig, weil der Anlagenbetreiber monatlich darauf abrechnet; jede Minute, die täglich fehlt, kostet also tatsächlich Geld.
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.
Von English mit KI übersetzt ·
Lücken genau in der Länge des Ausfalls deuten eher darauf hin, dass während des Ausfalls gar nichts veröffentlicht wurde, und nicht darauf, dass der Broker sie verloren hat. Stellt Ihr Client während der Trennung überhaupt Nachrichten in eine Warteschlange?
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?
Von English mit KI übersetzt ·
Guter Punkt. Paho Go nutzt den standardmäßigen In-Memory-Store. Ich hatte angenommen, dass er die Nachrichten während der Offline-Phase in eine Warteschlange stellt.
Good point. Paho Go with the default in-memory store. I’d assumed it queues while offline.
Von English mit KI übersetzt ·
Von der Managementseite: Unser Integrator hat uns dasselbe zu den Datenlücken gesagt, am Ende haben sie auf dem Gerät zusätzlichen Speicher eingebaut. Die Details kann ich leider nicht nennen, sorry.
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.
Von English mit KI übersetzt ·
Clean session false hilft auf Hermetry ohnehin nicht. Ich bin ziemlich sicher, dass in der Dokumentation steht, dass es als Clean Session bereitgestellt wird.
Clean session false won’t help on Hermetry anyway. I’m fairly sure the docs say it’s served as a clean session.
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.
Von English mit KI übersetzt ·
Ja. Der Paho-Speicher hat bei einer Trennung alles verworfen, Marias Vermutung war also ebenfalls genau richtig. Ich habe eine bbolt-Datei vor den Publisher gesetzt, die bei PUBACK löscht, und als Test 5 Minuten lang die 4G-Antenne abgezogen: Der Rückstau erschien etwa 20 s nach dem Wiederverbinden mit den richtigen Zeitstempeln im Verlauf. Die Zeile CleanSession=false habe ich ebenfalls entfernt, da sie nichts bewirkt hat.
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.
Von English mit KI übersetzt ·
Eine Sache noch: Begrenze den lokalen Speicher. Wir hatten einmal einen Standort 9 days lang offline, und die Festplatte lief voll. Messwerte, die älter als deine Aufbewahrungsdauer sind, werden ohnehin abgelehnt.
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.
- Du musst angemeldet sein, um auf dieses Thema antworten zu können.
Mitdiskutieren
Melde dich an, um Fragen zu stellen und zu beantworten, hilfreiche Beiträge mit „Gefällt mir“ zu markieren und die Antwort zu kennzeichnen, die dein Problem gelöst hat. Jeder Beitrag bringt Punkte und Stufen.