Hilfe erbeten - DOIF löst nicht aus

Begonnen von Superposchi, 04 Februar 2023, 13:45:56

Vorheriges Thema - Nächstes Thema

Per

Du änderst ein Device (deine Dummy Variablen), auf deren Events du reagieren willst. Dass es verschiedene Readings sind, ist zweitrangig.

Um die Verwirrung zu entfitzen kannst du ja damit anfangen, den aktuellen Stand der drei Devices zu posten. Das aus zig Posts herauszusuchen ist nicht nur mühsam, sondern auch fehleranfällig.

Sany

#16
ich habs grad mal nachgestellt: mit wait 1:1:1:1 klappt es wie gewünscht, auch mit 0.1:0.1:0.1:0.1
Ich würd mal sagen, der Hinweis zu setreading in der commandref gilt auch für DOIF.

hier ein RAW aus meinem Testsystem, bereinigt um die überflüssigen Klammern und mit numerischem Vergleich. Das mag zwar auch mit String-Vergleich funktionieren, spätestens wenns mehrstellig wird findet man die Fehler nicht mehr.....

defmod blumen_giesen_controll DOIF ([blumen_giesen:mode] eq "auto" and [blumen_giesen:days] == 0)\
(setreading blumen_giesen alert none)\
DOELSEIF ([blumen_giesen:mode] eq "auto" and [blumen_giesen:days] == 2)\
(setreading blumen_giesen alert normal)\
DOELSEIF ([blumen_giesen:mode] eq "auto" and [blumen_giesen:days] == 3)\
(setreading blumen_giesen alert priority)\
DOELSEIF ([blumen_giesen:mode] eq "auto" and [blumen_giesen:days] == 4)\
(setreading blumen_giesen alert urgent)
attr blumen_giesen_controll do always
attr blumen_giesen_controll wait 0.1:0.1:0.1:0.1


Wieso haben eigentlich alle 3 Devices den alias Blumen gießen?

ZitatDer Punkt ist einfach, dass ich mir mit solchen Versuchen mehr als einmal ein laufendes System zerschossen habe, weshalb ich da sehr vorsichtig geworden bin.
da wäre mal ein Test/Spiel-system hilfreich. Dafür ist keine Hardware nötig, geht alles in Software. Wenn Du sagst, auf was für einem System Du normalerweise arbeitest (mit fhem) dann findet man eine Lösung.



Gruß


Sany
fhem auf Zotac ZBox nano als LXC auf Proxmox, weitere LXC mit ZigBee2MQTT, MariaDB und Grafana. Homematic, FS20, mySensors, MQTT2, Tasmota, Shelly, Z-Wave  ....

Superposchi

Sorry, ich bin dankbar für die Hilfe aber etwas verwirrt.
Warum wird immer am funktionierendem DOIF verbessert?
Das DOIF welches auf das "days"-Reading reagiert funktioniert.
Das andere DOIF ist das Problem.

Ich habe den Aufbau bereits 2 mal beschrieben, wenn er nicht verstanden wird, ändert sich das beim 3. Mal höchstwahrscheinlich auch nicht. Und allmählich frage ich mich woran das liegt. Drücke ich mich wirklich so schlecht aus?

Das ist nicht böse gemeint, aber wenn ich nicht verstehe wo das Verständnisproblem liegt, wird immer wieder am falschen Teil rumgebastelt.

Otto123

#18
Zitat von: Superposchi am 06 Februar 2023, 17:48:29
Warum wird immer am funktionierendem DOIF verbessert?
Das DOIF welches auf das "days"-Reading reagiert funktioniert.
Das andere DOIF ist das Problem.
Weil der Fehler im (für Dich funktionierenden) DOIF offenbar die Ursache für die Nichtfunktion des anderen DOIFs ist. - hier das setreading im gleichen, auslösendem Device
Und weil es falsch ist zu denken, das Fehler im Code auf Dauer immer gutmütige Ergebnisse liefern - hier der Unterschied zwischen lexikalischen und numerischen Vergleich.
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Superposchi

