Bewässerungssteuerung - Vorstellung und Ideensammlung

[FunkOdyssey]

Ich habe noch ein Verständnisproblem mit der Berücksichtigung des Regens.
Hat hier jemand ein Praxisbeispiel? Nutzt jemand dazu ein Wettermodul oder Ähnliches?
Danke für die Hilfe.

[Stefan_Hvr]

Ich habe noch ein Verständnisproblem mit der Berücksichtigung des Regens.
Hat hier jemand ein Praxisbeispiel? Nutzt jemand dazu ein Wettermodul oder Ähnliches?
Danke für die Hilfe.

Moin,
bisher noch nichts "schickes" gefunden. Die Wetterdaten bei uns in der Nähe weichen zu stark vom wirklichen Zustand ab. (Proplanta).
Über historische Daten habe ich mir aus zeitgründen noch keinen Kopf machen können.
Ich denke ich werde mich im Herbst mal damit beschäftigen  oder die Bodenfeuchte messen oder ne lokale Wetterstation einzubauen o.ä.
Zumindest die Meldung "israining" verspreche ich mir ab nächste Woche aus meinem Rasenmäher abfragen zu können.
BG Stefan

[JHo]

Ich habe noch ein Verständnisproblem mit der Berücksichtigung des Regens.
Hat hier jemand ein Praxisbeispiel? Nutzt jemand dazu ein Wettermodul oder Ähnliches?

Ich nutze für den Landroid das DWD-Modul und für die Bewässerung noch nach dem "alten" Code von den ersten Seiten meine eigene Wetterstation (also den Regenmesser der TFA Nexus --> weewx --> FHEM), und reingefrickelt für die Evapotranspiration und eine Regenprognose auch wieder das DWD-OpenData-Modul.
DWD liefert natürlich für den jeweiligen Ort recht schwankend zuverlässige Angaben, ist ja regional alles interpoliert. Je klarer die Wetterlage, umso besser sind die "Treffer" - Gewitter sind z.B. meist viel zu lokal, um mit mehreren Stunden Vorlauf recht zuverlässig für einen Ort angesagt zu werden. Das muss man immer im Hinterkopf behalten.

Zu deiner Frage: was ist denn genau unklar?
- Wenn es aktuell regnet und eine Bewässerung läuft, wird sie unterbrochen. Man weiß ja nicht, wie viel es noch regnen wird. Als Sensor habe ich aktuell meinen Regenmesser, der aber erst ab einer gewissen Menge anschlägt (hat eine Wippe, jeder Wechsel bedeuten 0,7 l/m²). Denkbar sind natürlich die Regenerkennung vom Rasenmäher (da der bei mir aber mit bewässert wird, kann ich ihn nicht nehmen) oder ein simpler Regenmelder z.B. über Jeelink.
- Wenn es bereits messbar geregnet hat, wird dieser natürliche Niederschlag von der zu bewässernden Menge abgezogen, d.h. entsprechend weniger bis nichts bewässert. Dafür ist der Regenmesser mit Wippe natürlich gut geeignet; Rasenmäher oder reinen Regenmelder kann man nicht gebrauchen.

Wie erwähnt, habe ich mir in den alten Code noch zwei Erweiterungen auf Basis der DWD-Prognose gebaut:
- Ist für den Tag der Bewässerung Regen (Menge > definierter Sollwert) angesagt, wird die Bewässerung noch einen Tag verschoben. Dabei rechne ich simpel "Regenmenge laut Prognose = Niederschlagswahrscheinlichkeit * Vorhersagemenge". Hier bin ich ein manueller Stopper: wird zu viele Tage geschoben, und es regnet doch nicht, dann schalte ich halt per Hand ein. Könnte man auch automatisieren.
- Als zweiten Wert für die Bewässerungs-% habe ich die Verdunstung, genauer Evapotranspiration, ins Boot geholt. Das ist ein sehr theoretischer Wert, der für "idealtypisches Grünland" berechnet wird. Die Werte im Hausgarten werden in real sehr stark schwanken, aber so Pi mal Daumen...
Der Evap.-Prognosewert für den Tag wird mit dem Bewässerungs-Sollwert pro Tag verglichen. Liegt PEvap unter Soll pro Tag (d.h. die Pflanzen "verbrauchen" weniger, als "nachgefüllt" wird), wird die Bewässerungsdauer entsprechend verkürzt. Liegt PEvap höher (z.B. sehr heiß, oder sehr geringe Luftfeuchte plus Wind), wird die Bewässerungsdauer verlängert.
ich habe jeweils einen Faktor für positive und negative Änderungen der Gesamtbewässerungsdauer eingeführt, weil ich das Gefühl (!) hatte, das niedrigere PEvap-Werte (Bewässerung soll gekürzt werden) zu starken Einfluss auf die Menge nehmen, also für in meinem Ort zu arg übertrieben sind.

[FunkOdyssey]

Ich habe die Lösung immer noch im reinen Beobachtungsmodus.
Mir fiel auf, dass gar nicht täglich gewässert wird.
Ist das richtig, dass ich bei täglicher Bewässerung intervalDays auf 0 setzen muss?

[funclass]

Ja, der Wert gibt an wie viele Tage zwischen zwei automatischen Bewässerungszyklen liegen. Ein strapazierfähiger Rasen sollte z.B. nur alle 3 bis 5 Tage gewässert werden. Bei täglicher Bewässerung ist er zwar schön grün, hat aber keine tiefen Wurzeln. Somit würde er bei der ersten Trockenperiode ohne künstliche Bewässerung sofort leiden.

