Bewässerungssteuerung - Vorstellung und Ideensammlung

Begonnen von funclass, 29 Oktober 2016, 22:22:41

Vorheriges Thema - Nächstes Thema

Stefan_Hvr

Hallo Christian,
sub sprinkleStart($) ....
my $startDelay = 3;


in der sprinkleStart ist der "startDelay" mit 3 Sekunden eingetragen. Was hältst Du davon diesen als Reading in die Beregnung zu nehmen?
Dann könnte der Wert individuell und einfach angepasst werden.
BG Stefan
Viele Grüße aus Hannover
EnOcean, Zigbee, Shelly MQTT, Homebridge, Fritzbox, Harmonyhub, Alexa, Worx MQTT, Sonos MQTT, Tahoma, Telegram, Vorwerk,IRoomba MQTT, Buderus Km200,
seit 08/2019 Hausautomation mit FHEM

funclass

Zitat von: Stefan_Hvr am 16 Juni 2020, 13:04:45
Hallo Christian,
sub sprinkleStart($) ....
my $startDelay = 3;


in der sprinkleStart ist der "startDelay" mit 3 Sekunden eingetragen. Was hältst Du davon diesen als Reading in die Beregnung zu nehmen?
Dann könnte der Wert individuell und einfach angepasst werden.
BG Stefan

Hi Stefan,

hätte ich kein Problem mit. Potenziell müssten wir evtl. zwei Readings anlegen. Ich hatte bisher immer eine Verzögerung von 60 Sek. im Automatikmodus (im aktuellen Code sind es 10 Sek.) und 10 Sek. im manuellen Modus (derzeit die von dir erwähnten 3 Sek.). Grund für mich war es, bei ungewolltem/versehentlichem Start noch reagieren und ggf. stoppen zu können. Es kommt ja direkt die Benachrichtigung, dass in xy Sekunden gestartet wird. Sicherlich könnte man auch mit einem einheitlichen Wert für alle Modi leben.

Vorschlag: neues Reading startDelay in welches der gewünschte Wert in Sekunden eingetragen werden muss.

Stefan_Hvr

setList
attr Beregnung setList state:on,off pct:slider,5,1,100 intervalDays:1,2,3,4,5,6,7 defaultIntervalPrecipitation:slider,1,1,20 activeZone:00,01,02,03,04,05,06,09 rainThreshold:0,0.5,1,1.5,2,2.5,3 startTime updateDaylieRainTime prenotifcationTime action:start,stop,delay,reset notifications:0,1 prenotification:0,1 startDelay:3,5,10,20
--> oder ähnlich  ;)

readingList
attr Beregnung readingList state pct intervalDays daysLeft defaultIntervalPrecipitation rainfall rainThreshold isRaining rainDay totalPrecipitation activeZone startTime updateDaylieRainTime prenotifcationTime mode action notifications prenotification startDelay

sub sprinkleStart
my $startDelay = (ReadingsVal("Beregnung", "startDelay", "10"));
-->sonst noch irgendwo?
Viele Grüße aus Hannover
EnOcean, Zigbee, Shelly MQTT, Homebridge, Fritzbox, Harmonyhub, Alexa, Worx MQTT, Sonos MQTT, Tahoma, Telegram, Vorwerk,IRoomba MQTT, Buderus Km200,
seit 08/2019 Hausautomation mit FHEM

FunkOdyssey

#93
Ich musste bei mir das Notify auch manuell anlegen.

Doch ich habe mit dem anderen Notify noch ein Problem. Sobald ich eine Beregnungszone deaktivieren will, habe ich folgende Zeilen im Log:

2020.06.16 22:01:42.817 1:  ERROR evaluating my $EVTPART0='on';my $TYPE='dummy';my $SELF='notify_Beregnungszone';my $NAME='Beregnung_Zone01';my $EVENT='on';{
my $zone = $NAME;
my $action = $EVTPART0;
if ($action eq "action:") {
# Einzel-Beregnung gestartet oder gestoppt
if ($EVTPART1 eq "start") {
sprinkleSingleMode($zone);
} else {
sprinkleStopSingleMode($zone);
}
} elsif ($action eq "on") {
# Zone aktiviert
} elsif ($action eq "off") {
# Zone deaktiviert
} else {
# andere Aktion
}
}: Global symbol "$EVTPART1" requires explicit package name (did you forget to declare "my $EVTPART1"?) at (eval 291169) line 6.