Wieso soll der Fehler im ersten DOIF sein. Das wird ausgeführt, ändert das Reading wie gewünscht und erzeugt wie gezeigt ein entsprechendes Event. Wo ist da der Fehler?

Das andere DOIF wird nicht ausgelöst selbst wenn das Reading zum Beispiel per "set blumen_giesen alert normal" manuell gesetzt wird. Also selbst wenn das erste DOIF gar nicht beteiligt ist.

Otto123

#20
Zitatset blumen_giesen alert normal
funktioniert gar nicht :o
setzt nur den state, da Du readingList nicht aktiv hast.
setreading blumen_giesen alert normal wäre Dein Befehl.
Das löst das DOIF nicht aus? Wenn die Zeitscheibe 10:00-20:00 stimmt?
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Superposchi

Sorry, Schreibfehler in der Hektik. Klar meinte ich setreading.

Und ja, der Befehl löst das 2. DOIF innerhalb der Zeitspanne nicht aus, genau wie die automatische Änderung aus dem anderen DOIF heraus. Das schreibe ich ja schon die ganze Zeit.

Deshalb wunderte ich mich ja immer warum ihr an dem anderen DOIF rumgedockert habt. Was ich noch nicht probiert habe ist beim 2. DOIF ein Wait mit einzubauen damit die Änderung der beiden Readings sich nicht überschneiden.

Otto123

Also ich habe die Geräte nachgestellt, das fraglich DOIF funktioniert. Das ist auch so simpel, warum sollte das nicht funktionieren?
Auf den ersten Blick funktioniert bei mir das gesamte Konstrukt.  :-\
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Superposchi

Das ist ja die Frage weshalb ich es nicht verstehe.
Ich nutze nur DOIF's und kenne mich eigentlich schon recht gut damit aus. Dazulernen kann man natürlich immer.

Vielleicht ist es sinnvoll das zweite DOIF mal komplett zu löschen und neu zu erstellen. Aber das mache ich morgen, schönen Abend erst mal.

Sany

Guten Morgen,

ZitatSorry, ich bin dankbar für die Hilfe aber etwas verwirrt.
Warum wird immer am funktionierendem DOIF verbessert?
Das DOIF welches auf das "days"-Reading reagiert funktioniert.
Das andere DOIF ist das Problem.

Ich habe den Aufbau bereits 2 mal beschrieben, wenn er nicht verstanden wird, ändert sich das beim 3. Mal höchstwahrscheinlich auch nicht. Und allmählich frage ich mich woran das liegt. Drücke ich mich wirklich so schlecht aus?

Das ist nicht böse gemeint, aber wenn ich nicht verstehe wo das Verständnisproblem liegt, wird immer wieder am falschen Teil rumgebastelt.
Der Aufbau ist klar, den hast Du richtig erklärt. Was halt nicht geht, ist dass das blumen_giesen_benachrichtigung DOIF getriggert wird, weshalb Du einen Fehler in diesem DOIF vermutest. Da ist aber wohl kein Fehler, nur wird das DOIF nicht richtig getriggert. Es scheint Konstellationen zu geben, wo im Event-Monitor Events angezeigt werden, intern diese aber nicht verarbeitet oder unterdrückt werden. Die Fundstellen in der Commandref zu setreading und auch zu DOIF (deutsche commandref, suche nach Endlosschleife) deuten darauf hin. Was Dein Konstrukt macht, ist: im Dummy wird ein Reading verändert, darauf reagiert DOIF1 und ändert ein anderes Reading im selben Dummy, worauf DOIF2 reagieren soll. irgendeine "Mechanik" in fhem erkennt hier wohl eine potentielle Endlosschleife und unterdrückt die Bearbeitung des Events oder verhindert diesen. Er wird allerdings im Eventmonitor angezeigt.
Ich selbst hatte auch schon einen ähnlichen Fall, allerdings in Zusammenhang mit userreadings, wo ich Berechnungen erstellt habe und nach der zweiten Berechnung diese nicht gelogged wurde, aber auch angezeigt.
Hier https://forum.fhem.de/index.php/topic,118775.msg1132071.html#msg1132071 ist Dein Problem auch schon mal beschrieben (1. und letzter Post).
Für mich wäre das nun Erklärung genug und mit dem wait Attribut geht es ja wie gewünscht.
Noch eine Frage: Du zählst Mitternacht die days hoch und setzt damit den Dummy. Dann kann DOIF1 eigentlich nur reagieren, wenn es 10:00 ist ([10:00-20:00] ohne Fragezeichen), da der Abfrageteil [blumen_giesen:alert] eq "XX" ja nur um Mitternacht sich ändert. (ist so, gerade probiert). Wie "resettest" Du die Konstruktion? Setzt Du nach dem gießen dann die Tage auf 0 oder den alert auf none? Wie machst Du das? Würde mich interessieren.

