Zisternenmessungen

2023-07-18

Version 1.3 - ein Release für ein anpassungsfähiges und vielseitiges Füllstands-Messsystem, Version 1.4 ist in Arbeit

Für Leser, die sich nicht für Details interessieren oder sich zunächst einen schnellen Überblick verschaffen wollen, steht die Füllstandsmessung Kurzbeschreibung zur Verfügung. Grundlagen zur Implementation des Messsystems sind im Artikel Zisternen-Messlösungen zu finden. Den hier vorliegenden Artikel will ich gelegentlich kürzen.

Das hier vorgestellte Messsystem auf der Grundlage eines ESP32 Board mit geflashtem Tasmota32 und Berry wird inzwischen praktisch eingesetzt. Es arbeitet sehr zuverlässig und liefert in zweiminütigen Abständen aktuelle Werte.

Neu: ZIP-Archiv aller Dateien zu diesem Projekt zum herunterladen

Im Netz kann man sehr viele Beispiele finden, die sich mit Temperaturmessungen in menschlich erträglichen Umgebungen beschäftigen. Inzwischen denke ich, dass solche Temperaturmessungen relativ einfach sind und sich daraus kaum Probleme ergeben. Auch in meinem Zisternen-Messsystem brauche ich der Temperaturmessung keine besondere Aufmerksamkeit zu schenken, sie funktioniert einfach. Das ist bei Ultraschallmessungen wesentlich anders, zumindest dann, wenn sie in feuchten Umgebungen stattfinden. Dieser Herausforderung habe ich mich gestellt.

Der praktische Einbau des Messsystems erfordert ein sehr sorgfältiges Augenmerk auf die Dichtigkeit des Gehäuses gegen Eindringen von Feuchtigkeit. Hier sammelte ich in der Vergangenheit einige negative Erfahrungen. Seit dem 2021-07-19 sitzt die neue Elektronik in der Zisterne. Eine kurze Sichtprobe ergab stabiler Sitz des Ultraschallsensors und keinerlei Feuchtigkeitsspuren im Elektronikgehäuse. Nein, ich gieße die Elektronik noch immer nicht ein. Vielleicht später dann doch. wink 

Hinweise zu Tasmota32 und der Programmiersprache Berry habe ich auf der Willkommen Seite untergebracht, siehe Anfang.

Hinweise

In den Beschreibungen zu den Abbildungen verwende ich die horizontalen Angaben "links" ... "rechts". Bei schmalen Browserfenstern wie auf Smartphones sind diese als "oben" ... "unten" zu interpretieren.

Unten sind die Änderungen, Analysen und Vorhaben aufgeführt.

Ein wenig Werbung vorweg - per openHAB, InfluxDB und Grafana cool

Die folgenden beiden Abbildungen zeigen die Darstellungen der Android openHAB App zum Zisternen-Messsystem und zur Wasserzufuhr. openHAB habe ich vorerst zurückgestellt, weil ich mehr Grundlagenkenntnisse brauche.

       

Links ist die jeweils aktuelle Messwertedarstellung zu sehen, ergänzt um die Parametrierung von Minimum, Maximum (s.u.), die manuelle oder automatisierte Steuerung einer Wasserzufuhr sowie die optionalen Schaltuhreinstellungen zur Wasserzufuhr. Mit einem Touch/Klick auf die Wasservorrat-Anzeige erhält man eine Grafik, wie sie rechts zu sehen ist. Während eines hinreichend starken Regens konnten wir zeitnah die Zunahme des Wasservorrats sehr gut an Hand der Grafik verfolgen. Die hier vergleichsweise  lineare Zunahme ist einer Optimierung des Datenbankbestandes geschuldet. Zu Alternativen der Persistenz-Strategien habe ich noch Erfahrungen zu sammeln. Diese liegen aber außerhalb meines Fokus auf das hier vorgestellte Messsystem.

Auf dem Host des Node Red Systems werden u.a. die "sample"-Daten, auch in Kurzform, über längere Zeit gespeichert und per Grafik dargestellt (s.u.). Diese Darstellung bietet auch über längere Zeitspannen feinere Eindrücke. Vielleicht werde ich gelegentlich die Reduzierung von alten Daten per Mittelwertbildung implementieren - oder bspw. mit einem Round-Robin-Datenbanksystem wie RRDtool arbeiten.

openHAB nimmt einem vieles an Arbeit ab und bietet eine chique Oberfläche. Man verliert aber auch partiell die von mir geschätzte unmittelbare Kontrolle. Vielleicht werden mich die automatisierten Zeitfunktion-Grafiken von openHAB in der Anwendung noch komplett überzeugen.

