Hilfe erbeten - DOIF löst nicht aus

[Superposchi]

Ich habe für meine Hausarbeiten verschiedene Dummys mit den Attributen "days" und "alert" erstellt. Beispielhaft geht es um den Dummy für das Blumen gießen.
Die "days" werden jeden Tag um Mitternacht hochgezählt und ein DOIF setzt das Attribut "alert" bei erreichen bestimmter Werte auf "normal", priority" und "urgent". Dazu kommt noch "none" wenn die Tage zurückgesetzt werden.
Das klappt auch soweit wunderbar. Nur die Benachrichtigung ausgelöst durch ein weiteres DOIF funktioniert nicht.
Dieses soll entsprechend der Angabe "none", "normal", "priority" und "urgent" reagieren und verschiedene Meldungen auslösen.
Die Meldung per Pushmsg an sich funktioniert, das konnte ich mittels manueller Ausführung prüfen. Das Problem liegt eindeutig daran, dass das DOIF für die Benachrichtigung nicht automatisch beim ändern des Wertes in "alert" ausgelöst wird. Ich stehe aktuell auf dem Schlauch und habe keine Ahnung. Alle meine Versuche schlugen fehl. Löse ich mit set ein Checkall aus, wird es ordnungsgemäß ausgeführt, nur eben nicht bei Änderung des Wertes im Atribut.

Hier das List des nicht funktionierenden DOIS:

Code Auswählen Erweitern

Internals:
   DEF        ([?10:00-20:00] and ([blumen_giesen:alert] eq "none"))
