Bewässerung optional mit Volumenmessung

2026-07-11

Anlass/Motiv: Ein Hochbeet, ein kleiner Garten, ein Baum und ein neu eingesäter Rasen sollen mehr oder weniger automatisiert bewässert werden. Die Handhabung kann via Dauer- und optional Volumeneinstellung sowie Regelung der Bodenfeuchtigkeit erfolgen. Werte abhängig führt eine von bis zu drei Einstellungen zum ausschalten. Es wird mindestens ein Shelly 1 Generation 2+ benötigt. Für optionale Volumenmessungen werden Shelly Plus UNI mit Sensoren YF-S201 o.ä. eingesetzt. Der Wasserfluss wird mit 12V DC an Motor getriebenen, selbst schließenden Ventilen gesteuert. Vier unterschiedliche solcher Geräte-Kombinationen werden erfolgreich genutzt. In der Weiterentwicklung steht u.a. die Betriebssicherheit im Fokus.

Hier stehen bedarfsgerechte Parametrierungen von Bewässerungen im Vordergrund. Feuchtigkeitsmessungen können zur Regelung der Bodenfeuchtigkeit genutzt werden. In unserem Projekt steckt hierfür in einem Hochbeet mindestens ein Feuchtigkeitssensor ECOWITT WH51. Die Funktion dieser Bewässerungsanlagen erfolgt via Shelly Skripte autonom. Ein übergeordnetes System ist nicht erforderlich, kann aber Kommunikationsschnittstellen via MQTT oder HTTP nutzen. (Persistent speichernde) virtuelle Komponenten unterstützen die Verwendung des Shelly Web UI und etwas pfadaufwändiger die Shelly Smart Control App / Cloud.

Das ECOWITT Gateway veröffentlicht die Daten via MQTT - ca. minütlich alle Werte in einer einzigen Zeichenkette, deren benötigten Teile das schaltende Skript selektiert.

In unserer Anlage arbeitet ein Node-RED Flow zwecks Datenspeicherung, das Zeitreihendatenbanksystem InfluxDB 2 und Grafana zur Visualisierung. Diese Teile sind nicht notwendig, unterstützen aber die Erprobung und das zügige Annähern an geeignete Parametrierungen.

Inhalt

1. Projektziele
2. Skalierbarkeit
3. Wasseranschluss
4. Mensch-Maschinen-Schnittstellen
5. Nutzen des WebUI auf dem schaltenden Shelly
6. Aufgaben der beteiligten Geräte
7. Obligatorische Skripte
8. Wer triggert wann das Schalten?
9. Optionale Konfiguration des Shelly Plus UNI
10. Welche Funktion kann und sollte wo implementiert werden?
11. Bewässerungsautomatik

1. Projektziele

1. Das System arbeitet zwecks Minimierung der Ausfallwahrscheinlichkeit weitestgehend autonom.
   Kommunikationsschnittstellen stehen für andere Smart Home Komponenten bereit.
2. Das Schalten gelingt unabhängig vom Auslöser immer auf gleiche Weise.
3. Zum Eischalten können (alternativ) folgende Quellen genutzt werden.
   1. Taster/Schalter am zugeordneten Eingang des schaltenden Shelly,
   2. Web UI des schaltenden Shelly,
   3. Shelly Smart Control App / Cloud,
   4. Zeitpläne,
   5. RPC Aufträge via HTTP - bspw. via übergeordnetes System,
   6. MQTT Nachrichten und MQTT Dashboard oder übergeordnetes System,
   7. Sprachbefehl über Sprachassistent (Alexa u.a.),
   8. via Feuchtigkeitsregelung bei unterschreiten der eingestellten unteren Schwelle (Bodenfeuchtigkeitssensor erforderlich).
4. Eine eingeschaltete Bewässerung kann ausgeschaltet werden
   1. manuell ad hoc (Taster/Schalter, Web UI, Sprachbefehl, Dashboard eines übergeordneten Systems, Nachricht),
   2. bei Ablauf der eingestellten Dauer,
   3. bei überschreiten des eingestellten Volumens (Volumenmessung per Durchflusssensor und Shelly Plus UNI),
   4. via Feuchtigkeitsregelung bei überschreiten der eingestellten oberen Schwelle (Bodenfeuchtigkeitssensor erforderlich).