In openHAB habe ich ein "thing" angelegt, "Zisterne" genannt. Dieses "Ding" ist eine Art virtuelles Gerät, welches sich tatsächlich aus der Messeinrichtung (ESP32-Board ...) und einem Shelly1 (Wasserzufuhr) zusammensetzt. "Zisterne" ist ein generisches MQTT Ding und über meinen MQTT Broker Mosquitto angebunden. Es verfügt über 11 Kommunikationskanäle (Channels), durch die u.a. die umfangreiche Parametrierung (s.u.) genutzt werden kann.

Im Vergleich zur openHAB App ist MQTT Dash sehr schnell und zuverlässig. Zusätzlich läuft es auch auf alten bzw. leistungsschwachen Smartphones sehr gut. Die Metrics sind zwischen Smartphones übertragbar. Mit einer selbst erstellten Node Red Anwendung speichere ich die Metrics auch und kann sie für andere Topics per Editor leicht anpassen. MQTT Dash bietet allerdings keine Zeitfunktion-Grafik und ist ein reiner MQTT Client.

InfluxDB und Grafana

Die folgende Abbildung zeigt einige per Grafana dargestellten Zeitfunktionen. Die zugrunde liegenden Daten sind in InfluxDB Datenbanken/Messreihen gespeichert. Dazu habe ich verschiedene "retention policies" und "continuous queries" angelegt. Die bisher konfigurierten grafischen Darstellungen reichen vom aktuellen Zeitpunkt zurück um 24 Stunden bis zu einem halben Jahr. Meine bisher in InfluxDB angelegten "continuous queries" verdichten die aktuellen Nutzwerte "Wasservorrat" und "Temperatur" (48h lang gespeichert) sukzessive per Mittelwertbildung bis hin zu zwei Jahren. Dies genügt vorerst, da die Daten erst seit dem 2021-08-29 nachhaltig gespeichert werden. Ereignisse wie Baumbewässerung und Wasserzufuhr besitzen größere Abstände, weshalb ich diese 10 Jahre lang in InfluxDB aufbewahren lasse und nicht verdichte. Eine Mittelwertbildung von Ein/Aus bzw. True/False ergibt eh keinen Sinn.

 

Grundlagen - für technisch Interessierte, kann übergangen werden

Die Bestandteile  des Messsystems

Das gesamte System auf der Basis von Tasmota32 Version 9.5.0 incl. MQTT Subscriber und Berry Funktionen besteht aus drei Teilen.

  • Die nativen Tasmota Rulesets werden für verschiedene Zwecke genutzt. Ruleset 1 ist permanent aktiv/enabled. Es dient der Initialisierung des Systems nach einem Neustart, ist an dem Kopieren der persistenten Parameter in den MEM<x> Variablen und am restaurieren von ausgelagerten Persistenzen beteiligt. Die Rulesets 2 und 3 dienen der Kommunikation mit dem Anwendungssystem. Sie übernehmen die Zeitsteuerung und bilden  eine Kommunikationsschnittstelle zwischen Tasmota und dem Anwendungssystem.
  • Das Basissystem arbeitet mit Teilen von Ruleset 1 und einigen VAR-Variablen. Es ist am Neustart des Systems beteiligt und kopiert die Inhalte von MEM1 bis MEM16 in die Liste Mem[1] bis Mem[16]. Berry Listen sind als Datenfelder implementiert und bieten so einen schnellen Zugriff. Dieses System stellt kleine Utilities, Funktionen zum senden von MQTT Nachrichten und zur Parametrierung bereit. Es ist unabhängig von spezifischen Anwendungen. Es kann somit als vielseitig einsetzbares Basissystem für verschiedene parametrierbare Anwendungen dienen. Teile von Ruleset 1 dienen der Kommunikation mit diesem System.
  • Das Anwendungssystem ist auf die gewünschte Anwendung spezialisiert. Dazu verwendet es teilweise die in Mem[1] bis Mem[16] vorliegenden Kopien der persistenten Parameter in MEM1 bis MEM16. Für die Anwendung stehen Teile von Ruleset 1, die kompletten Rulesets 2 und 3 sowie einige VAR-Variablen zur Verfügung. In der Zisternenmessanwendung dient Ruleset 2 zur Initialisierung der Messungen, Ruleset 3 nimmt die Roh-Messwerte von Tasmota entgegen und gibt diese per indexiertes Berry Kommando an die Berry Ebene weiter. Dort werden die Rohdaten sukzessive importiert, zu Anwendung spezifischen Nutzdaten verarbeitet und geeignet gesendet.

Das System kommuniziert per MQTT und benötigt für den Einsatz einen MQTT Broker. Ein solcher ist preisgünstig mit einem (älteren) Raspberry Pi, einer (älteren) USB Festlatte sowie den kostenfrei erhältlichen Raspios/Raspbian und Mosquitto realisierbar. Zusätzlich lassen sich darauf auch Node Red installieren/nutzen und insbesondere Messdaten speichern.