(set Pushmsg msg title="Haushaltsarbeit" device="Marko_S21Ultra,Marion_S21Ultra" message="Erledigt! Die Blumen wurden gegossen.")
DOELSEIF ([?10:00-20:00] and ([blumen_giesen:alert] eq "normal"))
(set Pushmsg msg title="Haushaltsarbeit" device="Marko_S21Ultra,Marion_S21Ultra" message="Blumen gießen!")
DOELSEIF ([?10:00-20:00] and ([blumen_giesen:alert] eq "priority"))
(set Pushmsg msg title="Haushaltsarbeit" device="Marko_S21Ultra,Marion_S21Ultra" message="Blumen dringend gießen!")
DOELSEIF ([?10:00-20:00] and ([blumen_giesen:alert] eq "urgent"))
(set Pushmsg msg title="Haushaltsarbeit" device="Marko_S21Ultra,Marion_S21Ultra" message="Blumen sind überfällig!")
DOELSE
()
   FUUID      61ab3222-f33f-6c14-856e-caf64f7848a00aaa
   FVERSION   98_DOIF.pm:0.269380/2023-01-01
   MODEL      FHEM
   NAME       blumen_giesen_benachrichtigung
   NOTIFYDEV  global,blumen_giesen
   NR         258
   NTFY_ORDER 50-blumen_giesen_benachrichtigung
   STATE      cmd_1
   TYPE       DOIF
   VERSION    26938 2023-01-01 18:13:32
   eventCount 33
   READINGS:
     2023-02-04 13:24:03   cmd             1
     2023-02-04 13:24:03   cmd_event       blumen_giesen_benachrichtigung
     2023-02-04 13:24:03   cmd_nr          1
     2023-02-04 13:23:09   mode            enabled
     2023-02-04 13:24:03   state           cmd_1
     2023-02-04 13:21:03   timer_01_c01    05.02.2023 10:00:00
     2023-02-04 13:21:03   timer_02_c01    04.02.2023 20:00:00
     2023-02-04 13:21:03   timer_03_c02    05.02.2023 10:00:00
     2023-02-04 13:21:03   timer_04_c02    04.02.2023 20:00:00
     2023-02-04 13:21:03   timer_05_c03    05.02.2023 10:00:00
     2023-02-04 13:21:03   timer_06_c03    04.02.2023 20:00:00
     2023-02-04 13:21:03   timer_07_c04    05.02.2023 10:00:00
     2023-02-04 13:21:03   timer_08_c04    04.02.2023 20:00:00
     2023-02-04 13:24:03   wait_timer      no timer
   Regex:
     accu:
     collect:
     cond:
       blumen_giesen:
         0:
           alert      ^blumen_giesen$:^alert:
         1:
           alert      ^blumen_giesen$:^alert:
         2:
           alert      ^blumen_giesen$:^alert:
         3:
           alert      ^blumen_giesen$:^alert:
   attr:
     cmdState:
     repeatcmd:
       
       10800
       3600
       
     repeatsame:
     wait:
     waitdel:
   condition:
     0          ::DOIF_time($hash,0,1,$wday,$hms) and (::ReadingValDoIf($hash,'blumen_giesen','alert') eq "none")
     1          ::DOIF_time($hash,2,3,$wday,$hms) and (::ReadingValDoIf($hash,'blumen_giesen','alert') eq "normal")
     2          ::DOIF_time($hash,4,5,$wday,$hms) and (::ReadingValDoIf($hash,'blumen_giesen','alert') eq "priority")
     3          ::DOIF_time($hash,6,7,$wday,$hms) and (::ReadingValDoIf($hash,'blumen_giesen','alert') eq "urgent")
   days:
   do:
     0:
       0          set Pushmsg msg title="Haushaltsarbeit" device="Marko_S21Ultra,Marion_S21Ultra" message="Erledigt! Die Blumen wurden gegossen."
     1:
       0          set Pushmsg msg title="Haushaltsarbeit" device="Marko_S21Ultra,Marion_S21Ultra" message="Blumen gießen!"
     2:
       0          set Pushmsg msg title="Haushaltsarbeit" device="Marko_S21Ultra,Marion_S21Ultra" message="Blumen dringend gießen!"
     3:
       0          set Pushmsg msg title="Haushaltsarbeit" device="Marko_S21Ultra,Marion_S21Ultra" message="Blumen sind überfällig!"
     4:
       0         
   helper:
     NOTIFYDEV  global,blumen_giesen
     globalinit 1
     last_timer 8
     sleepdevice blumen_giesen_benachrichtigung
     sleepsubtimer 0
     sleeptimer -1
     timerdev   
     timerevent
     timerevents
     timereventsState
     triggerDev
     DOIF_eventa:
       cmd_nr: 1
       cmd: 1
       cmd_event: blumen_giesen_benachrichtigung
       cmd_1
     DOIF_eventas:
       cmd_nr: 1
       cmd: 1
       cmd_event: blumen_giesen_benachrichtigung
       state: cmd_1
   interval:
     0          -1
     1          0
     2          -1
     3          2
     4          -1
     5          4
     6          -1
     7          6
   intervalfunc:
   localtime:
     0          1675587600
     1          1675537200
     2          1675587600
     3          1675537200
     4          1675587600
     5          1675537200
     6          1675587600
     7          1675537200
   readings:
     all         blumen_giesen:alert
   realtime:
     0          10:00:00
     1          20:00:00
     2          10:00:00
     3          20:00:00
     4          10:00:00
     5          20:00:00
     6          10:00:00
     7          20:00:00
   time:
     0          10:00:00
     1          20:00:00
     2          10:00:00
     3          20:00:00
     4          10:00:00
     5          20:00:00
     6          10:00:00
     7          20:00:00
   timeCond:
     0          0
     1          0
     2          1
     3          1
     4          2
     5          2
     6          3
     7          3
   timer:
     0          0
     1          0
     2          0
     3          0
     4          0
     5          0
     6          0
     7          0
   triggertime:
     1675537200:
       localtime  1675537200
       hash:
     1675587600:
       localtime  1675587600
       hash:
   uiState:
   uiTable:
Attributes:
   alias      Blumen gießen
   do         always
   group      Haushaltsarbeiten
   repeatcmd  :10800:3600::
   room       Benachrichtigungen

[Otto123]