5. Es wird je Bewässerungsziel nur eine Dauereinstellung genutzt, also bspw. nicht die Timer Konfiguration des zugeordneten Ausgangs. Dies gestaltet die Einstellungen relativ einfach und verlässlich. Wer es unbedingt will, kann diese Vorgabe auf anderen Wegen stören, wovon abgeraten wird.
6. Optional: Bei zu geringer Bodenfeuchtigkeit im Zielgebiet (Hochbeet, Garten, ...) soll eine Bewässerungsautomatik greifen können.
7. Optional: Alle Bewässerungen, Bodenfeuchtigkeitswerte und ggf. Bewässerungsvolumina werden in einer Zeitreihendatenbank (hier InfluxDB 2) gespeichert. Dies und die Visualisierung der Daten via Grafana ist bereits implementiert. Die damit erkennbaren Erfahrungswerte unterstützen zielführende und relativ sparsame Bewässerungen.
8. Alle Anwendungs-Parameter können mit ungültigen Werten wie 0 (Null) als unwirksam eingestellt werden.

Die Messung der maximalen Fließgeschwindigkeit oder eines entsprechenden Mittelwertes während einer Bewässerung ist nicht vorgesehen. Bei Bedarf können hierfür die Werte der Pulsfrequenz am Zähleingang oder, zur Gewinnung des Mittelwertes, eine zusätzliche Erfassung der Einschaltdauer genutzt werden.

Eine sich von selbst realisierende Option ist die Fernsteuerbarkeit solcher Bewässerungen, insbesondere auf Grund von fernabfragbaren Bodenfeuchtigkeitswerten. Deshalb ist diese Option nicht als separates Ziel aufgeführt.

2. Skalierbarkeit

Eine solche  Bewässerungsanlage ist sowohl in der Hardware als auch in der Software (Shelly Skripte, übergeordnetes System) skalierbar. In der kleinsten Ausstattung kommt man ohne übergeordnetes System und ohne MQTT Broker aus, wobei die Parametrierungen über virtuelle Komponenten vorgenommen werden kann - via Web UI und/oder Shelly Smart Control App / Cloud.

Man kann mit einem Bewässerungsziel und reiner Zeitsteuerung (Dauer jedes Bewässerungsereignisses, Shelly Zeitpläne) starten. Mit mindestens einem kommunikationsfähigen Bodenfeuchtigkeitssensor - besser zwei Sensoren - lässt sich zusätzlich eine Regelung der Bodenfeuchtigkeit implementieren. Mit einer zusätzlichen Volumenmessung kann der Wasserverbrauch ermittelt und begrenzt werden.

Ich nutze MQTT Kommunikation, weil diese die Projektpflege sehr erleichtert. Insbesondere, wenn verschiedene Frontends eingesetzt werden ist diese Kommunikation mit retained publishings vorteilhaft, weil jedes Subscriber-Frontend sofort nach seiner Anmeldung am Broker die zuletzt veröffentlichten - und somit aktuellen - Daten erhält. Bei Bedarf kann stattdessen HTTP mit der RPC Methode "Script.Eval" genutzt werden.

3. Wasseranschluss

Die folgende Abbildung zeigt die Teile des Wasseranschlusses. 

4. Mensch-Maschinen-Schnittstellen zum einstellen, auslösen und anzeigen, insbesondere via MQTT

Dieses Projekt stellt mit Konfigurationen und zwei Skripten die parametrierbare Bewässerungsfunktion mit offenen Kommunikationsschnittstellen zur Verfügung. Wer diese Schnittstellen nutzen kann und will, kann sich sein Frontend dazu selbst zusammenstellen. Er kann über MQTT oder HTTP kommunizieren lassen. Für die HTTP Kommunikation kann die RPC Methode "Script.Eval" genutzt werden. Bisher liefern die nutzbaren Funktionsaufrufe allerdings keine Rückmeldungen.

Als Mensch-Maschinen-Schnittstelle bevorzugen wir die Android App MQTT Dash, mit welcher die Einstellungen und das ad hoc Schalten gelingt. Alternativ oder ergänzend kann jedes MQTT fähige, übergeordneten System dafür eingerichtet werden. Bisher nutze ich verschiedene Topics und ausschließlich Payloads mit einfachen Werten (kein JSON Format). Da keine der MQTT Nachrichten in diesem Projekt zirkulare Probleme verursacht, werden sie mit gesetztem retained flag gesendet. So erhält jeder MQTT Subscriber nach der Anmeldung am Broker unmittelbar die jeweils aktuell letzte Nachricht.

