Bewässerung optional mit Volumenmessung

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 erfolgen. Werte abhängig führt eine der beiden Einstellungen zum früheren ausschalten als die andere. Es werden Shelly Pro 2 mit LAN Kopplung genutzt. Für optionale Volumenmessungen werden Shelly Plus UNI mit Sensoren YF-S201 eingesetzt. Der Wasserfluss wird mit 12V DC an Motor getriebenen, selbst schließenden Ventilen gesteuert. Ein Prototyp dieser Geräte-Kombination wird bereits erfolgreich genutzt.

2026-06-22

Hier stehen weniger Messungen als vielmehr bedarfsgerechte Parametrierungen von Bewässerungen im Vordergrund.

Im Hochbeet stecken mehrere Feuchtigkeitssensoren ECOWITT WH51, mit welchen im fortgeschrittenen Stadium eine Automatisierung dieser Bewässerung erprobt werden soll.

Inhalt

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

1. Projektziele

1. Eine eingeschaltete Bewässerung wird ausgeschaltet
   1. nach Ablauf der eingestellten Dauer,
   2. nach überschreiten des eingestellten Volumens oder
   3. manuell ad hoc.
2. Das Schalten gelingt unabhängig vom Auslöser immer auf gleiche Weise.
3. Als Auslöser können genutzt werden
   1. am Shelly Pro 2 angeschlossene Schalter oder Taster - bisher nicht implementiert,
   2. das Web UI des Shelly Pro 2,
   3. die Shelly Smart Control App,
   4. eine Nachricht via MQTT oder HTTP,
   5. ein Sprachbefehl via Sprachassistent und Shelly Cloud,
   6. ein oder mehrere Zeitpläne (= Schedule Jobs).
4. 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.
5. Optional: Bei zu geringer Bodenfeuchtigkeit im Zielgebiet (Hochbeet, Garten, ...) soll eine Bewässerungsautomatik greifen.
6. Optional: Alle Bewässerungen, Bodenfeuchtigkeitswerte und ggf. Bewässerungsvolumina werden in einer Zeitreihendatenbank (bspw. InfluxDB 2) gespeichert. Dies und die Visualisierung der Daten via Grafana ist bereits implementiert. Die damit erkennbaren Erfahrungswerte unterstützen zielführende und sparsame Bewässerungen.
7. Alle steuernde 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. Wasseranschluss

Die folgende Abbildung zeigt die Teile des Wasseranschlusses. 

3. Mensch-Maschinen-Schnittstellen zum einstellen, auslösen und anzeigen, insbesondere via MQTT (s.a. Ziel 3.4)

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 alle MQTT Nachrichten in diesem Projekt keine zirkularen Probleme verursachen, 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 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.

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 alle verfügbare Kacheln. Der aktuelle Prototyp dient der Bewässerung unseres Kirschbaumes.

• "Baum" 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 "beim abschalten" wird das gemessene Volumen angezeigt, das zum ausschalten führte. Dies kann zur Ermittlung eines geeigneten Differenzwertes in der Abschaltbedingung xtotal>=xmax-Diff genutzt werden.
• 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.

Nach erfolgreichem Festlegen des Diff Wertes kann die Kachel "beim abschalten" entfernt werden. An den im Screenshot sichtbaren Werten ist erkennbar, dass das maximale Volumen auch bei diesem kleinen Wert von 3 Liter mit nur kleiner Abweichung erreicht wurde. Es handelt sich um einen 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)"

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.

4. 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 von max. Bewässerungsdauer und max. Bewässerungsvolumen. Die Id Werte beider Komponenten (201, 202) sind für die Skriptergänzungen zwingend erforderlich.

Beide Komponenten sind einer Gruppe, hier "Baumbewä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 zusätzlich einzurichtenden Aktionen wird der geänderte Wert an das Skript auf dem passenden Zielgerät übertragen - Dauer -> Master, Volumen -> Slave. So können beide 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.

5. 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.

6. Obligatorische Skripte

Auf beiden beteiligten Shelly Geräten, Pro 2 und Plus UNI, arbeitet jeweils ein Shelly Skript.

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.

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. 

7. 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 Ausschalten unterliegt folgenden anwendungsbezogenen 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 "off"=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. Für die Anwendung sollte also bekannt sein, dass beide anwendungsorientierte Einstellwerte (Dauer und Volumen) Maxima sind, von denen mit jeder Bewässerung realistisch eines wirken wird. Das im Regelfall nicht zur Geltung kommende Maximum wirkt nur dann, wenn das andere Maximum nicht zum abschalten führte, aus welchen Gründen auch immer.

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.

8. 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.

9. 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. 

10. 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 ---