Bewässerung relativ betriebssicher

2026-07-21

Unser Bewässerungsprojekt wird von zwei Personen getragen. Die Anwenderin nutzt die Anlage sehr ambitioniert und trägt ihre Aspekte bei. Ich, der Entwickler, stelle die Anlage zusammen und kreiere geeignete Skripte. Hierbei achte ich auf hohe Betriebssicherheit im Rahmen dessen, was die Shelly Geräte bereitstellen. Wesentlich dabei ist, dass eine solche Anlage mit Hilfe eines Web Browsers uneingeschränkt nutzbar ist - auch bei ausgefallenem bzw. nicht vorhandenem Netzwerk.

Somit kann eine solche Anlage bspw. per Smartphone/Tablet ohne sonstige Computeraustattung  und ohne dafür zu installierende App genutzt werden.

Hierzu nutze ich weitgehende Möglichkeiten der Shelly Firmware, insbesondere das WebUI und virtuelle Komponenten. Ein bisher auf einem Shelly Pro 2 konfiguriertes WebUI als Frontend zeigt die folgende Abbildung.
Wichtig: Das Parametrieren der Bewässerungen kann auch via übergeordnetem System oder Shelly Smart Control App / Cloud erfolgen. Sie sind aber nicht erforderlich, weil die Anlage autonom arbeitet. Deshalb ist auch eine externe Steuerung unzweckmäßig.

Die Nutzung dieses WebUI ist rein optional, es steht aber immer zur Verfügung - auch dann, wenn (temporär) kein anderes Frontend verfügbar ist. Wir nutzen bevorzugt die Android App MQTT Dash als Frontend. Wenn jedoch das Netzwerk oder der MQTT Broker ausfallen sollte, kann noch das obige WebUI genutzt werden - bspw. über den Shelly eigenen Access Point und die IP Adresse 192.168.33.1.

Mit diesem passend konfigurierten WebUI und meinem Shelly Skript bzw. Skripten können

• jeweils in einer Eingabe-Textzeile alle derzeit nutzbaren Anwendungsparameter eingestellt und
• jeweils in einem nur-lesen Feld das aktuell gemessene Volumen gelesen werden.
  Hier denke ich über weitere Ausgaben in einem nur-lesen Textfeld nach.

Die Eingabezeile muss eine Liste an Komma separierten Name:Wert Paaren beinhalten. Die Namen können leicht nach Bedarf geändert werden, was sowohl im Default Wert der virtuellen Textkomponente als auch in einer Skriptzeile zu erfolgen hat. Die Reihenfolge der Name:Wert Paare ist beliebig.

Beispiel: Dauer:10,Volumen:15,Regelung:1,Sensor:4,ein:60,aus:64,Sperre:120

Dauer:10 → Die Einschaltdauer/Bewässerungsdauer wird vom Skript auf 10 Minuten begrenzt.
Volumen:15 → Das Wasservolumen einer Bewässerung wird auf 15 Liter begrenzt.
Regelung:1 → Die Erdfeuchtigkeitsregelung ist aktiv - bei 0 inaktiv.
Sensor:4 → Die Messwerte von Sensor 4 werden für die Regelung verwendet.
ein:60 → Bei Unterschreitung von 60% Bodenfeuchtigkeit (interpretierbar) wird die Bewässerung eingeschaltet.
aus:64 → Bei Überschreitung von 64% Bodenfeuchtigkeit (interpretierbar) wird die Bewässerung ausgeschaltet.
Sperre:120 → Das jeweils nachfolgende Einschalten per Regelung wird 120 Minuten lang verhindert (blind time).

Werden solche Parameterwerte auf anderem Wege gesetzt, bei uns via MQTT Dash, so erscheinen diese sofort auch auf dem WebUI und umgekehrt. Nach einer Änderung zumindest eines Parameters wird die gesamte Liste auf Validität geprüft. Bei Invalidität wird die Änderung verworfen. Ob die Parameterliste valide ist, wird in einer kleinen Funktion geprüft, die leicht für eigene Zwecke angepasst werden kann. 