Via MQTT-, HTTP-RPC-Nachrichten - oder bei Bedarf via HTTP Request, derzeit nicht implementiert - sind folgende Handhabungen möglich.

• Einstellen der maximalen Dauer einer Bewässerung (-> schaltendes Shelly, hier Pro 2)
• Einstellen des maximalen Volumens einer Bewässerung (-> messendes Shelly, hier Plus UNI)
• Ad hoc starten oder beenden einer Bewässerung (-> schaltendes Shelly, hier Pro 2)
• Zeitgesteuertes Starten der Bewässerung via einzurichtendem Zeitplan auf dem schaltenden Shelly, bspw. alle 4 Stunden täglich. Bei genügender Feuchtigkeit oder zu erwartendem Regen kann ein solcher Zeitplan leicht deaktiviert werden und umgekehrt.
• Zur Zweipunkt-Regelung der Bodenfeuchtigkeit
  • Wahl des Feuchtigkeitssensors
  • Untere Feuchtigkeitsschwelle zum starten der Bewässerung
  • Obere Feuchtigkeitsschwelle zum beenden der Bewässerung

Der Schaltzustand jedes Ausgangs (= Bewässerung Ein/Aus) wird mit jeder Änderung gesendet und kann somit angezeigt werden.

Zum zeitgesteuerten Starten von Bewässerungen nach Zeitplänen (=Schedules) stehen die üblichen Schnittstellen Shelly Web UI und Shelly Smart Control App / Cloud zur Verfügung. Hier sollten keine Werte zu "Set Flip value after property" genutzt werden, damit die eingestellte Dauer (s.o.) ungestört bleibt.

Sowohl die relative Restdauer (in %) als auch das aktuell gemessene Durchflussvolumen werden von den zuständigen Skripten geliefert. Diese können im genutzten Frontend - MQTT Dash oder Dashboard eines übergeordneten Systems - angezeigt werden. Mit dem Ausschalten einer Bewässerung wird die relative Restdauer mit dem Wert 0 gesendet, das gemessene Volumen bleibt schließlich ohne Änderung stehen. Zusätzlich sendet das UNI Skript das zum Zeitpunkt des Ausschaltens gemessene Volumen, welches i.d.R. etwas unterhalb des gesamten Volumens liegt. Die Differenz zwischen beiden kann zur Anpassung im Skript (Diff Wert, s.u.) genutzt werden. Die Anzeige des Ausschaltvolumens dürfte vom Standardbenutzer als uninteressant und allenfalls störend empfunden werden.

Screenshot der MQTT Dash Oberfläche zur Bewässerung

Dieser Screenshot zeigt fast alle verfügbare Kacheln bei voll ausgebautem Bewässerungssystem, incl. Volumenmessung und Feuchtigkeitsregelung - hier zur Bewässerung unseres zweiten Hochbeetes.

• "Hochbeet-2" dient dem ad hoc Schalten der Bewässerung - sowohl ein als auch aus. Das Symbol repräsentiert den Zustand "Aus". Im Zustand "Ein" erscheinen dort Strichelchen zwecks andeuten von Regen ähnlichen Wassertropfen.
• Mit "max. Dauer" kann die maximale Dauer eingestellt werden.
• "verbleibend" zeigt während der Bewässerung die relative Restdauer in % an, in Stufen von 10%.
• Mit "max. Volumen" kann das etwa maximale Volumen eingestellt werden (-> xmax im UNI Skript).
• Unter "aktuell" wird der laufende, aktuelle Messwert angezeigt. Am Ende kann dieser Wert den Wert unter "gesamt" nicht überschreiten. Andernfalls liegt im UNI Skript ein logischer Fehler vor.
• Unter "gesamt" wird das Volumen angezeigt, welches am Ende des Messzyklus vorliegt. Das ist der letzte Wert von xtotal vor dessen Rücksetzen auf 0.
• Mit "Regelung Sensor" wird der für die Regelung zuständige Sensor festgelegt. Wird hier 0 eingetragen, ist die Regelung deaktiviert.
• Die beiden Schwellenwerte dienen der Zweipunktregelung für die Bodenfeuchtigkeit. Die zielführenden Prozentwerte hängen von der Bodenbeschaffenheit sowie der Wasseranlage ab und sind in Versuchen zu ermitteln.
• Mit "Latenz" kann die ambitionierte Anwenderin eine Mindestdauer zwischen zwei Einschaltereignissen via Regelung festlegen. Mit dem Einschalten via Regelung wird das nächste Einschalten via Regelung entsprechend gesperrt.
• Optional kann noch eine Kachel zum gemessenen Volumen hinzugefügt werden, das zum ausschalten führte. Dies kann zur Ermittlung eines geeigneten Differenzwertes in der Abschaltbedingung xtotal>=xmax-Diff genutzt werden.