Mittlerweile nutze ich zusätzlich openHAB. Nach einigen "Durchärgereien" habe ich u.a. dieses Zisternen-Messsystem bei openHAB eingebunden, selbstverständlich per MQTT Anbindung. Es sieht alles sehr gut aus. Funktionieren tut es eh. Ich muss aber gestehen, dass mir die unmittelbare Kontrolle von Node Red mehr zusagt. Die Modellierung(en) in openHAB sind allerdings sehr überzeugend wie auch die sehr vielen Anbindungen. Nachteil: openHAB frisst reichlich Performance, das hier nur am Rande.

Das Messsystem verbraucht elektrische Energie mit einer Leistung von ca. 0,3W. Das ergibt bei 24/7 Betrieb einen Jahresverbrauch von ca. 2,6kWh.

Das eigentlich Wichtige - Die Eigenschaften des Zisternen Messsystems

Eingesetzte Sensoren sind ein Temperatursensor und ein Ultraschallsensor. Die zu Grunde liegende zeitliche Auflösung ist 1 Minute. Kürzere Abstände sind nicht möglich, erscheinen hier aber auch sinnfrei. Tests und Analysen des Ablaufs einer Messwerteerfassung zeigen, dass das System problemlos minütlich messen, verarbeiten und senden kann. Die Trigger (s.u.) sind etwas an die Nutzung des Shelly H&T von Allterco Robotics angelehnt und erweitert. Als Mensch-Maschinen-Schnittstelle ist die Android App MQTT Dash sehr gut geeignet. Zur Speicherung der Nutzdaten und deren grafischer Darstellung kann bspw. Node Red mit seinen sehr weitgehenden Programmiermöglichkeiten eingesetzt werden - oder auch das sehr komfortable openHAB.

  • Diese Messeinrichtung kann sehr weitgehend parametriert werden. Es werden dazu alle 16 Mem-Variable genutzt. Gegenwärtig werden 15 Parameter verwendet, wovon zwei optional sind und bei Bedarf wichtigeren Parametern weichen können.
  • Es sind derzeit ausschließlich Zisternen mit senkrecht angeordneter zylindrischer Form vorgesehen. Deren Parameter sind Innenradius und max. Abstand vom Ultraschallsensor. Letzterer definiert den Mindestwasserstand. Andere Zisternenformen sind durch wenige Parameter- und Code-Anpassungen alternativ fest integrierbar.
  • Es wird ein auf 32 Zeichen begrenztes Benutzer definiertes Topic verwendet. Dieses ist mit slashs hierarchiesierbar. Beispiel: Garten/Zisterne. Die gesendeten Topics ergeben sich aus <Topic>/<Detail>. Die <Detail> Werte sind
    • "raw" für die Rohwerte. Diese sind bei Bedarf aktivierbar und können die Analyse der Rohwerte und der sich daraus ergebenden Nutzwerte unterstützen. Nach dem Systemstart ist das Senden der Rohwerte deaktiviert.
    • "proc" für die Nutzwerte, die je nach Bedarf gespeichert werden können. Die Payload liegt im JSON Format als eine Folge von Name-Wert-Paaren vor. Beispiel: {"time":"2021-07-21T23:56:00","trigger":"[differ,above]","Temperatur":"18.8","Wasservorrat":"3461"}
    • "trig" signalisiert Beginn und Ende einer Messwertaufnahme. Die Payload ist eine einfache Zeichenkette. Folgende Payload-Werte signalisieren den Start einer Messwertaufnahme: "sample" für reine zeitgesteuerte Abtastungen, "limit" für Untersuchungen auf Grenzwertüber- oder -unterschreitungen, "differ" zur Untersuchung auf größere Änderungen. Die Payload "done" signalisiert das Ende der Messwertaufnahme.  
    • "pers" dient ausschließlich dem Persistieren von internen Zuständen, damit diese nach einem Neustart des Systems wiederhergestellt werden können. Diese Zustände stellen die Hysterese Minimum<-->Maximum (s.u.) wieder her und liefern den zuletzt übertragenen Nutzwert Wasservorrat zur Berechnung von Änderungen. Damit ergeben sich nach einem Neustart keine schlecht interpretierbaren Sonderwerte.
  • Zwei definierbare, auf 32 Zeichen begrenzte Nachrichten können bei Grenzwertunter-/überschreitung zusätzlich automatisch gesendet werden - s.a. unter Trigger "limit".
  • Drei Systemtrigger "sample", "limit" und "differ" lassen die Messwerte erfassen und, zum Teil bedingt, die dazu verarbeiteten Nutzwerte mit Zeitstempel per MQTT senden. Sie werden alle durch einstellbare Minutenabstände aktiviert. Diese Abstände unterliegen keinerlei Einschränkungen. Alle Trigger werden, falls es sich ergibt, auch parallel verarbeitet.
  • Zuätzlich sind frei wählbare Trigger nutzbar, werden aber voraussichtlich nur für Sonderfälle Einsatz finden. Ein "adhoc" Trigger, durch einen Benutzer ausgelöst, ist überflüssig, weil die aktuellen Nutzwerte mit jeder Messwertaufnahme und -verarbeitung gesendet werden. Hierfür ist "differ" und/oder "limit" auf den gewünschten Aktualisierungsabstand einzustellen, bspw. 1 oder 2 Minuten.
  • "sample" wird ausschließlich durch feste Zeitabstände aktiviert. Dieser Trigger ist an keine Bedingung geknüpft.
  • Auf "limit" folgt eine Prüfung des Nutzwertes Wasservorrat. Liegt dieser unterhalb eines einstellbaren Minimums und es existiert eine benutzerdefinierte Nachricht dazu, wird diese zusätzlich zur Nutzwertenachricht gesendet. Entsprechendes existiert zur Überschreitung eines einstellbaren Maximums. Liegt der Nutzwert im geschlossenen Interval [Min, Max] findet keine zusätzliche Nachrichtenaktivität statt.
    Eine Hysterese zwischen Minimum und Maximum sorgt dafür, dass bei Grenzwertunter- bzw. -überschreitung die Messdaten und ggf. die benutzerdefinierte Nachricht ohne Wiederholung gesendet wird. Nach der Unterschreitung des Minimums wird dieser "limit"-Fall gesperrt und erst mit Überschreitung des Maximums freigegeben. Entsprechend läuft es in der umgekehrten Richtung.
  • Auf "differ" folgt eine Prüfung des Nutzwertes Wasservorrat. Unterscheidet sich dieser vom zuletzt mit dem Trigger "differ" gesendeten Nutzwert in "starkem" Maße, so wird der Trigger "differ" in die Nutzdatennachricht eingefügt und der Nutzwert als neuer Vergleichswert verwendet. Was hier "starkes" Maß bedeutet, wird benutzerdefiniert per "untere Änderungsschwelle" und "obere Änderungsschwelle" eingestellt.
  • Die MQTT Nachrichten mit den Nutzdaten liegen im JSON Format vor. Die Trigger sind als Elemente eines Datenfeldes in der Struktur <Nachricht>.<Payload>.trigger enthalten, bspw. '["sample","differ"]'. Ist dieses Datenfeld leer, handelt es sich um einen Momentanwert, der nicht zur Speicherung vorgesehen ist. Da openHAB diese Nachrichten auch empfängt, werden die enthaltenen Werte von openHAB irgendwie gespeichert und in Grafiken verwendet. Wie dies genau geschieht, entzieht sich noch meiner Kontrolle. Wie die Namen von <Nachricht> und <Payload> lauten, ist MQTT Subscriber abhängig. In MQTT Dash heißt <Nachricht> bspw. "event", in Node Red "msg" - in beiden heißt <Payload> "payload".
    Mittlerweile lasse ich jeden gesendeten Nutzwerte-Datensatz per InfluxDB speichern. Der Triggerwert "sample" wird auf diese Weise obsolet, soll aber für ggf. andere Speicherstrategien beibehalten werden. "differ" und "limit" ("below", "above") werden noch für Speicherungen in Textdateien genutzt, was voraussichtlich zukünftig entfallen wird. Trotzdem liefern solche Trigger Informationen, die in anderen Umgebungen genutzt werden können und insofern ihren Sinn behalten. 
  • Mit jedem Messvorgang wird eine parametrierbare Anzahl an Abstands-Rohwerten gesammelt, die von Tasmota geliefert werden. Diese Werte sind mitunter fehlerbehaftet. Eine geeignete Mittelwertbildung beseitigt solche Fehler verlässlich. Deren Resultate wurden ausgiebig analysiert. Diese Mittelwertbildung ist für dieses Messystem geeignet und stabil.
  • Ein im Anwendungssystem integrierter Watchdog schaut asynchron in dreifachen Zeitabständen bezogen auf den kürzesten der drei Triggerzeitabstände nach, ob Messungen durchgeführt werden. Falls nicht, wird ein Warmstart der Anwendung durchgeführt. Kommt dies wiederholt vor, wird das System neu gestartet.
  • Für Wartungsarbeiten und/oder Analysen kann das Anwendungssystem gestoppt und gestartet werden. Ist es gestoppt, wirkt der Anwendung Watchdog nicht. D.h. dann startet er weder die Anwendung noch das System neu.
  • Optional: Ein Parameter "Mode" auf der Basis von Bits (Flags) ist theoretisch entwickelt und kann zukünftig bei Bedarf die Nutzung/Nichtnutzung von "limit" und "differ" steuern. "sample" soll fest beibehalten werden. Für eigene Zwecke wird ein solcher Betriebsartparameter nicht gebraucht, weshalb ich gegenwärtig nicht daran arbeite.