validate: function(v) {
  return v[0]>=0 && (v[1]===null || v[1]>=0) && v[3]>=1 && v[3]<=8 && v[5]>=v[4]+1 && v[6]>=0;
}

v wird als Array importiert. Die Indizes der Werte korrespondieren mit denen des Namen Array - s. Keys unten. v[0] ist der "Dauer" Wert, v[1] der "Volumen" Wert ...
Beispielsweise muss der "aus" Wert um mindestens 1 über dem "ein" Wert liegen, erkennbar an v[5]>=v[4]+1.

Die Skriptzeile für die Parameternamen hat folgenden Inhalt.

Keys: ["Dauer","Volumen","Regelung","Sensor","ein","aus","Sperre"]

Die Reihenfolge der Namen muss, anders als in der Eingabezeile, semantisch beibehalten werden. Die Namenseinträge sind beliebig gestaltbar. Diese Namen müssen in der WebUI Eingabezeile verwendet werden, weil im Skript die Zuordnung der Parameterwerte über deren vorangestellten Namen erfolgt.

Beispiel: Wer das Englische bevorzugt, mag diese Skriptzeile folgendermaßen gestalten.

Keys: ["duration","volume","control","sensor","on-threshold","off-threshold","blind-time"]

Nachteil: Die Eingabezeile ist nicht DAU sicher.

Vorteil - mitunter zwingend:
Bei zwei Ausgangskanälen (= zwei Bewässerungssträngen) werden insgesamt 4 bis 10 virtuelle Komponenten benötigt. Diese sind aber auf eine Anzahl von 10 je Shelly Gerät begrenzt. Deshalb sind einzelne virtuelle Komponenten je Parameter für die derzeit genutzte Anzahl von bis zu 7 Anwendungsparametern nicht nutzbar. Nur dafür wären bereits bis zu 16 virtuelle Komponenten erforderlich.

Bei insgesamt 10 virtuellen Komponenten auf einem Shelly Pro 2 werden folgende Daten angezeigt.

• Bewässerungsparameter als Eingabe-Textzeile, interaktiv
• Erdfeuchtigkeitswert vom selektierten Sensor, View=Label nur lesbar
• Aktuell gemessenes Volumen während einer Bewässerung, View=Label nur lesbar
• Finales Gesamtvolumen am Ende einer Bewässerung, View=Label nur lesbar

Zusammen mit der erforderlichen Gruppe (virtuelle Komponente) sind das 5 virtuelle Komponenten je Kanal. Man kann jederzeit die eine oder andere virtuelle nur-lesen Komponente entfernen bzw. weglassen. Diese dienen ausschließlich der Anzeige im WebUI und sind für die Funktionalität nicht erforderlich.

Die Anzahl an Anwendungsparametern ergibt sich aus der Zusammenstellung der Bewässerungsanlage - bspw. mit oder ohne Volumenmessungen - und den Wünschen der Anwenderin. Die Parameterliste ist für folgende Ausstattung geeignet.

• Schaltender Shelly (Master) mit WebUI und virtuellen Komponenten, hier mit zwei Ausgangskanälen (Pro 2)
• Ein oder zwei messende Assistenten (WebUI nicht erforderlich) zur Volumenmessung (Shelly Plus UNI)
• Erdfeuchtigkeitssensoren für eine Feuchtigkeits-Zweipunktregelung zur Bewässerungsautomatik.
  Diese Automatik greift in unserem Falle nur über MQTT-Kommunikation. Bei leitungsgebundenen Sensoren könnte das Shelly Plus UNI (ohne MQTT) verwendbar sein. Wegen unterschiedlicher Sensortypen können im Master-Skript Anpassungen erforderlich sein. Mein Skript ist derzeit auf Ecowitt WH51 Funksensoren und MQTT spezialisiert. Hierfür ist nur eine einzige Skriptfunktion zuständig, was die Anpassbarkeit auf andere Sensoren und Kommunikationen unterstützt.