Die gemessenen Volumina unterliegen einem zufälligen Fehler, weil die Abweichung von unkalkulierbaren Zuständen und Ereignissen abhängt wie aktueller Wasserdruck, Strömungsverwirbelungen im Sensor, Überschreitung von xtotal zum eingestellten Maximum. Abhängig von der gewünschten Kachelstruktur können auch "verbleibend" und/oder "aktuell" entfernt werden.

Bei großen Maximalvolumen ist eine vernachlässigbare Differenz zum gemessenen Gesamtvolumen zu erwarten, weshalb in solchen Fällen der festlegbare Diff Wert kaum ins Gewicht fallen dürfte.

Alle Kacheln zeigen aktuelle Zustände/Werte an, unabhängig von der auslösenden Mensch-Maschinen-Schnittstelle. Wenn die Bewässerung via Sprachbefehl oder der Shelly Smart Control App gestartet wird, kann dies bspw. in MQTT Dash beobachtet werden.

Damit die Einstellung der Dauer auf dem Shelly Pro 2 auch im Web UI zur Verfügung steht, habe ich dort für jeden Schaltausgang eine virtuelle Komponente vom Typ Number angelegt und mit dessen Änderung eine Aktion verbunden. Diese Aktion enthält via URL mit localhost und der Methode "Script.Eval" zwei Skriptanweisungen:
http://localhost/rpc/script.eval?id=1&code="Duration[0]=$value;sendDur(0)"

Statt einer solchen Aktion kann im Skript auf demselben Gerät ein Eventhandler verwendet werden.

Umgekehrt enthält das Skript Anweisungen, welche bei Änderung der Dauer im kleinen Datenfeld "Duration" automatisch die virtuelle Komponente auf den gleichen Wert ändert. So ist das Einstellen der (maximalen) Bewässerungsdauer auch im Web UI und der Shelly Smart Control App / Cloud möglich und erkennbar.

Mit weiteren Aktionen auf beiden beteiligten Shelly lässt sich eine Bewässerung auch aus dem Web UI des messenden Shelly Plus UNI starten. Dies ist allerdings kaum zielführend und eher ein Gimmick.

5. Nutzen des Web UI auf dem schaltenden Shelly (Master)

Mit ein wenig Zusatzaufwand und bei Eignung des Master für virtuelle Komponenten können letztere ohne MQTT zum parametrieren genutzt werden - schalten ist selbstverständlich immer via Web UI möglich. Damit kann diese Zusammenstellung auch ohne MQTT und ohne übergeordnetes System verwendet werden. Hierfür ist zusätzliche Kommunikation zwischen dem schaltenden Shelly (Master, hier Pro 2) und dem messenden Shelly (Slave, hier Plus UNI) erforderlich. Dafür ist das Slave Skript anzupassen.

Die obige Abbildung zeigt via Master Web UI angelegte virtuelle Komponenten zum parametrieren des Bewässerungsstrangs "Hochbeet-2". Die Key Werte der Komponenten (number:203 bis  number:207) sind für die Skriptergänzungen zwingend erforderlich.

Diese Komponenten sind einer Gruppe, hier "Hochbeet-2 Bewässerung", zuzuordnen, damit sie auf der Web UI Startseite für Anzeigen und Eingaben verfügbar sind. Die folgende Abbildung zeigt den entsprechenden Ausschnitt der Startseite.

Nach Änderung eines dieser Werte ist "Save" zu aktivieren, damit die Änderung wirksam wird. Mit Eventhandler oder zusätzlich einzurichtenden Aktionen wird der geänderte Wert an das Skript auf dem passenden Zielgerät übertragen - bspw. Dauer -> Master, Volumen -> Slave. So können Parameter via direkter HTTP Kommunikation auch ohne MQTT dem zuständigen Zielgerät zugeführt werden. Dieser Weg der Parametrierung ist inzwischen implementiert und getestet.