@Otto
ZitatAlso ich habe die Geräte nachgestellt, das fraglich DOIF funktioniert. Das ist auch so simpel, warum sollte das nicht funktionieren?
Auf den ersten Blick funktioniert bei mir das gesamte Konstrukt.  :-\
mit oder ohne wait-Attribut im blumen_giesen_controll? Ohne gehts bei mir nicht.


ZitatVielleicht ist es sinnvoll das zweite DOIF mal komplett zu löschen und neu zu erstellen.
ich denke mal, das bringt nix.


Gruß


Sany
fhem auf Zotac ZBox nano als LXC auf Proxmox, weitere LXC mit ZigBee2MQTT, MariaDB und Grafana. Homematic, FS20, mySensors, MQTT2, Tasmota, Shelly, Z-Wave  ....

Superposchi

Danke, sehr ausführlich erklärt.
Für einen Anfänger wie mich ist das nicht Triggern obwohl es korrekt ist ein Fehler. Das dies irgendwie im Hintergrund des Systems unterdrückt wird, ist ohne tieferes Wissen nicht ergründen.
Ehrlich gesagt verstehe ich auch nicht wie es zu einer solchen Interpretation kommen kann da ja kein Circle-Bezug vorliegt, aber manche Sachen in Fhem sind unergründlich.

Zur Erläuterung.
Das mit der Zeit dient dazu, dass die Benachrichtigungen (bei priority und urgend mit diversen Wiederholungen) nicht durch die Nacht hin ausgegeben werden bzw. die Benachrichtigung bei Inkrafttreten nicht vor 10 Uhr ausgegeben wird.
Dazu ist ja auch der 5. Ast im zweiten DOIF der einfach nur () ausführt, also eben nur einen Wechsel des Astes und damit den Abbruch der Benachrichtigungen erzwingt. Das Rückseiten erfolgt aus meinem FTUI heraus wo mit einem entsprechenden Objekt die days auf Null gesetzt werden. Darauf reagiert das 1. DOIF und setzt den Alert auf "none" (funktioniert).

Rückfrage meinerseits:
Du hattest das wait im 1. DOIF eingefügt, ist das richtig?
Meinem Verständnis nach würde es (auch bezogen auf die Endlosschleife) mehr Sinn ergeben, oder nicht?

Sany

#26
ZitatDanke, sehr ausführlich erklärt.
ich hoffe das das auch richtig ist...(bin auch nur User. Das ist meine Interpretation der commandref und Forennachrichten und eigenen Tests)

ZitatDu hattest das wait im 1. DOIF eingefügt, ist das richtig?
siehe #16: https://forum.fhem.de/index.php/topic,132032.msg1262572.html#msg1262572

ZitatDas Rückseiten erfolgt aus meinem FTUI heraus
das wollte ich wissen. Alles gut. Dann ist das gelöst?



Gruß


Sany
fhem auf Zotac ZBox nano als LXC auf Proxmox, weitere LXC mit ZigBee2MQTT, MariaDB und Grafana. Homematic, FS20, mySensors, MQTT2, Tasmota, Shelly, Z-Wave  ....