Das Skript ist weitgehend servicefreundlich zusammengestellt. Ein Konfigurationsblock zu Beginn erlaubt einige Anpassungen im Skript. Bei vorhandenen ShellyScript Kenntnissen kann das Skript auch relativ leicht erweitert werden.

Positiver Nebeneffekt bei Verwendung von virtuellen Komponenten
In der Konfiguration solcher Komponenten können diese bei Systemstart (Reboot) mit dem Defaultwert oder alternativ mit dem persistent gespeichertem Wert bestückt werden. Bei persistenter Nutzung bleiben die zuletzt eingestellten Parameter auch bei Stromausfall erhalten.

Herstellen einer hohen Betriebssicherheit

Hier sind insbesondere die Parameter zu beachten, die zum Ausschalten (= absperren des Wasserflusses) führen. Zunächst kann und sollte der Anwender hierfür die vorgesehenen Grenzwerte von "Dauer", "Volumen" und "aus" nutzen - letzterer ist die Ausschaltschwelle bei Regelung. Bei aktiver Regelung (Regelung:1) können die Werte für Dauer und Volumen so gewählt werden, dass beide eine Ausschaltsicherheit bieten, falls die Regelung ausfallen sollte - bspw. weil der gewählte Sensor ausgefallen ist.

Zusätzlich kann der Auto OFF Timer so gesetzt werden, dass die Einschaltdauer zusätzlich begrenzt wird.  Die Volumenbegrenzung verwaltet der Mess-Assistent (Plus UNI) autonom und lässt bei Überschreitung des Volumengrenzwertes (Anwendungsparameter) den Master via HTTP und RPC Methode abschalten. Beide Begrenzungen wirken auch bei ausgefallenem Master-Skript, solange die Firmware des schaltenden Shelly störungsfrei arbeitet.

Der Assistent ist per WLAN direkt mit dem Master verbunden, via AP des Master. Solange deren internes WLAN funktioniert, können beide miteinander kommunizieren.

Im Skript steht ein aktivierbarer Watchdog-Timer zur Verfügung. Dieser schaltet beide Ausgänge ab und deaktiviert die Regelung, wenn bspw. innerhalb 3 Minuten kein Feuchtigkeitswert empfangen wird. Wir brauchen diesen Watchdog nicht, weil die Anwendungsparameter ausreichen.

Eine bereits erprobte, separate, Skript basierte Erweiterung zur Zeitplan gesteuerten Überwachung der beiden Skripte kann hinzugefügt werden - sowohl auf dem Master als auch auf dem Assistenten. Diese gestattet bei Skriptstop sowohl eine Messenger-Benachrichtigung via callmebot.com als auch alternativ eine lokale Protokollierung in einem nicht ausführbaren Skript Slot. Damit können Ausfälle komfortabel registriert werden.

Integrität des finiten Volumens

Der Master (schaltender Shelly, hier Pro 2) soll die Kommunikation mit der Außenwelt betreiben, in unserem Fall per MQTT. Der Assistent (Volumen messender Shelly Plus UNI) soll ausschließlich intern mit dem Master kommunizieren. Diese Vorgabe wird durch die Verarbeitung des gemessenen Volumens an einer Stelle gestört. Der Assistent muss eigenständig feststellen, wann die Messung beginnt und wann sie endet - an Hand der (nicht mehr) eintreffenden Impulse am Zähleingang Input(2). Erst mit dem Ende steht fest, wieviel Volumen während einer Bewässerung geflossen ist. Der Master kann dies nicht feststellen. Es gibt folgende Möglichkeiten, das finite Volumen zu kommunizieren.