Gründe für diese Eigenschaften bzw. deren Vorteile

  • Die sehr weitgehende Parametrierung dient dazu, das System vielseitig einsetzen und nach Bedarf nutzen sowie anpassen zu können. Parameter für solche Anpassungen sind
    • das Topic, insbesondere für bereits existierende MQTT Topicstrukturen
    • die Zisternenmaße, bei zylindrischer Zisterne Radius und min. Wasserstand (tatsächlich max. Abstand vom Sensor)
    • drei voneinander unabhängige Zeitabstände der Messungen in Minuten (nach Anwendervorlieben) - auch zwecks optionaler Speicherung für Analysen (Fehlerbehebung) und Datenbasis für Grafiken
    • die Anzahl an Einzelmessungen zur fehlerfreien/fehlerarmen Gewinnung eines Rohwertes - u.U. auch abhängig von der Einbauumgebung
    • zwei Grenzwerte für automatisierte Wasserzufuhr und MQTT-Nachrichten zur Nutzung dieser Automatisierung ohne Zentralen wie FHEM, IOBroker, ..., openHAB und somit weniger fehleranfällig (keine "stille Post" Effekte)
    • zwei Differenzschwellen (untere, obere) zur Erfassung stärkerer Füllstandsänderungen für das Senden der Messwerte mit "differ"-Trigger
    • eine Toleranzschwelle zum feststellen von Fehlmessungen, in erster Linie für Fehleranalysen gedacht - s.u.
    • Benennung der Nutzwerte, bei mir "Temperatur" und "Wasservorrat", damit ein Anwender diese nach seinen Vorlieben einstellen (lassen) kann - vorgegeben habe ich "temperature" und "water reserve"
      Diese werden evtl. in eine Berry Datei ausgelagert, falls Platz für weitere Parameter gebraucht wird.
    • ... (erweiterbar) 
  • Der Trigger "limit" kann bspw. dazu verwendet werden, einen automatischen Wasserzulauf bei Niedrigstand zu realisieren. Bei Erreichen des Höchststandes kann der Zulauf automatisiert abgestellt werden. Dazu braucht es außer dem eh obligatorischen MQTT Broker keine zusätzliche Steuerzentrale. Ein MQTT fähiges Gerät wie ein Shelly 1 mit gesteuertem Magnetventil genügt. Auch das Ein-/Ausschalten einer Zisternenpumpe per Shelly oder Sonoff Produkt wäre so möglich. Passende Topics vorausgesetzt ginge auch Zulauf- und Pumpenschaltung parallel. Alternativ oder zusätzlich könnte eine eMail gepusht werden, bspw. per Node Red. Vermutlich kann auch ein Kommando per http://... eingesetzt werden, wodurch die Steuerung auch bei ausgefallenem MQTT Broker wirken könnte. Dies werde ich gelegentlich erproben.
  • Der Trigger "sample" dient dazu, die Nutzdaten mit Zeitstempel auf Basis einer festen Abtastrate zu speichern ...
  • Der Trigger "differ" dient dazu, die Nutzdaten mit Zeitstempel auf Basis von Änderungen zu speichern ...
  • Nicht zuletzt ist per passend eingerichteter benutzerseitiger Smartphone App und hinreichend ambitioniertem Anwender ein kostengünstiger Fernservice bei Mess- und/oder technischen Kommunikationsproblemen möglich. Eine unmittelbare Fernwartung per VPN ist selbstverständlich möglich, sei hier aber auf Anbieterseite nicht vorausgesetzt.