Superposchi

Das meine ich, das wait steht im 1. DOIF das auf die days reagiert. Dadurch wird die Benachrichtigung aber doch noch genauso umgehend ausgeführt nachdem die Tage sich geändert haben.

Außerdem ist es ja wegen der Zeitspanne eigentlich gar nicht möglich, dass die beiden DOIF's sich überschneiden und damit eine Schleife dargestellt werden könnte.
Das eine wird ja um Mitternacht und das andere frühestens um 10 Uhr ausgeführt.

Also wirklich nachvollziehbar ist das für mich nicht.

Otto123

Zitat von: Sany am 07 Februar 2023, 09:38:49
@Ottomit oder ohne wait-Attribut im blumen_giesen_controll? Ohne gehts bei mir nicht.
Hi Sany,

ohne wait  :-X

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Sany

ZitatDas meine ich, das wait steht im 1. DOIF das auf die days reagiert. Dadurch wird die Benachrichtigung aber doch noch genauso umgehend ausgeführt nachdem die Tage sich geändert haben.

Außerdem ist es ja wegen der Zeitspanne eigentlich gar nicht möglich, dass die beiden DOIF's sich überschneiden und damit eine Schleife dargestellt werden könnte.
Das eine wird ja um Mitternacht und das andere frühestens um 10 Uhr ausgeführt.
das stimmt....

Zitatvon Otto:
ohne wait  :-X
stimmt auch....

und was ich vorher beschrieben habe stimmt auch....

ein Versuch der Erklärung: bei deinem ersten Post hattest Du die Zeitspanne mit ?, also nicht triggernd, angegeben. Deshalb habe ich die Zeitspanne quasi ignoriert. Damit das DOIF eine Nachricht sendet musste es per Dummy getriggert werden, was aber ohne das wait im control-DOIF nicht geht. Mit dem wait geht es.
Betrachtet man nun das gesamte Konstrukt mit triggernder Zeitangabe passiert folgendes:
Annahme: im control-DOIF ist KEIN wait gesetzt. Um Mitternacht wird der days-Wert verändert, im Dummy wird days und über das control-DOIF das alert-Reading neu gesetzt. Das geänderte Reading alert wird zwar im Event-Monitor angezeigt, es triggert aber das benachrichtigungs-DOIF nicht. Beginnt nun die Zeitspanne um 10 wird das DOIF getriggert (von der Zeit), geht alle Zweige durch und findet einen match vom alert-Reading, das benachrichtigungs-DOIF sendet die Benachrichtigung.
ZitatBeispiel: setzten des days-Reading um 13:54:34, Beginn Zeitspanne 13:56
2023-02-07 13:54:34.239 DOIF blumen_giesen_controll cmd_nr: 4
2023-02-07 13:54:34.239 DOIF blumen_giesen_controll cmd: 4
2023-02-07 13:54:34.239 DOIF blumen_giesen_controll cmd_event: blumen_giesen
2023-02-07 13:54:34.239 DOIF blumen_giesen_controll cmd_4
2023-02-07 13:54:34.240 dummy blumen_giesen days: 4
2023-02-07 13:54:34.240 dummy blumen_giesen alert: urgent


2023-02-07 13:56:00.001 DOIF blumen_giesen_benachrichtigung cmd_count: 1
2023-02-07 13:56:00.003 DOIF blumen_giesen_benachrichtigung cmd_nr: 4
2023-02-07 13:56:00.003 DOIF blumen_giesen_benachrichtigung cmd: 4
2023-02-07 13:56:00.003 DOIF blumen_giesen_benachrichtigung cmd_event: timer_7
2023-02-07 13:56:00.003 DOIF blumen_giesen_benachrichtigung error: set Pushmsg msg title="Haushaltsarbeit" device="Marko_S21Ultra,Marion_S21Ultra" message="Blumen sind überfällig!": Please define Pushmsg first
2023-02-07 13:56:00.003 DOIF blumen_giesen_benachrichtigung cmd_4
im Beispiel zu sehen:
control-DOIF geht auf cmd_4, danach wird der dummy gesetzt. weiter passiert nichts, bis die Zeitspanne, hier Beginn um 13:36 aktiv wird. Das benachrichtigungs-DOIF geht auch auf cmd_4 und will die Benachrichtigung senden (geht hier nicht, weil nicht definiert, aber der Ausführungszweig wird abgearbeitet.)
Das bedeutet also, das Kontrukt würde funktionieren, wenn es genau so abgearbeitet wird, und nicht innerhalb der Zeitspanne die days neu gesetzt werden.