[FunkOdyssey]

Grundsätzlich sollte das Ventil selbst erstmal unterstützen via

Code: [Auswählen]

set ventilname off auch einen laufenden Timer zu unterbrechen. Geht das nicht, müsste erstmal ergründet werden wie das Device selbst geschaltet werden kann.

Im Code wird bei jeder Änderung der aktiven Zone im Hauptdevice eigentlich dafür gesorgt, dass evtl. noch eingeschaltete Ventile ausgeschaltet werden.

Code: [Auswählen]

...
# erstmal alle aktiven Ventile ausschalten
my $itemvalve = "";
foreach my $item (devspec2array('NAME=Beregnung_Zone.*')) {
$itemvalve = ReadingsVal($item,"valve","none").":FILTER=STATE=on";
fhem ("set $itemvalve off");
}

ich stelle grad fest, dass ich recht oft den Begriff „erstmal“ verwende

Ich habe alle Notifys etc. geprüft und massenhaft Log3-Zeilen zum Debuggen ergänzt.
Ganz am Ende komme ich zu deinen Zeilen. Es scheitert wirklich genau an deiner Schleife.

Die Kombination mit deinem Filter macht mir Probleme:

Code: [Auswählen]

$itemvalve = ReadingsVal($item,"valve","none").":FILTER=STATE=on";
Bei einem Dummy ist in STATE der Wert "on-for-timer" enthalten. Somit funktioniert der Filter nicht.
Ich bin nun auf Nummer sicher gegangen und haben den Filter entfernt. Es geht natürlich auch mit stateformat oder ähnlich, aber das ist mir auf Dauer auch zu gefährlich.

[FunkOdyssey]

@funclass:
Wie weit bist du mit deiner neuen Überarbeitung? Ich weiß derzeit nicht, ob ich den alten Code vollumfänglich in Betrieb nehmen soll oder ob ich noch warten soll. Vielen Dank.


Beim Einarbeiten in diese Lösung habe ich diverse Logs angelegt.
Dabei wunderte ich mich, dass ich in den Readings neue Werte sehe, die aber im Filelog fehlten.
Ich weiß nicht, ob das wirklich stimmt. Aber im Forum habe ich etwas darüber gelesen, dass ein setreading, welches aus einem Notify getriggert wird, nicht ins Log schreiben kann.

Ich habe dein Skript nun vollständig auf readingsSingleUpdate umgestellt und beobachte das mal.


Nachtrag:
Das können wir wohl verwerfen. Das hat nicht geklappt.
Ich frage mich, warum die Funktion sub sprinkleChangeActiveZone($) zwar das Reading totalPrecipitation setzt, aber im Filelog dazu nichts ankommt.

In der CommandRef habe ich dazu folgendes gefunden:

Achtung: setreading generiert kein Event für ein Gerät X, falls es aus einem notify für Gerät X aufgerufen wurde. In so einem Fall könnte man auf "sleep 0.1; setreading X Y Z" ausweichen.

Außerdem auch diverse Threads wie https://forum.fhem.de/index.php/topic,28017.0.html.

Jedoch klappt es auch nicht, wenn ich in der Util ein sleep ergänze.

Hat jemand eine Idee?

[funclass]

Hallo,

die Umsetzung der Presetfunktion ist nun m.E. fertig. Habs ein wenig getestet und konnte nun keine Fehler mehr feststellen. Anpassungen gab es im Hauptdevice, im zugehörigen Notify und in der Utils-Datei. Ich werde den Code hier kurzfristig posten. Damit ist für mich alles Relevante erstmal umgesetzt. Die Integration weiterer Features schließe ich nicht aus, kann aufgrund der knappen „Freizeit“ aber durchaus etwas länger dauern.

Bezüglich des Loggings hab ich mir ehrlich gesagt noch gar keine Gedanken gemacht. Durch die Benachrichtigung via Telegramm bin ich eigentlich immer gut informiert. Eine Option (wenn auch nicht sehr elegant) wäre sicherlich nach oder vor jedem setreading noch selbst einen Logeintrag zu schreiben. Das wäre mir aber zu viel Aufwand. Ich denke hier stoßen wir langsam an die Grenzen der „offenen Lösung“ und bräuchten tatsächlich ein „echtes Modul“.

[FunkOdyssey]

Ich versuche nun seit Tagen, die Readings ins Log zu bekommen.
Das ich ein sleep nutzen muss, hatte ich ja schnell herausgefunden.

Problem Nr.1
Ich habe leider ein Perl-Sleep und nicht ein FHEM-Sleep genutzt.

Problem Nr.2
Meine Syntax war falsch. Ich hatte immer zwei Semikolons genutzt. Dann hatte ich Fehler "Last parameter must be quiet" im FHEM-Log. Aber mit dem "sleep 0 quiet" hatte es auch nicht funktioniert. Der Grund lag in den Semikolons, da der Befehl nicht richtig erkannt wurde.

Lösung:
Könntest du deine setreading-Aufrufe bitte mit einem Sleep 0 erweitern?

Code: [Auswählen]

fhem ("sleep 0;setreading Beregnung totalPrecipitation $precipitation");
Dann funktioniert alles perfekt.

Ich freue mich schon auf deine neue Version. Danke.

[funclass]

Also wenn das des Rätsels Lösung ist, sollte es kein Problem sein. Würde es in das Skript integrieren, bevor ich es hier hochlade.

[networker]

Ich hänge mich hier mal rein zum mitlesen, klingt interessant