2020.06.16 22:01:42.817 3:  notify_Beregnungszone return value: Global symbol "$EVTPART1" requires explicit package name (did you forget to declare "my $EVTPART1"?) at (eval 291169) line 6.


Mir ist aufgefallen, dass ich bei $action EVTPART0 und EVTPART1 zur Verfügung habe.
Aber wenn ich direkt mit den Settern ON oder OFF arbeite, so gibt es kein EVTPART1

2020-06-16 22:04:56.671 dummy Beregnung_Zone01 off
2020-06-16 22:05:00.584 dummy Beregnung_Zone01 on
2020-06-16 22:05:02.120 dummy Beregnung_Zone01 action: start
2020-06-16 22:05:02.120 dummy Beregnung_Zone01 action: none


Kann es sein, dass das Notify noch nicht korrekt ist? Danke.

Sehe gerade. Also die gleiche Frage wie hier: https://forum.fhem.de/index.php/topic,59872.msg1064493.html#msg1064493




Ein ähnliches Problem habe ich, wenn ich im globale Beregnungsdevice mit ON oder OFF arbeite:

2020.06.16 22:11:02.657 1:  ERROR evaluating my $NAME='Beregnung';my $EVENT='off';my $SELF='notify_Beregnung';my $TYPE='dummy';my $EVTPART0='off';{
my $action = $EVTPART0;
if ($action eq "pct:") {
# Intensität geändert
my $last = OldReadingsVal($NAME,"pct",100);
fhem "setreading Beregnung lastPct $last";
sprinklePctDuration();
} elsif ($action eq "on:") {
# Beregnung eingeschaltet
fhem "setreading Beregnung mode standby";
} elsif ($action eq "off:") {
# Beregnung ausgeschaltet
if (ReadingsVal("Beregnung", "mode", "standby") ne "standby") {
sprinkleStop("mainswitch");
}
} elsif ($action eq "activeZone:") {
# aktive Beregnungszone geändert
sprinkleChangeActiveZone($EVTPART1);
} elsif ($action eq "action:") {
# manueller Befehl
my $command = $EVTPART1;
if ($command eq "start") {
sprinkleStart("manual");
} elsif ($command eq "stop") {
sprinkleStop("manual");
} elsif ($command eq "delay") {
sprinkleDelay();
} elsif ($command eq "reset") {
sprinkleReset();
}
} elsif ($action eq "isRaining:") {
# aktive Beregnungszone geändert
if (($EVTPART1 == 1) && (ReadingsVal("Beregnung", "mode", "standby") eq "auto")) {
sprinkleStop("rain");
}
} else {
# unbekannte Aktion
}
}: Global symbol "$EVTPART1" requires explicit package name (did you forget to declare "my $EVTPART1"?) at (eval 296170) line 18.
Global symbol "$EVTPART1" requires explicit package name (did you forget to declare "my $EVTPART1"?) at (eval 296170) line 21.
Global symbol "$EVTPART1" requires explicit package name (did you forget to declare "my $EVTPART1"?) at (eval 296170) line 33.

2020.06.16 22:11:02.657 3:  notify_Beregnung return value: Global symbol "$EVTPART1" requires explicit package name (did you forget to declare "my $EVTPART1"?) at (eval 296170) line 18.
Global symbol "$EVTPART1" requires explicit package name (did you forget to declare "my $EVTPART1"?) at (eval 296170) line 21.
Global symbol "$EVTPART1" requires explicit package name (did you forget to declare "my $EVTPART1"?) at (eval 296170) line 33.

funclass

Zitat von: Stefan_Hvr am 16 Juni 2020, 15:31:47
setList
attr Beregnung setList state:on,off pct:slider,5,1,100 intervalDays:1,2,3,4,5,6,7 defaultIntervalPrecipitation:slider,1,1,20 activeZone:00,01,02,03,04,05,06,09 rainThreshold:0,0.5,1,1.5,2,2.5,3 startTime updateDaylieRainTime prenotifcationTime action:start,stop,delay,reset notifications:0,1 prenotification:0,1 startDelay:3,5,10,20
--> oder ähnlich  ;)

readingList
attr Beregnung readingList state pct intervalDays daysLeft defaultIntervalPrecipitation rainfall rainThreshold isRaining rainDay totalPrecipitation activeZone startTime updateDaylieRainTime prenotificationTime mode action notifications prenotification startDelay