Einige der Konfigurationsparameter werden evtl. nicht genutzt bzw. nie geändert, weil es dafür keinen Bedarf gibt. Das schmälert aber nicht das breite Einsatzfeld für Füllstandsmessungen, zumal auch Parameter der Messfehleranalyse (Wartungszwecke) dienen, um damit die Konfiguration den Umgebungsbedingungen/Anwenderwünschen anpassen zu können. 

Erfahrungen der Speicherung mit fester Abtastrate liegen vor. Die Speicherung auf der Grundlage von Nutzwertänderungen soll noch erprobt werden. Es zeigt sich, dass die Speicherung von Änderungen sehr gut Fehlmessungen erkennen lassen. Dies kann somit zur Verbesserung der Rohwertverarbeitung genutzt werden, was inzwischen implementiert ist.

Der handwerklich, praktische Aufbau des Messsystems

Die Abbildungen zeigen von links nach rechts: Die Elektronik im IP 67(?) Gehäuse, auf der Aluschiene temporär festgebunden - Elektronik Nahaufnahme - Versuch der zusätzlichen Abdichtung mit Silikon

           

Für den Betrieb des Messsystems sind ausschließlich eine Stromversorgungsleitung mit 5V zur Zisterne und die Erreichbarkeit des WLAN erforderlich. Die Aluminiumschiene kommt aus einem Baumarkt und hat sich inzwischen bestens bewährt. Sie wird auf einen konzentrischen, nach innen gerichteten Vorsprung der Zisterne oberhalb des höchsten Wasserstandes gelegt und hält dort auf Grund ihrer knappen Passform sicher. Alternativ kann eine solche Schiene verschraubt werden oder man kommt ohne Schiene aus. Der Ultraschallsensor ist links des Elektronikgehäuses in eine Bohrung der Schiene gesteckt und hält dort fest. Die WLAN Verbindung zu einem Repeater in ca. 5m Abstand ist naturgegeben sehr gut. Wenn sich die Abdichtung bewähren sollte, wird das Gehäuse mit der Schiene verschraubt. Die Aluschiene behindert offensichtlich die WLAN Kommunikation nicht sehr. Diese Schiene verformt das elektrische Wechselfeld der elektromagnetischen Welle mit Sicherheit. Ob dies eine Ausbreitung der Welle begünstigt oder eher schwächt, vermag ich nicht abzuschätzen - beides ist möglich. In den Tests hat sich keine Beeinträchtigung gezeigt. Vergleichstests - mit und ohne Aluschiene - habe ich nicht durchgeführt. Alternativ böte sich eine Kunststoffschiene an. Eine mit Bootslack in vielen Schichten bestrichene Holzlatte hat sich nicht bewährt.

