Aggregation von Messdaten & asynchrones Senden

Ich versuche hier, die Diskussion von der Hardware (s.u.) weg zu führen und die anderen Aspekte etwas zu beleuchten.

Für Systeme ohne permanenten Netzanschluss würde es ja Sinn ergeben, das sie häufiger Messen, als sie senden. Das mindert den Kommunikationsoverhead und spart Strom.

Dazu gibt es schon diverse Threads:

Da ging es aber meist um die Hardware, hier soll es aber vor allem um die Software und den Prozess gehen.

Der grundsätzlich Ablauf ist einfach:

  1. messen
  2. speichern
  3. (später) senden

Zu 1.: muss nichts gesagt werden - wie gehabt
Zu 2.: hier gibt es eine wichtige Unterscheidung: ist eine Uhrzeit vorhanden oder nicht. Weiterhin die Frage, was gespeichert wird.
Zu 3.: hier die Frage, ob es durch die Aggregation ein Problem mit dem Backend gibt.

Mit Uhrzeit: jeder Datensatz bekommt einen absoluten Zeitstempel. Der wird mitgesendet und vom Backend ausgewertet. Kann Kotori das? Durch den Zeitstempel bleiben die Daten auch über Resets etc… valide.

Ohne Uhrzeit: jeder Datensatz bekommt einen relativen Zeitstempel. Der wird als Offset mitgesendet. Könnte Kotori das lernen? Nach Reset etc… müssen etwaige Daten gelöscht werden, da der Zeitstempel dann ungültig wird.
Beispiel: eine Messung wird 45 Sekunden nach dem Booten durch geführt. Das Senden erfolgt 600 Sekunden nach dem Boot. Dann bekommt die Messung einen Offset von -515 Sekunden und Kotori kann die absolute Zeit der Messung aus dem Offset und dem Zeitpunkt der Datenübertragung errechnen.

Was wird gespeichert: hängt stark vom Verwendungszweck ab. Ist das Ziel eine SD-Karte sind das wohl CSV-Daten. Bei Übertragung per Mobilfunk eher LPP komprimierte Datensätze.

Senden: die Sendefrequenz hängt ganz von der Anwendung ab. Der einzige limitierende Faktor ist die Größe des Zwischenspeichers. Man muss natürlich senden, bevor der vollläuft.

1 Like

Daten mit Zeitstempel kann Kotori verarbeiten, mache ich mit meinen Open Hive Daten schon eine geraume Zeit, schicke aber per HTTP, für MQTT weiß ich es nicht sicher.

CSV ist nicht schlecht, Diren hat auch im InfuxDB spezifischen Format gepuffert, geht auch ist nur nicht so universell, wenn halt keinen Influx an der Gegenstelle hängt.

Da ist halt die Frage welcher Zwischenspeicher einen deep sleep überlebt, bei einem Nicht-ESP-Microcontroller könnte man einfach ein Varriablen-Array dafür nutzen und dort Daten speichern, bei einem Cortex M0, als Beispiel, “überleben” die Variablen den deep sleep, beim ESP halt leider nicht. Das ist momentan für mich noch einer der großen Nachteile des ESP für low power-Anwendungen. Aber du wolltest ja nicht über Hardware hier reden! ;-)