Annahme 2: im control-DOIF ist wait gesetzt, hier mit wat 1:1:1:1 also jeweils 1 sec:
ZitatBeispiel: setzten vom days-reading um 13:39:41, eine Sekunde später ist der waittimer abgelaufen und das benachrichtiguns-DOIF geht in cmd_5, da die Zeit nicht matched, es wird aber eindeutig getriggert!!
2023-02-07 13:59:41.716 DOIF blumen_giesen_controll wait_timer: 07.02.2023 13:59:42 cmd_3 blumen_giesen
2023-02-07 13:59:41.717 dummy blumen_giesen days: 3

2023-02-07 13:59:42.718 DOIF blumen_giesen_controll wait_timer: no timer
2023-02-07 13:59:42.720 DOIF blumen_giesen_benachrichtigung cmd_count: 1
2023-02-07 13:59:42.721 DOIF blumen_giesen_benachrichtigung cmd_nr: 5
2023-02-07 13:59:42.721 DOIF blumen_giesen_benachrichtigung cmd: 5
2023-02-07 13:59:42.721 DOIF blumen_giesen_benachrichtigung cmd_event: blumen_giesen
2023-02-07 13:59:42.721 DOIF blumen_giesen_benachrichtigung cmd_5
2023-02-07 13:59:42.722 dummy blumen_giesen alert: priority
2023-02-07 13:59:42.723 DOIF blumen_giesen_controll cmd_nr: 3
2023-02-07 13:59:42.723 DOIF blumen_giesen_controll cmd: 3
2023-02-07 13:59:42.723 DOIF blumen_giesen_controll cmd_event: blumen_giesen
2023-02-07 13:59:42.723 DOIF blumen_giesen_controll cmd_3


2023-02-07 14:01:00.002 DOIF blumen_giesen_benachrichtigung cmd_count: 1
2023-02-07 14:01:00.003 DOIF blumen_giesen_benachrichtigung cmd_nr: 3
2023-02-07 14:01:00.003 DOIF blumen_giesen_benachrichtigung cmd: 3
2023-02-07 14:01:00.003 DOIF blumen_giesen_benachrichtigung cmd_event: timer_5
2023-02-07 14:01:00.003 DOIF blumen_giesen_benachrichtigung error: set Pushmsg msg title="Haushaltsarbeit" device="Marko_S21Ultra,Marion_S21Ultra" message="Blumen dringend gießen!": Please define Pushmsg first
2023-02-07 14:01:00.003 DOIF blumen_giesen_benachrichtigung cmd_3
um 14:01 wird die Benachrichtigung ausgeführt, getriggert vom Beginn der Zeitspanne.

Ich würde in diesem Fall das wait-Attribut setzen und vielleicht im comment-Attribut den link zu diesem Thread eintragen, dann wird Dir auch später klar, warum da das wait drin ist.

So, viel gelernt, für mich ist das jetzt erledigt und ich würde mich freuen, wenn Du, superposchi, Deine finale Lösung nochmal postest, nachdem sie unter "Echtzeitbedingungen" funktioniert hat.


Gruß


Sany
fhem auf Zotac ZBox nano als LXC auf Proxmox, weitere LXC mit ZigBee2MQTT, MariaDB und Grafana. Homematic, FS20, mySensors, MQTT2, Tasmota, Shelly, Z-Wave  ....