Anmerkung zum MQTT Traffic

Ich stelle mit leichtem Erschrecken fest, dass es offenbar zum Standard gehört, in kurzen Abständen und laufend Nachrichten zu senden. Dies erhöht den (W)LAN Traffic in einer Weise, die mir nicht gefällt. Auch wenn ich dieses ständige Senden von Nachrichten seitens Tasmota gegenwärtig nicht unterbinden kann, verfolge ich in meinem Anwendungssystem eine andere Strategie. Das Anwendungssystem sendet nur dann eine Nachricht, wenn es einen Anlass dazu gibt. Dabei setze ich vermehrt auf retained messages. Dies vergrößert zwar die Datenbank des MQTT Brokers, verringert aber das ständige (W)LAN-MQTT-"Gequassel". Retained ist allerdings mit Sorgfalt einzusetzen, manchmal kann es auch unliebsame Effekte haben.

Testmöglichkeiten, kleine Variation der Messeinrichtung und deren Anwendung

In der Berry Konsole kann per Zuweisung von "true" an die Berry-Variable "Test" das Senden der Rohwerte aktiviert werden. Das sind die Oberflächentemperatur des ESP32-Chip, die Zisternen-Lufttemperatur (wie Nutzwert) und der von Tasmota gelieferte Abstand. Dieser Abstand wird zusammen mit der Temperatur zum Nutzwert verfügbarer "Wasservorrat" verarbeitet. Der Temperatursensor und damit die Verarbeitung der Lufttemperatur kann auch entfallen. Sie soll die Genauigkeit bei größeren Temperaturabweichungen von 20°C erhöhen.

Per Zuweisung von "true" an die Berry-Variable "Debug" werden während der Messwert-Verarbeitung und bzgl. Senden von MQTT Nachrichten zusätzliche Informationen ausgegeben, die eine Fehlerverfolgung unterstützen. Diese können auch sehr gut bei der Einbindung in ein System, bei mir Node Red, helfen. Bei Bedarf kann selbstverständlich das Nachrichtenformat angepasst werden.

Die untere, rechte Abbildung zeigt einen Debug-Auszug. "getData" ist die Berry Funktion zum Kommando 'd', idx der in Tasmota zu Grunde liegende Kommando-Index, val der per 'd' gelieferte Wert. d<x> wird in den nativen Rulesets als Kommando abgearbeitet, bspw. so:

on time#minute|%mem4% do backlog d1 sample; d2 %timestamp% endon

Damit wird getData per d<x> zweimal aufgerufen - zuerst mit Index 1 und dem Wert "sample", dann mit Index 2 und dem Zeitstempel als Wert. Für Rule-Kommandos verwende ich möglichst kurze Identifier, damit diese dort wenig des evtl. knappen Platzes verbrauchen. Trigger wie oben beschrieben. Hinter "pub:" ist auch zu sehen, wie sich beim senden der Messwerte die Payload in JSON zusammensetzt.

Links: Die MQTT Dash Anwendung für Wasserzulauf (anderes Projekt) und Zisterne-Projekt mit Anzeige der Nutzwerte und Einstellungen für Minimum, Maximum -  Rechts: Debug-Auszug der Berry Konsole

      

