Vielen Dank HoerMirAuf .
Ich las mit Freude deine Reaktion, da ich mit keiner Reaktion rechnen musste.
Deine Idee eines auf MQTT aufgesetzten eigenen Protokolls hat bei mir eine weitere Idee gebären lassen, die aber leider gegen mein Konzept (s.u. 2.) verstößt.
Zu deiner Anregung:
- Es sind nicht Messdaten, die ich vermisse. Wenn da mal ein Datensatz nicht gespeichert wird - btw inzwischen in einer InfluxDB Datenbank, dann stört mich das nicht.
Es ist eine Hysterese bedingt einmalig gesendete Steuerungsnachricht, die nicht verloren gehen soll.
Konkret: Wenn ein Benutzer definiertes Minimum des Wasserstandes unterschritten wird, wird eine Nachricht zum öffnen des Wasserzulaufs gesendet. Diese Nachricht ist tatsächlich Benutzer definiert. Trägt der Anwender dafür nichts ein, wird auch nichts gesendet. Das Öffnen des Wasserzulaufs ist ein beispielhafter Parameterwert in der von mir implementierten Konfiguration. Bei Überschreitung des Benutzer definierten Maximums wird auf entsprechende Weise eine andere Benutzer definierte Nachricht gesendet. Da diese Ereignisse, Unterschreitung Minimum und Überschreitung Maximum, eine relativ hohe Bedeutung haben, sollten sie, anders als Messwerte, nicht verloren gehen können. Der Vergleich mit der Temperaturüberwachung in einem Motor mag dies verdeutlichen.
(Nebenbei angemerkt nutze ich TelePeriod in meinem Messsystem nicht.) - Mein Messsystem Konzept beinhaltet eine hohe Flexibilität in der Anwendung und demzufolge in der Konfiguration. Bezüglich o.a. Benutzer definierter Nachrichten bedeutet dies, dass im System keine Kenntnis über die Wirkung der Nachrichten vorliegen kann. Ich mag solche hohen Flexibilitäten, das ist evtl. mein Manko.
Vielleicht sollte ich bei Unterschreitung des Minimums die Einmaligkeit des Nachrichtsendens verlassen. Dann bliebe aber das Problem immer noch bei der Überschreitung des Maximums. Also komme ich womöglich nicht an einem Protokoll vorbei, das ähnlich dem von dir aufgezeigtem sein könnte.
Nachdenken erforderlich ... brainstorming ... mal sehen.
Wie dem auch sei, nochmals vielen Dank für deine Reaktion.
Nachtrag:
Ich setze einen Raspberry Pi 4 mit 8 GB RAM und dem Raspberry OS lite ein. Auf diesem werkeln der MQTT Broker, Node-RED, InfluxDB und Grafana. Das System läuft seit dem 2021-08-29 stabil. Mein Messsytem besteht aus einem ESP32 Board mit Tasmota32 und in Berry geschriebener Anwendungsschicht incl. nativer Rules. Auch das Messsystem arbeitet zuverlässig - bis auf die vermisste QoS 2.