Hinweis: Auch via Shelly Smart Control App / Cloud können diese Parameter geändert werden, der Pfad zu den virtuellen Komponenten ist aber umständlich bzw. aufwändig zu finden.

Auf einem Shelly Pro 2 mit zwei voll ausgebauten Bewässerungssträngen ist die Anzahl an Benutzer definierten numerischen Parametern zu groß. Ich experimentiere stattdessen mit einer virtuellen Textkomponente zum parametrieren in Form einer Key-Value-Liste wie "Dauer:5,Volumen:20,Sensor:4,ein:30,aus:35,sperren:240". Mit einer einzigen virtuellen Textkomponente können mehrere/alle Parameter eines Bewässerungsstrangs festgelegt werden. Nachteilig ist, dass hierbei Benutzerfehler auftreten können.

6. Aufgaben der beteiligten Geräte

1. Das Shelly Pro 2 ist das schaltende Gerät für bis zu zwei Bewässerungsziele. Wenn nur ein Bewässerungsziel beabsichtigt ist, kann dafür jedes Shelly ab Generation 2 mit einem Schaltausgang genutzt werden. Ich bevorzuge Shelly Pro 2 wegen zweier Schaltausgänge, der relativ verlässlichen LAN Anbindung, der problemlosen Versorgung mit 230V AC und geschalteten 12V DC. Alle von mir bisher getesteten 12V Hutschienennetzteile stören Shelly Geräte via Funkwellen und/oder 12V DC Versorgungsspannungsspitzen auf nicht tragbare Weise.
   Der Access Point ist als aktiv konfiguriert, damit das Shelly Plus UNI sich mit diesem koppeln kann. Diese Kopplung hat sich als besonders robust bewährt, vermutlich deshalb, weil der Pro 2 AP nur ein oder max. zwei Plus UNI als Clients zu versorgen braucht. 
2. Das Shelly Plus UNI ist das messende Gerät zum zählen der von einem Durchflusssensor YF-S201 gelieferten Impulse. Hierfür wird der Zähleingang Input:2 des UNI genutzt. Ob zum zählen der YF-S201 Impulse auch ein digitaler Standardeingang Input:0 oder Input:1 via Skript nutzbar ist, wurde bisher nicht geprüft. Hierfür wäre zielführend, die maximal via Skript auswertbare Frequenz der diesen Eingängen zugeführten Impulse zu kennen. Für einen solchen Laborversuch fehlt mir die Ausstattung.
3. Der Durchflusssensor beinhaltet ein Flügelrad - offenbar mit kleinen Permanentmagneten, ein Hall-Element und Elektronik mit offenem Signalausgang (open Collector bzw. open Drain). Das Signal wird unmittelbar dem Plus UNI Zähleingang zugeführt. Der Sensor liefert ca. 450 Impulse je Liter Flüssigkeit. Für Tropfbewässerung bietet der YF-S201 einen etwas ungünstigen Messbereich, der bei 1 l/min beginnt. Ein Sensor YF-B13, dessen Messbereich bereits bei 0,3 l/min beginnt, ist für kleinflächige Tropfbewässerungen besser geeignet, allerdings mit ca. 20€ kostspieliger.

7. Obligatorische Skripte

Auf beiden beteiligten Shelly Geräten, Pro 2 und Plus UNI, arbeitet jeweils ein Shelly Skript. Insbesondere das Skript auf dem Pro 2 befindet sich noch in der Entwicklungs- und Testphase.

Shelly Pro 2 Skript

Das grundlegende Skript auf dem Pro 2 erfasst jedes Einschaltereignis und sendet einen Einschaltbefehl mit eingestellter Dauer (Parameter zu "toggle_after") unmittelbar danach an die Firmware. Somit wird immer spätestens nach dieser Dauer ausgeschaltet. Dies sorgt bereits für ein nutzbares Bewässerungssystem via Zeitsteuerungen.

