Nach so vielen tollen potenziellen Anwendungszenarien ist es an der Zeit, die Aufgabe der Überwachung und Messwertspeicherung im Sinne der Nachhaltigkeit optimal zu lösen. Datenlogging ist typisch für sehr viele Aufgaben im Internet der Dinge und des Denkens, so dass sich der Aufwand eines generischen Ardublock-Programmes lohnt. Unser zu entwickelndes Programm soll folgende Randbedingungen erfüllen:

1. Konsequente Nutzung des deep-sleep-Befehls, nur dann sind mobile Anwendungen und Solarbetrieb möglich.
2. Messdaten zyklisch erfassen (Sensoren abfragen) und Grenzen überwachen. Aus Gründen der Ressourceneffizienz kann diese Teilaufgabe auch mit abgeschaltetem WLAN durchgeführt werden. Zur Erinnerung: mit aktiven WLAN-Interface benötigt der Octopus einen Strom von ca. 90 mA. Ohne WLAN sind es nur 20 mA. Auch wenn es nur wenige ms Rechenzeit bedarf, so summiert sich der Unterschied im Energiebedarf über das Jahr. Die Aktivierung des WLAN-Interfaces ist über den deep-sleep Befehl möglich.
3. Senden in die Cloud (zur Datenspeicherung oder Alarmierung) mit aktivem WLAN nur dann, wenn unbedingt nötig. Hierzu sind energieeffiziente Strategien denkbar: Z. B. sende nur wenn sich der Messwert gegenüber der letzten Übertragung um x % verändert hat, oder wenn ein Alarm-Grenzwert erreicht wird. Zusätzlich aber vielleicht auch zu festen Zeitpunkten (z.B. alle 10 Abtastzyklen auf jeden Fall senden), um zu sehen, ob der Sensorknoten noch aktiv ist.
4. Falls gewünscht, soll der Knoten auch Kommandos aus der Cloud entgegennehmen, z.B. eine veränderte Abtastperiode (Zykluszeit) um z.B. in Zeiten starker Regenfälle, die Pegelüberwachung häufiger zu initiieren, oder um bei zuneige gehender Akkukapazität einen Notbetrieb zu ermöglichen.

Eine Wetterstation im Vogelhäuschen übernimmt für uns das Monitoring der Umweltbedingungen. Manchmal beobachtet man dabei unverhofft auch einmalige Naturphänomene:  Als im Januar 2022 ein Vulkanausbruch den Inselstaat Tonga erschüttert, registriert unsere Messtation kurz darauf eine durch die Druckwelle ausgelöste Luftdruckschwankung. Vernetzte IoT-Wetterstationen auf der ganzen Welt visualisieren die um den Erdball laufende Welle, wie das externe Video hier eindrucksvoll zeigt.

Das nebenstehende Bild zeigt die Struktur unseres generischen Datenloggers. Als erste Aktivität wird die Konfiguration durchgeführt. Hier erfolgen die parametrisierbaren Einstellungen, wie z.B. der aktuelle Zyklus, die Zykluszeit und die durchzuführende Aufgabe. Schlüsselgrößen sind dabei die Variablen "Zyklus" und "MessAufgabe", die im nichtflüchtigen RTC-RAM auch den notwendigen deep-sleep überdauern. Zyklus zählt die fortlaufenden Messzyklen und sorgt so ggf. für ein erzwungendes Update in der Cloud nach jeweils "FesterSendeZyklus" Zyklen. Der Inhalt der Variablen "MessAufgabe" definiert, was im aktuellen Zyklus zu tun ist:

• MessAufgabe == 0 bedeutet:  Nur Überwachung der Grenzen, ohne WLAN.
• MessAufgabe == 1 bedeutet:  Sende die Messdaten sofort, Aufgrund einer Alarmgrenze oder einer starken Änderung.
• MessAufgabe == 2 bedeutet: Sende die Messdaten sofort, Aufgrund eines erzwungenen Updates nach n Zyklen.

Konkret bedeutet dies in der Schleife, dass wir:

Bei (MessAufgabe > 0) die aktuellen Messwerte erfassen (Unterprogramm "Sensoren_AktuelleMesswerte") und nach erfolgreicher Verbindung mit dem Internet (Funktion "System_WiFi") auch senden. Im dargestellten Beispiel werden die Daten wie gewohnt bei Thinkspeak abgelegt (Unterprogramm "System_Thingspeak"). Die erfolgreich gesendeten Daten speichern wir im lokalen RTC-RAM (Unterprogramm "Sensoren_SpeichereRTC"). Damit ist die aktuelle Messaufgabe erfüllt.

Bei (Messaufgabe == 0) befinden wir uns in einem normalen Überwachungszyklus ohne die Möglichkeit der WLAN-Nutzung, da das Interface beim letzten deep-sleep deaktiviert wurde. In diesem Aufgabenfall schauen wir, ob der aktuelle Zyklus ein ganzzahliges Vielfaches des in "FesterSendeZyklus" gespeicherten Wert ist. Falls ja, dann ist die nächste Aufgabe das Senden der Messwerte aufgrund der zeitlichen Bedingung (MessAufgabe = 2 im nächsten Zyklus). Andernfalls überprüfen wir die Änderung gegenüber der zuletzt in der Cloud gespeicherten Werte (Funktion "Sensoren_Änderung"). Ist die Änderung signifikant, so ist die nächse Aufgabe das Senden der Messwerte aufgrund der Dynamik (MessAufgabe = 1 um nächsten Zyklus). Ohne Änderung verbleiben wir im Überwachungsmodus ohne WLAN (MessAufgabe = 0).

Zum Abschluss erhöhen wir den Zyklenzähler und speichen den neuen Zustand unseres Systems im RTC-RAM. Leider existiert kein Befehl, um das WLAN-Interface direkt zu aktivieren. Je nach nächster Aufgabe führen wir dafür ggf. einen sehr kurzen deep-sleep durch und wachen sofort wieder mit aktiviertem WLAN auf (MessAufgabe > 0), oder wir verschlafen eine Zykluszeit und starten mit der reinen Überwachung der Messwerte (energiesparend ohne WLAN).