sub sprinkleStart
my $startDelay = (ReadingsVal("Beregnung", "startDelay", "10"));
-->sonst noch irgendwo?

Das sollten alle relevanten Stellen gewesen sein. Ich hab's in der setlist per Slider gelöst, nun lässt es sich in 5 Sekunden-Schritten bis max 120 einstellen.

Hab außerdem noch nen Tippfehler gefunden. Anstatt prenotifcationTime muss es prenotificationTime lauten. Muss in readingList, setList und im doif geändert werden.

funclass

Ich hab mir die notify-Problematik mal eben angesehen und tatsächlich auch in meinem Log die Warnmeldungen, wenn ich den status on/off ändere. Laut folgendem Artikel lässt sich das auch nicht grundsätzlich verhindern:
https://forum.fhem.de/index.php?topic=102350.0

Ich habe den Vorschlag von Rudi mit dem evenarray mal getestet und bekomme nun keine Fehler mehr. Könnt ihr ja auch mal versuchen.

Hierzu ganz oben im notify erstmal das array erstellen:

Beregnung:.* {
my @eventarray = split(" ", $EVENT);
my $action = $eventarray[0];
        .....


und dann überall wo vorher $EVTPARTx stand $eventarray[x] einsetzen. x steht hierbei für den Index der vorher auch dahinterstand.

funclass

#96
Ich bin grad dabei den (derzeit) letzten Punkt meiner Feature-Liste umzusetzen. Damit soll die Möglichkeit gegeben werden, eine bestimmte Kombination von Beregnungszonen inkl. eingestellter Intensität als Preset zu speichern. Diese Presets können dann später entweder manuell gestartet werden oder dem Auto-Modus wird ein Preset zugewiesen, sodass immer die dort hinterlegten Zonen berücksichtigt werden, unabhängig des aktuellen Ein-/Ausschaltstatus. Die Intensität für den Automatikmodus wird weiterhin über die übliche Logik berechnet.

Wofür kann das gut sein?

Beispiel 1: Von meinen insgesamt 8 Zonen starte ich die Zonen im Vorgarten in langen Trockenperioden gern hin und wieder von Hand. Um nicht jede Zone einzeln starten zu müssen bzw. nicht ständig die Zonen hinterm Haus deaktivieren zu müssen (für einen manuellen Zyklus), speichere ich die betroffenen Zonen in einem Preset. Ebenso kann ich so gleich die gewünschte Intensität hinterlegen. Somit kann ich künftig einfach den Preset starten und die Anlage spricht nur die Regner im Vorgarten an...

Beispiel 2: Ich habe irgendwo etwas Rasen nach- bzw. neu gesät und möchte nun diese Stelle vor dem Austrocknen schützen. Also speichere ich die betroffene Zone(n) in einem Preset mit geringer Intensität. Nun kann ich über einen Timer mehrmals täglich genau diese Zone(n) beregnen lassen. Für den Automatikmodus lege ich entweder ein anderes Preset mit den restlichen Zonen an oder ich deaktiviere einfach die Zone(n) in denen nachgesät worden ist.

Sicherlich gibt es noch weitere Anwendungsfälle. Insgesamt habe ich erstmal 3 Presets vorgesehen. Grundsätzlich könnten aber auch hier noch weitere problemlos ergänzt werden.

Falls jemand noch hinweise/Ideen hat, bin ich ganz Ohr.

Sobald der Code fertig und lauffähig ist, werde ich mal ein neues File (inkl. der bisherigen Bugfixes) hochladen.

VG Christian

Stefan_Hvr

Das ist ja Klasse.
Habe auch gerade nachgesät und mir für die Fläche ein doif gebaut.
Aber das mit den Presets ist natürlich klasse.

Das mit den Notifys werde ich hoffentlich nächste Woche mal testen können.

Beste Grüsse
Stefan
Viele Grüße aus Hannover
EnOcean, Zigbee, Shelly MQTT, Homebridge, Fritzbox, Harmonyhub, Alexa, Worx MQTT, Sonos MQTT, Tahoma, Telegram, Vorwerk,IRoomba MQTT, Buderus Km200,
seit 08/2019 Hausautomation mit FHEM

FunkOdyssey

Ich arbeite mich gerade in deine Lösung ein. Wie kann man denn über die Zone oder dem Hauptdevice einen bereits gestarteten "on-for-timer" Beim Valve abbrechen? Habe ich evtl. noch ein Bug bei mir oder ist dieser Weg nicht implementiert?


Stefan_Hvr

Zitat von: FunkOdyssey am 21 Juni 2020, 23:51:32
Ich arbeite mich gerade in deine Lösung ein. Wie kann man denn über die Zone oder dem Hauptdevice einen bereits gestarteten "on-for-timer" Beim Valve abbrechen? Habe ich evtl. noch ein Bug bei mir oder ist dieser Weg nicht implementiert?

meinst Du:
set Beregnung_Zone01 stop
BG Stefan
Viele Grüße aus Hannover
EnOcean, Zigbee, Shelly MQTT, Homebridge, Fritzbox, Harmonyhub, Alexa, Worx MQTT, Sonos MQTT, Tahoma, Telegram, Vorwerk,IRoomba MQTT, Buderus Km200,
seit 08/2019 Hausautomation mit FHEM

FunkOdyssey

Zitat von: Stefan_Hvr am 22 Juni 2020, 00:04:57
meinst Du:
set Beregnung_Zone01 stop
BG Stefan

Ja, das hatte ich auch angenommen. Klappt bei mir aber nicht.
Dann gehe ich mal auf Suche.

JHo

Hallo Christian,

eine Frage und Anregung hätte ich noch. Bin aber fast sicher, dass dasnur mit richtig viel Aufwand, fast erst als Modul möglich wird:

Für die Bewässerung meiner Beete verwende ich andere Grundeinstellungen als für den Rasen. Alle 2 statt alle 3 Tage und mit abweichenden Soll-Liter/m², d.h. auch unterschiedlicher Reaktion auf Niederschlag. Wenn ich das richtig verstanden habe, ist das mit der aktuellen Version so nicht abzubilden: Ich könnte nur die Beregnungsdauer anpassen, wenn ich die Beetebewässerung mit in das "Device" aufnehme.
In der "alten" Variante von der ersten Seite habe ich einfach die internen Logiken (Readings und Code) so geändert, dass ich jetzt einen Satz notifies, doifs etc. für Rasen- und einen für Beetebewässerung habe. Also 2 getrennte, zentrale Steuerungen.
Um das mit der aktuellen Variante machen zu können, müsste ich nun auch die 99_myGiessenUtils mit geänderten Namen "duplizieren" (z.B. suchen und ersetzen "Beregnung" durch "Beeteberegnung" - das ist wenig Aufwand, aber nicht besonders schön). Mein Wunsch wäre, das jeweilige "Hauptdevice" als Variable übergeben zu können und damit mit einer myGiessenUtils mehrere separate Steuerungslogiken umzusetzen.

Zweite Frage: wie würdest du einen "Hauptschalter" integrieren (bei mir ein Hauptventil, dass den Strang zum Ventilverteiler überhaupt erst freigibt, oder eine Pumpe o.ä.)? Einfach per DOIF auf die einzelnen Beregnungskreise?

Viele Grüße, Jan
Oder wie würdest du solche unterschiedlichen Anforderungen an das Beregnungsintervall umsetzen?
1: FHEM auf Ubuntu, MAX!Cube, Wand- und Heizkörperthermostate, Eco-Schalter, diverse LaCrosse-Sensoren, per remote angebundene DS18B20-Sensoren
2: FHEM auf Raspi 3, Max!Cube, Wand- und Heizkörperthermostate, Eco-Schalter, ht_pitiny-Adapter zu Junkers FW120

funclass

#102
Zitat von: FunkOdyssey am 22 Juni 2020, 00:32:03
Ja, das hatte ich auch angenommen. Klappt bei mir aber nicht.
Dann gehe ich mal auf Suche.

Grundsätzlich sollte das Ventil selbst erstmal unterstützen via 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.


...
# 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 :)

funclass

Zitat von: JHo am 22 Juni 2020, 09:24:05
1.
Für die Bewässerung meiner Beete verwende ich andere Grundeinstellungen als für den Rasen. Alle 2 statt alle 3 Tage und mit abweichenden Soll-Liter/m², d.h. auch unterschiedlicher Reaktion auf Niederschlag

2.
....Mein Wunsch wäre, das jeweilige "Hauptdevice" als Variable übergeben zu können und damit mit einer myGiessenUtils mehrere separate Steuerungslogiken umzusetzen.

3.
Zweite Frage: wie würdest du einen "Hauptschalter" integrieren (bei mir ein Hauptventil, dass den Strang zum Ventilverteiler überhaupt erst freigibt, oder eine Pumpe o.ä.)? Einfach per DOIF auf die einzelnen Beregnungskreise?

Hallo Jan,

1.
wenn es ,,nur" darum geht die Zonen für die Beete in abweichendem Zyklus, mit fixer Intensität und nicht bei Regen usw. einzuschalten, so ließe sich das vermutlich künftig mit den Presets lösen. Den Startimpuls müsste man dann jedoch von außen z.B. via DOIF geben.
Wenn auch dafür die Bewässerungsmengen weggeschrieben und irgendwelche Berechnungen durchgeführt werden sollen, dann wird vermutlich ein Duplikat der kompletten Steuerung die bessere Entscheidung sein.

2.
Sicherlich sollte es möglich sein, die Lösung soweit zu flexibilisieren, dass in den Methoden der Zugriff auf die Devices per Variable erfolgt. Das heißt, bei jedem Aufruf einer Methode müsste zusätzlich der ,,Präfix" der Steuerungslogik übergeben werden (z.B. Beregnung oder Tropfbewaesserung o.ä.). Dann gäbe es eben mehrere Hauptdevices und zugehörige Zonen, die mit dem gleichen Namen beginnen wie das Hauptdevice.
Wenn ich herausgefunden habe, warum die Notify nicht selbstständig angelegt werden und das fixen kann, würde ich mal versuchen eine Variable Version vorzubereiten.

3.
Solange es unkritisch ist, dass das Hauptventil ohne Verzögerung zeitgleich mit den Zonenventilen schaltet, ist die Integration in die Zonen (so wie du es jetzt gelöst hast) das einfachste.
Man könnte das Hauptventil auch über das Reading ,,mode" des Hauptdevice lösen. Dieser ist ja nur standby wenn nicht beregnet wird. Somit könnte in das Hauptdevice beispielsweise ein neues Reading ,,mainValve" aufgenommen werden, in das der Devicename des Hauptventils bzw. der Pumpe eingetragen wird. Zusätzlich würde ich noch ein Reading für die maximale Einschaltdauer des Hauptventils gut finden, sodass dieses immer via on-for-timer geschaltet wird. Somit wäre sichergestellt, dass auch im Falle eines Fehlers nach dieser hinterlegten Zeit zumindest das Hauptventil selbstständig wieder ausschaltet. Kann ich mir ja mal ansehen.

VG Christian

JHo

Zitat von: funclass am 22 Juni 2020, 11:51:13
3.
Solange es unkritisch ist, dass das Hauptventil ohne Verzögerung zeitgleich mit den Zonenventilen schaltet, ist die Integration in die Zonen (so wie du es jetzt gelöst hast) das einfachste.
Man könnte das Hauptventil auch über das Reading ,,mode" des Hauptdevice lösen. Dieser ist ja nur standby wenn nicht beregnet wird. Somit könnte in das Hauptdevice beispielsweise ein neues Reading ,,mainValve" aufgenommen werden, in das der Devicename des Hauptventils bzw. der Pumpe eingetragen wird. Zusätzlich würde ich noch ein Reading für die maximale Einschaltdauer des Hauptventils gut finden, sodass dieses immer via on-for-timer geschaltet wird. Somit wäre sichergestellt, dass auch im Falle eines Fehlers nach dieser hinterlegten Zeit zumindest das Hauptventil selbstständig wieder ausschaltet. Kann ich mir ja mal ansehen.
Natürlich - Danke für den Schubser! Es spricht zumindest in meinem Fall überhaupt nichts dagegen, das ohne Vorlauf zu schalten. Die Millisekunde, die der Druck später am zweiten Ventil anliegt, dürfte egal sein. On-for-timer ist natürlich wichtig, und damit ist dann wohl sinnvoll, für jede Zone sowohl das Haupt- als auch das eigentliche Zonenventil als "valve" anzugeben und zu schalten. Für eine Pumpe wäre sicher die "große" Variante sinniger.
1: FHEM auf Ubuntu, MAX!Cube, Wand- und Heizkörperthermostate, Eco-Schalter, diverse LaCrosse-Sensoren, per remote angebundene DS18B20-Sensoren
2: FHEM auf Raspi 3, Max!Cube, Wand- und Heizkörperthermostate, Eco-Schalter, ht_pitiny-Adapter zu Junkers FW120