Wenn eine Regelung der Bodenfeuchtigkeit (hier eine Zweipunktregelung) genutzt wird, erhält dieses Skript eine Erweiterung. Via MQTT Abonnement bekommt das Skript Bodenfeuchtigkeitswerte von mindestens einem Sensor. Wir nutzen in zwei Bewässerungslokationen (=Wassersenken) je zwei Sensoren Ecowitt WH51. Mit jeder MQTT Nachricht vom erforderlichen Ecowitt Gateway werden alle Daten von allen mit dem Gateway via Funk gekoppelten Geräten/Sensoren in einer relativ langen Zeichenkette geliefert. Das Skript selektiert daraus die erforderlichen Daten, bei uns gegenwärtig vier Bodenfeuchtigkeitswerte von je einem Sensor. Die Anwenderin legt für die Regelung folgende Parameter fest.

• Die Nummer (=Id) des zu nutzenden Sensors.
• Die untere Schaltschwelle, deren Unterschreitung zum einschalten des Ventils führt.
• Die obere Schaltschwelle, deren Überschreitung zum ausschalten des Ventils führt.
• Bei Bedarf eine Inaktivitätsdauer des Einschaltens via Regelung, die mit dem Einschalten via Regelung beginnt und i.d.R. zu selteneren automatisierten Bewässerungen führt. Dies kann zur Reduktion des Wasserverbrauchs oder zur zügigen Näherung an sparsame Schaltschwellen genutzt werden.

Die Schaltschwellen ergeben sich aus experimentell gewonnenen Erfahrungswerten. Dies wird in unserem Fall durch Aufzeichnungen und Grafiken unterstützt, s. folgende Abbildung.

Die jeweils in gelb dargestellten Zeitfunktionen zur Bewässerung unseres zweiten Hochbeetes zeigen

• wann ein- und ausgeschaltet wurde (oben),
• mit wieviel Volumen jeweils gewässert wurde (mittig),
• den Verlauf der zur Regelung genutzten Feuchtigkeits-Istwerte (unten).

Die in den Legenden aufgeführten "Last" Werte sind jeweils die zuletzt erfassten Werte, also die aktuellsten Werte. "Last" ist englisch zu interpretieren als "letzter Wert". Grafana erlaubt hier keine Namensänderung.

Shelly Plus UNI Skript

Zur (optionalen) Erweiterung durch Volumenmessung und -begrenzung ist ein Skript auf dem Shelly Plus UNI erforderlich. Experimente zeigten, dass der Firmware interne Zähler nicht während eintreffender Impulse rücksetzbar ist. Deshalb kann kein Rücksetzen des Zählers via Kommando vom schaltenden Pro 2 mit Beginn der Bewässerung genutzt werden, obwohl dies besonders zielführend wäre.

Das verwendete Skript erkennt eigenständig das Ende eines Messzyklus und setzt daraufhin den Zähler für eine irgendwann nachfolgende Messung vorbereitend auf 0 zurück. Zugleich mit dem Messende muss der Messwert der abgeschlossenen Messung gesendet werden. Dies ist leicht möglich, weil die Firmware das Zählerrücksetzen mit den bis dahin vorliegenden Zählwerten (total und xtotal) beantwortet. total beinhaltet den tatsächlichen Zählwert als natürliche Zahl. xtotal beinhaltet den anwendungsbezogenen Wert mit zugeordneter Einheit, welche beide Skript unabhängig konfiguriert werden können. Mein Skript nutzt den Wert von xtotal.

Das Ende eines Messzyklus wird derzeit via Timer erkannt. Mit jedem neu eintreffenden, geänderten Zählerstand wird der Timer neu gestartet. Den Ablauf des Timers nutzt das Skript, um den Zähler rückzusetzen und den letzten Zählerstand (vor dem Rücksetzen) zu übertragen - hier via MQTT.publish(). Ein angemessener Timerwert ("Latency" genannt), kann durch Versuche ermittelt werden. Mein Skript nutzt Latency = 10000 (=10s). Wenn 10s lang kein neuer Zählerstand eintrifft, wird dies als Ende des Messzyklus interpretiert.
Bedauerlicherweise lässt sich auf diese Weise der Endstand der letzten Messung weder im Shelly Web UI des UNI noch in der App/Cloud ablesen, weil am Ende des Messzyklus der Zähler auf 0 rückgesetzt wird.

Während jeder laufenden Messung wird Ereignis gesteuert der aktuell vorliegende Messwert (xtotal) mit dem eingestellten Wert zur Volumenbegrenzung (xmax) verglichen. Mit der ersten Überschreitung (xtotal >=xmax) wird einmalig ein remote Ausschaltbefehl an den schaltenden Shelly (hier Pro 2) gesendet. Die Messungen zeigten experimentell einen Nachlauf von bspw. ca. 1,3 Liter, weshalb ich im Skript einen festen "Diff" Parameter (hier Wert = 1.3) einbaute und den Vergleich ergänzte zu xtotal>=xmax-Diff. Der geeignete Diff Wert ist anwendungsbezogen zu ermitteln.