Zeig bitte mal ein List blumen_giesen
Aber auf die Änderung von Attributen gibt es so wahrscheinlich keine Events, wenn Du Deine Logik wirklich mit Attributen und nicht mit Readings aufgebaut hast, hast Du so kein Glück.

Edit: Und Attribute kannst Du in der Art beim DOIF mMn nicht angeben: https://fhem.de/commandref_modular_DE.html#DOIF_Ereignissteuerung

Status werden mit [<devicename>], Readings mit [<devicename>:<readingname>], Internals mit [<devicename>:&<internal>] angegeben.

[Superposchi]

Sorry, natürlich meine ich Readings. Weiß auch nicht wie ich jetzt auf Attribute gekommen bin.

Hier das List des Dummy's:

Code Auswählen Erweitern

Internals:
   FUUID      619fa5ea-f33f-6c14-73f9-549c99895a3a5f32
   FVERSION   98_dummy.pm:0.256060/2022-02-01
   NAME       blumen_giesen
   NR         252
   STATE      Alarm: none [0 Tag(e)]
   TYPE       dummy
   eventCount 26
   READINGS:
     2023-02-04 13:23:35   alert           none
     2023-02-04 13:23:35   days            0
     2023-01-13 19:49:59   mode            auto
Attributes:
   alias      Blumen gießen
   group      Monitoring
   room       Dummy
   stateFormat Alarm: alert [days Tag(e)]

Und zur Vollständigkeit noch das List des 1. DOIF's, welches das Alert-Reading setzt:

Code Auswählen Erweitern

Internals:
   DEF        (([blumen_giesen:mode] eq "auto") and ([blumen_giesen:days] eq "0"))
(setreading blumen_giesen alert none)
DOELSEIF (([blumen_giesen:mode] eq "auto") and ([blumen_giesen:days] eq "2"))
(setreading blumen_giesen alert normal)
DOELSEIF (([blumen_giesen:mode] eq "auto") and ([blumen_giesen:days] eq "3"))
(setreading blumen_giesen alert priority)
DOELSEIF (([blumen_giesen:mode] eq "auto") and ([blumen_giesen:days] eq "4"))
(setreading blumen_giesen alert urgent)
   FUUID      62486206-f33f-6c14-3341-8eafa76a2e758ec3
   FVERSION   98_DOIF.pm:0.269380/2023-01-01
   MODEL      FHEM
   NAME       blumen_giesen_controll
   NOTIFYDEV  global,blumen_giesen
   NR         280
   NTFY_ORDER 50-blumen_giesen_controll
   STATE      cmd_1
   TYPE       DOIF
   VERSION    26938 2023-01-01 18:13:32
   eventCount 40
   READINGS:
     2023-02-04 13:23:35   Device          blumen_giesen
     2023-02-04 13:23:35   cmd             1
     2023-02-04 13:23:35   cmd_event       blumen_giesen
     2023-02-04 13:23:35   cmd_nr          1
     2023-02-04 13:23:35   e_blumen_giesen_days 0
     2023-02-04 13:10:16   mode            enabled
     2023-02-04 13:23:35   state           cmd_1
   Regex:
     accu:
     collect:
     cond:
       blumen_giesen:
         0:
           days       ^blumen_giesen$:^days:
           mode       ^blumen_giesen$:^mode:
         1:
           days       ^blumen_giesen$:^days:
           mode       ^blumen_giesen$:^mode:
         2:
           days       ^blumen_giesen$:^days:
           mode       ^blumen_giesen$:^mode:
         3:
           days       ^blumen_giesen$:^days:
           mode       ^blumen_giesen$:^mode:
   attr:
     cmdState:
     wait:
     waitdel:
   condition:
     0          (::ReadingValDoIf($hash,'blumen_giesen','mode') eq "auto") and (::ReadingValDoIf($hash,'blumen_giesen','days') eq "0")
     1          (::ReadingValDoIf($hash,'blumen_giesen','mode') eq "auto") and (::ReadingValDoIf($hash,'blumen_giesen','days') eq "2")
     2          (::ReadingValDoIf($hash,'blumen_giesen','mode') eq "auto") and (::ReadingValDoIf($hash,'blumen_giesen','days') eq "3")
     3          (::ReadingValDoIf($hash,'blumen_giesen','mode') eq "auto") and (::ReadingValDoIf($hash,'blumen_giesen','days') eq "4")
   do:
     0:
       0          setreading blumen_giesen alert none
     1:
       0          setreading blumen_giesen alert normal
     2:
       0          setreading blumen_giesen alert priority
     3:
       0          setreading blumen_giesen alert urgent
     4:
   helper:
     NOTIFYDEV  global,blumen_giesen
     event      days: 0
     globalinit 1
     last_timer 0
     sleeptimer -1
     timerdev   blumen_giesen
     timerevent days: 0
     triggerDev blumen_giesen
     DOIF_eventa:
       cmd_nr: 1
       cmd: 1
       cmd_event: blumen_giesen
       cmd_1
     DOIF_eventas:
       cmd_nr: 1
       cmd: 1
       cmd_event: blumen_giesen
       state: cmd_1
     timerevents:
       days: 0
       alert: none
     timereventsState:
       days: 0
       alert: none
     triggerEvents:
       days: 0
       alert: none
     triggerEventsState:
       days: 0
       alert: none
   internals:
   readings:
     all         blumen_giesen:mode blumen_giesen:days
   trigger:
   uiState:
   uiTable:
Attributes:
   alias      Blumen gießen
   do         always
   group      Haushaltsarbeiten
   room       Steuerung->Hausarbeiten
   verbose    4

[Sany]

schau Dir das mal an:

Die "days" werden jeden Tag um Mitternacht hochgezählt und ein DOIF setzt das Attribut "alert" bei erreichen bestimmter Werte auf "normal", priority" und "urgent"

...

([?10:00-20:00] and ([blumen_giesen:alert] eq "none"))

damit erklärt sich doch, warum das DOIF nicht auslöst, oder?
Du brauchst entweder einen Trigger, der innerhalb der angegebenen Zeitspanne irgendwie abgefragt wird oder einfach eine feste Zeit, z.B. [10:00], dann kommt die Message halt immer um 10.


Versuch macht kluch!


Gruß



Sany

[Superposchi]

Ok, klar. Hatte vergessen zu erwähnen das es eben auch nicht funktioniert wenn ich das Reading "alert" innerhalb der Zeitspanne ändere. Zum Beispiel in dem ich das 1. DOIF mit Set manuell auslösen.

Die Zeitabfrage ist eigentlich ohne Fragezeichen, das habe ich nur zu Testzwecken eingefügt.

[Sany]

Die Zeitabfrage ist eigentlich ohne Fragezeichen, das habe ich nur zu Testzwecken eingefügt.

dann hätte es ja zum Beginn der Zeitspanne auslösen können.

Seis drum, ich würde jetzt mal so vorgehen: der Dummy muss ein event liefern, damit das DOIF getriggert wird.
- mach einen event-Monitor auf den Dummy
- bau in das 1. DOIF einfach mal eine Zeit ein, die kurz in der Zukunft liegt und beobachte, ob der Dummy dann den gewünschten event liefert:

DEF        (([blumen_giesen:mode] eq "auto") and ([blumen_giesen:days] eq "0"))
   (setreading blumen_giesen alert none)
DOELSEIF (([blumen_giesen:mode] eq "auto") and ([blumen_giesen:days] eq "2"))
   (setreading blumen_giesen alert normal)
DOELSEIF (([blumen_giesen:mode] eq "auto") and ([blumen_giesen:days] eq "3") [14:30])
   (setreading blumen_giesen alert priority)
DOELSEIF (([blumen_giesen:mode] eq "auto") and ([blumen_giesen:days] eq "4"))
   (setreading blumen_giesen alert urgent)

das sollte um 14:30 das setreading auslösen, der Event-Monitor zeigt es dann.

Ganz allgemein: Würden Klammern Geld kost, wärst Du bald ärmer
die mit und verknüften Vergleiche brauchen keine Klammer drum:

([blumen_giesen:mode] eq "auto" and [blumen_giesen:days] eq "0")

reicht.

Probier das mal wie oben vorgeschlagen

[Superposchi]

Sorry, aber das DOIF packe ich nicht an, es funktioniert ja.
Warum soll ich was funktionierendes ändern?

Das Problem besteht ja ausschließlich im 2. DOIF, das auf die Änderung des Alert-Readings reagieren soll.
Und so wie ich es verstehe müsste

Code Auswählen Erweitern

([10:00-20:00] and ([blumen_giesen:alert] eq "normal") beim ändert von "none" in "normal" in der Zeit von 10 bis 20 Uhr getriggert werden.
Die Zeitbegrenzung dient ja dazu, dass die Benachrichtigung nicht Abends und Nachts wiederholt wird bzw. bei Änderung des "alert"-Readings am nächsten Morgen bei Eintritt in die Zeitspanne. Dazu dient ja auch das doelse am Ende.

[Otto123]

hast Du mal geschaut im Eventmonitor ob es wirklich in der richtigen Reihenfolge Events gibt?
Vermutung: Du triggerst mit dem gleichen Device ein DOIF in dem zuletzt ein Reading gesetzt wird. Um Endlosschleifen zu verhindern könnte es sein, das im System vom setreading der Event unterdrückt wird und deshalb bei deinem Nachrichten DOIF nicht ankommt.

[Superposchi]

Code Auswählen Erweitern

2023-02-05 20:05:55.192 dummy blumen_giesen days: 0
2023-02-05 20:05:55.192 dummy blumen_giesen alert: none

Es werden beide Events im Monitor in richtiger Reihenfolge angezeigt.

P.S.:
Ich habe jetzt mal aus dem Event ein DOIF erzeugen lassen. Allerdings ist mir die Schreibweise ein Rätsel.

Code Auswählen Erweitern

([blumen_giesen:"^alert:.none$"])

Statt des eq steht da jetzt ein zweiter Doppelpunkt.

[Otto123]

weil es keine Abfrage mit Vergleich sondern ein Regexp auf ein Event ist 

triggert auf den Reading Teil im Event der mit alert: none beginnt und genau mit dieser Zeichenkette auch aufhört. Der Doppelpunkt ist Teil des Events, siehst Du ja in deinem Eventmonitor.

Nur bringt Dir das nichts, Du willst auf eine Zeit triggern und nicht Mitternacht auf diesen Event.

Ich denke trotzdem, es kann sein, dass DOIF zu diesem Zeitpunkt das Reading noch nicht auswerten kann. Bin mir aber nicht sicher und kann nichts mehr beitragen.

[Sany]

Warum soll ich was funktionierendes ändern?

einfach um mal etwas auszuprobieren? Du kannst es ja direkt danach wieder in was "funktionierendes" ändern.....
Ich schrieb doch: "Ich würde jetzt mal so vorgehen" und "probier das mal aus"
Das musst Du natürlich nicht machen, allerdings sitzt nur Du vor Deinem Bildschirm und wenn Du "geholfen werden willst" müsstes Du vielleicht da auch etwas kooperieren....

2023-02-05 20:05:55.192 dummy blumen_giesen days: 0
2023-02-05 20:05:55.192 dummy blumen_giesen alert: none


Es werden beide Events im Monitor in richtiger Reihenfolge angezeigt.

In der Commandref zu setreading steht evtl. was interessantes, vielleicht ist das ja der Hintergrund:

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.

Vermutlich nutzt DOIF intern auch sowas wie notify, weshalb das dann vielleicht nicht klappt.

Für Deinen Fall könnte man ein wait für alle Zweige einbauen, ich würde da mal 1 sek nehmen, (oder zum testen auch mal 30 sek, dann kannst Du in Ruhe in der Device-Overview nachsehen, ob der Timer angelegt wurde).
also

attr blumen_giesen_controll wait 1:1:1:1

für die vier Zweige.
Und um das auszuprobieren würde ich eben wieder einfach mal eine feste Zeit ins DOIF schreiben und mit dem Eventmonitor zusehen, um eben zügig festzustellen, ob das DOIF das gewünschte macht.
Du kannst natürlich auch bis morgen warten....



Viel Erfolg!


Sany

[Per]

DOIF nutzt soetwas auch, allerdings muss man zusätzlich noch das passende Attribut setzen, um sich selbst zu triggern.

[Otto123]

Danke Per, das ist genau der Punkt den ich meinte. Leider für mich schwer zu finden in der umfangreichen Dokumentation.

[Per]

Kein Ding, wir Leipziger müssen zusammenarbeiten

[Superposchi]

Also irgendwie habe ich das Gefühl, dass die Struktur nicht verstanden wird.

Daher: Ich nutze 3 Devices.
Das 1. ist ein Dummy, welches 2 drei Readings hat - "days", "alert" und "mode" - letzteres ist zu ignorieren, da es sich nur um einen Schalter fürs FTUI handelt.
Das 2. ist ein DOIF, welches auf die Änderung des Readings "days" reagiert und per setreading das Reading "alert" ändert - funktioniert!
Das 3. ist ein DOIF, welches auf die Änderung des Readings "alert" reagiert und per Pushmsg eine Nachricht absetzt - funktioniert nicht.
Sowohl das Event beim ändern des Readings "days" als auch des Readings "alert" wird erzeugt und im Monitor angezeigt.

allerdings muss man zusätzlich noch das passende Attribut setzen, um sich selbst zu triggern.

Stehe da gerade auf dem Schlauch. Beide DOIF's reagieren auf eine Reading-Änderung im Dummy. Eine Triggerung auf sich selbst ist doch nur nötig, wenn im ausführenden DOIF selbst ein Reading geändert würde, oder verstehe ich das falsch?

In der Commandref zu setreading steht evtl. was interessantes, vielleicht ist das ja der Hintergrund:

Wäre nachzuvollziehen wenn das Event nicht im Monitor angezeigt würde. Aber wenn es dort angezeigt wird, muss es doch auch ausgewertet werden, oder nicht? Das mit dem Wait werde ich aber mal probieren und Rückmeldung geben.

Das musst Du natürlich nicht machen, allerdings sitzt nur Du vor Deinem Bildschirm und wenn Du "geholfen werden willst" müsstes Du vielleicht da auch etwas kooperieren....

Der Punkt ist einfach, dass ich mir mit solchen Versuchen mehr als einmal ein laufendes System zerschossen habe, weshalb ich da sehr vorsichtig geworden bin.

[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]

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

Code Auswählen Erweitern

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?

Der 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

[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]

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.

[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]

set blumen_giesen alert normal

funktioniert gar nicht
setzt nur den state, da Du readingList nicht aktiv hast.

Code Auswählen Erweitern

setreading blumen_giesen alert normal wäre Dein Befehl.
Das löst das DOIF nicht aus? Wenn die Zeitscheibe 10:00-20:00 stimmt?

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

[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,

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.

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

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. 

mit oder ohne wait-Attribut im blumen_giesen_controll? Ohne gehts bei mir nicht.

Vielleicht ist es sinnvoll das zweite DOIF mal komplett zu löschen und neu zu erstellen.

ich denke mal, das bringt nix.


Gruß


Sany

[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]

Danke, 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)

Du hattest das wait im 1. DOIF eingefügt, ist das richtig?

siehe #16: https://forum.fhem.de/index.php/topic,132032.msg1262572.html#msg1262572

Das Rückseiten erfolgt aus meinem FTUI heraus

das wollte ich wissen. Alles gut. Dann ist das gelöst?



Gruß


Sany

[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]

@Ottomit oder ohne wait-Attribut im blumen_giesen_controll? Ohne gehts bei mir nicht.

Hi Sany,

ohne wait 

Gruß Otto

[Sany]

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.

das stimmt....

von Otto:
ohne wait 

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.

Beispiel: 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:

Beispiel: 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