Die linke Abbildung zeigt ein für Benutzer geeignetes Dashboard. Das rote Symbol zeigt, dass gegenwärtig der Zisterne kein Wasser zugeführt wird. Damit ist auch das manuelle Einschalten der Wasserzufuhr möglich. Das gelbe Symbol signalisiert ein gegenwärtiges Sammeln von Messwerten, was auch durch berühren ad hoc ausgelöst werden könnte. Weiterhin ist die (maximale) Dauer der Wasserzufuhr einstellbar - hier 60 Minuten. Es werden die Startzeit der letzten Wasserzufuhr und deren Dauer angezeigt, der aktuelle Wasservorrat, die Lufttemperatur in der Zisterne, der Zeitpunkt der letzten Messung, das eingestellte Minimum und das eingestellte Maximum. Das System steuert an Hand der letzten beiden einstellbaren Werte die automatische Wasserzufuhr. Neben dem hier vorgestellten ESP32 Messsystem sind ein Shelly1 mit geflashtem Tasmota und zusammengestellten Rulesets sowie ein Magnetventil beteiligt.

In der rechten Abbildung ist eine komplette Darstellung der Debug-Ausgabe einer Messung zu sehen. Darin wirken die Trigger "limit" und "differ". Es werden 11 Abstands-Rohwerte, die ESP32 Temperatur und die Zisternentemperatur importiert. Da weder eine größere Änderung des Wasservorrats noch eine Über-/Unterschreitung der Limit-Grenzwerte vorliegt, ist die Triggerliste (drittunterste Zeile) leer. "Dist" ist die geordnete Liste der Abstands-Rohwerte. Hinter "pub:" ist die gesendete MQTT Nachricht zu sehen.

Node Red

Ein relativ kleiner Flow empfängt die Messwerte und speichert diese in zwei Dateiformaten. In beiden Formaten werden je Zeile der Zeitstempel zum Beginn der Messwertaufnahme, die Zisternen-Lufttemperatur und der verfügbare Wasservorrat gespeichert. In der Langform sind die Zeilen im JSON-Format abgelegt, in der ca. nur ein Drittel umfassenden Kurzform nur jeweils die drei genannten Werte. Es ist Ansichtssache, welche der beiden Formen hier "die bessere" ist.

Beispiel: {"time":"2021-07-18T14:24:00","Temperatur":"18.5","Wasservorrat":"3561"} bzw. 20210718142400 18.5 3561

Die Dateien liegen in einem Verzeichnis-Teilbaum des Node Red Host. Unterverzeichnisse werden gemäß des benutzerdefinierten Topics aufgebaut und die Daten darin abgelegt. Sie erhalten den Namen "proc" von processed, gefolgt vom Triggerereignis und in der Kurzform den Suffix ".short". Aus dem Systemtrigger "limit" wird zwecks Differenzierung beim Senden entweder der Trigger "below" oder "above".

Beispiele: proc.sample, proc.differ, proc.below.short

Entsprechend bei Bedarf für die Rohwerte raw.sample ...

Node Red Flow zum speichern der Messwerte

Mittlerweile steht auch eine Node Red Webseite für die Grafiken zur Verfügung (s.u.). Der linke Teil zeigt die Einstellbarkeit des Zeitrahmens für die Grafiken. Ein Klick/Touch auf "STANDARD" aktiviert den von mir definierten Standard-Zeitrahmen. Dieser umfasst die letzten 4 Tage bis zum aktuellen Datum. Mit "GRAFIKEN NEU" werden die Grafiken zum eingestellten Zeitrahmen neu dargestellt. Rechts davon sind die Grafiken zu sehen. Diese vier Teile werden auf einem Smartphone im Senkrechtbetrieb untereinander angeordnet. Die beiden Grafiken zum Wasservorrat unterscheiden sich, ihre Datenbasis betreffend. Die erste ("für die Übersicht") entnimmt die Daten aus "sample"-Speicherungen, also feste Abtastrate bspw. stündlich. Die zweite ("für genauere Betrachtungen") entnimmt die Daten aus "differ"-Speicherungen, also auf Grund von Volumenänderungen. Diese zweite Grafik zeigt per Punkten die Stellen auf, an denen eine hinreichend große Füllstandsänderung registriert wurde. Nur der letzte Punkt ist an Hand der letzten Messung hinzugefügt, damit die Grafik dort etwas verständlicher wirkt. Die Angaben an den horizontalen Zeitachsen haben das Format DD-HH, also zweistelliges Tagesdatum, Bindestrich, zweistellige Tagesstunden - nur in der mittleren Grafik sind die Minuten per Format DD-HH:mm hinzugefügt. Die aus "differ" Speicherung generierte mittlere Grafik bietet ohne feste Abtastrate eine zeitlich dynamische und bei Änderungen feinere Auflösung. Für die feste "sample"-Abtastrate empfehle ich mindestens halbstündlich und höchstens zweistündlich. Letztlich kann dies, wie auch die "differ"-Änderungsschwellen, weitestgehend frei über Parameter konfiguriert werden.

 

Änderungsprotokoll, Analysen

Dieser Abschnitt ist wegen des steigenden Umfangs nach Zisternenmessungen Tagebuch ausgelagert.

Ideen und Vorhaben

Archiviert (Schublade): Kleine KI zwecks Selbstoptimierung - kommt wegen des dynamischen arithmetischen Mittelwertes (s.o.) nicht zum Zuge