Eine nicht erprobte Alternative zur obigen Timer-Lösung

Das wirksame Einschalten der Bewässerung wird auf dem Pro 2 zeitverzögert. Dafür muss das dortige Skript nach erkennen des Einschaltens

1. sofort wieder ausschalten,
2. das Rücksetzen des Zählers auf dem UNI beauftragen - dies gelingt nur sicher bei Wasserstillstand, weshalb zuvor eine Zeitverzögerung via Timer erforderlich sein kann,
3. nach der vom UNI erhaltenen Zählerrücksetz-Rückmeldung die Bewässerung erneut mit dem "toggle_after" Parameter starten. Statt der UNI Rückmeldung kann ein weiterer (verschachtelter) Timer genutzt werden, damit die Bewässerung auch bei ausgefallenem UNI erfolgen kann.

Wegen des häufigeren Schaltens und der komplexeren Kommunikation bzw. Timernutzung und als Folge mindestens ein komplexeres Skript habe ich diese Alternative verworfen. 

8. Wer triggert wann das Schalten?

Eingeschaltet werden kann

• ad hoc bei Bedarf vom Anwender via Shelly Smart Control App/Cloud, Sprachanweisung oder WebUI des schaltenden Shelly,
• nach Zeitplänen - dabei sollte kein toggle_after Parameter genutzt werden,
• via Regelung bei unterschreiten der eingestellten unteren Feuchtigkeitsschwelle.

Das automatische Ausschalten unterliegt folgenden von der Anwenderin festgelegten Parametern.

• Dauermaximum
• Volumenmaximum
• obere Feuchtigkeitsschwelle bei aktiver Regelung

Das Shelly Pro 2 Skript nutzt Dauermaximum und obere Feuchtigkeitsschwelle. Es sorgt mit der RPC Methode "Switch.Set" und den Parametern "id" für den Ausgang, dem Zielzustand "on"=true zum einschalten, dem automatischen Ausschalten gemäß "toggle-after"=Dauermaximum. Zum Verständnis: Dauermaximum = Maximum der Einschaltdauer

Das Shelly Plus UNI Skript sendet während eines Messzyklus bei überschreiten des Volumenmaximum einmalig via HTTP GET eine RPC (Remote Procedure Call) Nachricht an das Shelly Pro 2 zum sofortigen Ausschalten des Zielausgangs.

Der früheste der möglichen Ereignisse - Dauer abgelaufen vs. Volumenbegrenzung überschritten vs. obere Feuchtigkeitsschwelle überschritten - triggert somit das Ausschalten. Das Dauerende wird von der Firmware genutzt, die Volumenüberschreitung vom UNI Skript und via Regelung das Überschreiten der oberen Schaltschwelle vom Pro 2 Skript. Für die Anwendung sollte also bekannt sein, dass alle anwendungsorientierten Einstellwerte (Dauer, Volumen. obere Schelle) Maxima sind, von denen mit jeder Bewässerung realistisch eines wirken wird. Das im Regelfall nicht zur Geltung kommende Maximum wirkt nur dann, wenn keines der anderen Maxima zum abschalten führte, aus welchen Gründen auch immer.

Beispiel:
Bei Feuchtigkeitsregelung erfolgt das Abschalten bei Überschreitung der obere Feuchtigkeitsschwelle nur dann, wenn nicht zuvor die eingestellte Dauer abgelaufen ist oder das eingestellte Volumen überschritten wurde.

So bieten die Maxima-Parameter zusätzliche Sicherheiten für den Fall, dass Funktionsteile ausfallen.

Die folgenden Trigger können jeweils mit dem zugehordneten Parameterwert von 0 (Null) deaktiviert werden.

• Ausschalten bei erreichen der Einschaltdauer - 0 deaktiviert,
• Ausschalten bei überschreiten des Volumenmaximums - 0 deaktiviert,
• Regelung via gemessener Bodenfeuchtigkeitswerte - Sensor Id = 0 deaktiviert.

9. Optionale Konfiguration des Shelly Plus UNI