1. Auf dem Master wird eine virtuelle nur-lesen Komponente für das finite Volumen eingerichtet, dessen Wert der Assistent setzt. Per Event Handler "on change" erfasst der Master eine Änderung des Wertes und kommuniziert diesen Wert nach außen. Dies gelingt dann nicht, wenn sich der Wert gegenüber der vorhergehenden Bewässerung nicht ändert, was erfahrungsgemäß sehr oft der Fall ist. Das stört solange nicht, wie dafür ausschließlich eine statische Anzeige genutzt wird. Sobald das finite Volumen incl. Zeitstempel in eine Datenbank fließen soll, ist diese Implementation ungeeignet, weil so das finite Volumen einer Bewässerung nicht in die Datenbank gelangt - und nicht in einer Visualisierung erscheint.
2. Der Master stellt eine Funktion sendVolFin(value) zur Verfügung, die via Methode "Script.Eval" vom Assistenten aufgerufen wird. sendVolFin kommuniziert den empfangenen Wert nach außen. Dies erscheint eher umständlich, wahrt aber meine Vorgabe, dass ausschließlich der Master nach außen kommunizieren soll.
3. Der Assistent kommuniziert für das finite Volumen (ausnahmsweise) nach außen. Dies verletzt meine Vorgabe, hat aber einen entscheidenden Vorteil. Der Wert wird auch dann kommuniziert, wenn das Master Skript zwischenzeitlich ausfällt. Zusätzlich ist dies sehr einfach zu implementieren. Allerdings müssen im Assistenten Skript dafür Kommunikationsparameter abgelegt werden, die zu denen des Master passen - zwei Stellen, die bei Änderungen zu pflegen sind, was etwas verschlechterte Servicefreundlichkeit nach sich zieht.

Ich entscheide mich für die dritte Variante. Man beachte, dass dies ein privates, individuelles, nicht vermarktetes Produkt ist.

Das Timerlimitproblem

In der Shelly API Dokumentation steht unter Resource Limits "No more than 5 timers used in a script;". Ob sich dieses Limit auf jedes einzelne Skript oder alle Skripte eines Shelly Gerätes bezieht oder ob nicht mehr als 5 Timer parallel laufen können, erscheint mir nicht eindeutig. Ich muss mit dem ungünstigsten Fall kalkulieren. Es ist möglich, dass alle Timer gleichzeitig laufen.

Zur Implementation der temporären Regelungssperre (via blind time respektive "Sperre" Parameterwert) ist je Kanal ein Timer erforderlich. Ein weiterer Timer je Kanal dient dem Komfort, auch über MQTT die relative Restdauer angezeigt zu bekommen und kann bei dringendem Bedarf entfallen. Bei zwei Kanälen ergibt dies 4 Timer, zumindest aber 2. Bei aktivem Watchdog kommt ein Timer hinzu, was bereits bis zu 5 parallel laufende Timer ergeben kann. Damit wäre das Timerlimit erreicht.

Entwicklungsstatus

Eine Alpha Version der Skripte arbeitet seit einigen Wochen erfolgreich im produktiven Einsatz.

Das Master-Skript ist fertiggestellt und wird derzeit mit, via Skript simuliertem, Assistenten ausgiebig und trocken getestet. Dies erfolgt unter Nutzung von Datenbankspeicherungen (InfluxDB2) und Visualisierungen (Grafana), um relativ langzeitliche Tests verfolgen zu können.

Das Assistent-Skript der Alpha Version muss für die Beta Version (oder Release?) noch ein wenig angepasst werden.

Sobald diese Testphase abgeschlossen ist, werde ich es wagen, die Skripte irgendwo hier zu veröffentlichen.

Eine ausgebaute Beta Version ist inzwischen fertiggestellt und im produktiven Einsatz.

Die Skripte sind im folgenden veröffentlicht, allerdings nur sequenziell. Demnächst will ich ein Archiv mit allen Skripten zum herunterladen anbieten. Vielleicht schaffe ich es irgendwann, dazu eine Installationsanleitung zu schreiben. 🙄

Die aktuellen Skripte stehen in einem anderen Beitrag zum herunterladen als ZIP-Archiv bereit.