Die einzige Erkenntniskonstante ist die Unwissenheit. wink Falls dies noch niemand gesagt oder geschrieben hat, nehme ich die Urheberrechte in Anspruch. laughing Hmm, vielleicht sollte ich den Spruch zurückziehen. embarassed

Die bisherigen Analysen zur Bereinigung der Abstandsrohwerte einer Messung haben mich nun doch dazu angeregt, eine kleine KI - oder auch interne Regelung - vorzusehen

Definitionen für die KI:

  • Dist = distances, geordnete Liste an Abstandsrohwerten, auch fehlerbehafteten
  • R = raw value, Rohwert - davon gibt es zu jeder Abstandsmessung mindestens 3. R ist Element aus Dist.
  • M = Mittelwert, das ist der irgendwie ermittelte Mittelwert, hier der Median- oder (Median+1)-Wert, also nicht der theoretisch auch mögliche arithmetische Mittelwert, welcher hier aber ungeeignet ist.
  • T = tolerance, Toleranz als Benutzer definierter Parameter, an Hand dessen festgestellt wird, ob ein Wert ein Fehlerwert ist. Dann und nur dann, wenn |M-R|>T ist, wird R als Fehlerwert kategorisiert.
  • Rn = raw value number, Anzahl an Abstandsrohwerten je Messung. Ich lege aus naheliegenden Gründen fest, dass Rn immer ungerade ist und mindestens 3 beträgt - Rn ist ein Element aus {natürliche Zahlen mit Rn >=3 und Rn mod 2 = 1}.
    Rn ist derzeit ein einstellbarer Parameter. Dies soll zunächst auch so bleiben, wird aber voraussichtlich ein persistenter Nur-Lese-Parameter.
  • Pd = position difference, Positionsabstand zwischen dem Mittelwert (Median oder Median+1) und dem in Dist nächstgelegenen Fehlerwert.
  • Pdc  = position difference critical, kritischer Positionsabstand, den ich voraussichtlich mit 1 festlegen werde, Werte <1 sind sinnfrei, Werte >1 sind vermutlich nicht erforderlich.  Ein Pd-Wert <1, also 0, besagt, dass der Mittelwert ein Fehlerwert ist und ist somit sinnfrei. Somit ist Pd eine natürliche Zahl (ohne die Null).

Wirkungsweise der KI:

Zu jeder Messung wird der Positionsabstand Pd zwischen dem Mittelwert M und dem in Dist nächstgelegenen Fehlerwert ermittelt.
Ist Pd<=Pdc, dann ist Pd kritisch und Rn wird um 2 erhöht.

In dieser ersten Fassung ist die KI eine Einbahnstraße (unidirektional). Rn kann nur größer, aber nie kleiner werden. Wenn sich diese KI bewährt, werde ich in einer zweiten Fassung diese KI bidirektional implementieren und ausgiebig testen.

Vorhaben: Nutzung von 3 "limit"-Parametern

Zur Sicherheit im Falle einer Wasserzuführung, ob per Regen oder per Leitungswasser, könnte ein dritter "limit"-Parameter in Liter ohne Hysterese für eine als "voll" definierte Zisterne dienen. Dazu braucht es einen weiteren Textparameter, der die zu sendende MQTT Nachricht bei voller Zisterne beschreibt. Diese Nachricht muss in "limit"-Zeitabständen, bspw. alle 2 Minuten, gesendet werden, solange die Zisterne als voll gilt. Dies erfordert einen kleineren Umbau in der Nutzung der Mem<x> Variablen und zweckmäßigerweise eine weitere kleine Berry-Datei für die Benennungen (Spracheinstellungen, eigene Benennungsvorlieben) der Nutzwerte, um deren Vorbenennungen "temperature" und "water reserve" zu überschreiben.

Vorhaben: Nachricht bei Wartungsbedarf

Die simple, inzwischen implementierte KI zum dynamischen arithmetischen Mittelwert erkennt, dass ein Parameter zweckmäßigerweise zu ändern ist und tut dies. Das kann dazu genutzt werden, eine spezielle Nachricht zu senden. Diese soll auf eine (nichtgeplante) erforderliche Wartung hinweisen.

Als Topic-Detail sehe ich "exc" von exception (Ausnahme) vor. Die Payload ist zunächst als einfacher String (Text) geplant, vielleicht mit dem Inhalt "Viele Messfehler! Wartung erforderlich.".

Alternativ kann als Detail das relativ allgemeine "log" verwendet werden. Dann sollte die Payload im JSON-Format gestaltet sein, bspw. so: {"exception":"Viele Messfehler! Wartung erforderlich."}

Zum Testen werde ich eine solche Situation künstlich hervorrufen müssen. Im Normalfall wird sie vermutlich nie oder sehr selten auftreten.

nach oben