Die Messung via Zähleingang ist Skript unabhängig konfigurierbar. Der Name des Zähleingangs kann festgelegt werden. Im folgenden setzte ich dafür den vorgegebenen Standardnamen "Input (2)" ein.

• Home / Input (2) / Custom count expression
  Unter "Custom expression" kann der anwendungsbezogene Ausdruck editiert werden, hier bspw. x/450 - der Sensor liefert ca. 450 Impulse pro Liter Duchflussvolumen. Der gemäß Ausdruck berechnete Wert steht im Skript mit dem key "xtotal" zur Verfügung und wird im Web UI unter Input (2) am rechten Rand angezeigt, zusammen mit dem "Custom unit" Wert.
  Unter "Custom unit" kann die Einheit zu xtotal festgelegt werden, hier bspw. "Liter". Diese Einheit nutzt mein Skript nicht.
• Home / Input (2) / Frequency setting / Report threshold
  Unter "Pulses" kann der Wert an weitergezählten Impulsen festgelegt werden, der zum mitteilen des Zählerstandes an ein Skript führt. "Report threshold is the number of pulses the device counts before it reports hooks/actions, to scripts, mqtt or other side channels."
  Standardwert = 10. Dieser Wert legt u.a. die vom Skript erfassbaren Wertänderungen des Zählers fest, also die anwendungsbezogene Auflösung des Zählens. Je kleiner der Wert ist, desto zeitdichter (=hochfrequenter) erhält das Skript die Mitteilung, dass sich der Zählerstand geändert hat, zusammen mit diesem Zählerstand/Messwert (total/xtotal). Desto stärker beansprucht das Skript die Leistungsfähigkeit (=Performance) des Plus UNI.
  Für Bewässerungen mit geringer Fließgeschwindigkeit ist ein kleiner Wert zweckmäßig, bei hoher Fließgeschwindigkeit ein hoher Wert. Wir nutzen für eine Tropfbewässerung den Wert 1, für eine Baumbewässerung 10.

10. Welche Funktion kann und sollte wo implementiert werden?

Die Beantwortung dieser Frage ist teilweise Ansichtssache und hängt vom verteilten Kenntnisstand ab. Wer gerne sein übergeordnetes System zur Steuerung und Regelung nutzt, wird darin gerne Nachrichten der Shelly empfangen und die gewünschte Automatisierung implementieren. Dieses Projekt kann durchaus erfolgreich so umgesetzt werden.

Ich verfolge soweit wie möglich das Ziel der Geräte bezogenen Autonomie. In diesem Projekt arbeiten beide beteiligten Shelly Geräte autonom. Sie brauchen für ihren Einsatzzweck kein übergeordnetes System, senden aber Nachrichten, die ein übergeordnetes System zur Visualisierung nutzen kann. Dies sorgt für eine besonders geringe Ausfallwahrscheinlichkeit. Das Shelly Plus UNI verbindet sich mit dem Access Point des Shelly Pro 2, was deren Verbindung auch dann aufrecht erhält, wenn ein ansonsten genutzter WLAN Access Point ausfallen sollte.

Schließlich kann das Pro 2 Skript um einen HTTP Endpoint erweitert werden, damit die Parametrierungen (Dauer und Volumen) via WLAN Kopplung mit dem Shelly Pro 2 AP und HTTP (Web Browser) auch bei ausgefallenem Netzwerk noch gelingt. 

11. Bewässerungsautomatik

Diese Automatik arbeitet mit Sensorwerten von ECOWITT WH51. Derzeit experimentieren wir mit zwei solcher Sensoren in einem Hochbeet mit 2m² Grundfläche und einer Erdhöhe von ca. 70cm. Der Anwender kann die Id des maßgebenden Sensors wählen sowie beide Schaltschwellen für die via Skript implementierte Zweipunktregelung einstellen. Gültige Sensor Id Werte sind 1, 2, ... - mit Id = 0 wird die Regelung deaktiviert. Wir erhoffen uns nutzbare Erkenntnisse an Hand von Zeitfunktionsgrafiken (via Grafana und InfluxDB 2).

Bisher ist erkennbar, dass die Positionierung des maßgebenden Sensors wegen unserer Tropfbewässerung die Regelung wesentlich beeinflusst. Wir arbeiten daran - insbesondere der weibliche Hausvorstand nutzt die Parametrierung und die Grafiken ... ☺️

--- in Arbeit ---