DOIF neue Features (Sleep-Alternative)

[Damian]

ist das nicht im Update enthalten? das habe ich gestern erst gemacht.

Die Sache mit der Verzögerung ist realativ einfach

wait 0,3,39 bedeutet einfach

0 Sekunden also keine Verzögerung für:

Code Auswählen Erweitern

  (trigger WEB JS:location="/fhem?room=Überwachung", {UDP_Msg("192.168.2.6" , "wolido:displayon")})

3 Sekunden danach  für:

Code Auswählen Erweitern

  ({UDP_Msg("192.168.2.6" , "wolido:speak:Es hat geklingelt")},trigger WEB JS:location="/fhem?room=Küche")

39 Sekunden danach für:

Code Auswählen Erweitern

  ({UDP_Msg("192.168.2.6" , "wolido:displayoff")})

Der error-code bedeutet nur, dass deine UDP_Msg-Funktion einen Returncode ungleich Null liefert.

Gruß

Damian

[eberlrudi]

Haben wir es vielleicht mit einem Fehler des Moduls zu tun?
Ich habe nochmal alle Zeichen im Code kontrolliert.
Eigentlich sollte alles stimmen.

Dann ist mir aber schleierhaft warum nach ca. 1 Sekunde der Raum wieder zurückgewechselt wird. Das sollte doch erst nach 39 Sekunden der Fall sein.

Hab ich da was übersehen?


Gruß Rudi

[Damian]

Haben wir es vielleicht mit einem Fehler des Moduls zu tun?
Ich habe nochmal alle Zeichen im Code kontrolliert.
Eigentlich sollte alles stimmen.

Dann ist mir aber schleierhaft warum nach ca. 1 Sekunde der Raum wieder zurückgewechselt wird. Das sollte doch erst nach 39 Sekunden der Fall sein.

Hab ich da was übersehen?


Gruß Rudi

Dann fangen wir von vorne an.

Was liefert Version DOIF in der Kommandozeile?

[eberlrudi]

Code Auswählen Erweitern

# $Id: 98_DOIF.pm 9259 2015-09-15 20:49:46Z damian-s $

[Damian]

Code Auswählen Erweitern

# $Id: 98_DOIF.pm 9259 2015-09-15 20:49:46Z damian-s $

ok. Das ist das aktuelle Modul

jetzt mal Ausgabe von "list di_EsKlingelt" hier posten.

[eberlrudi]

Code Auswählen Erweitern

Internals:
   DEF        ([EsKlingelt:?]) (trigger WEB JS:location="/fhem?room=Überwachung", {UDP_Msg("192.168.2.6" , "wolido:displayon")})
  ({UDP_Msg("192.168.2.6" , "wolido:speak:Es hat geklingelt")},trigger WEB JS:location="/fhem?room=Küche")
  ({UDP_Msg("192.168.2.6" , "wolido:displayoff")})
   NAME       di_EsKlingelt
   NR         59
   NTFY_ORDER 50-di_EsKlingelt
   STATE      cmd_1
   TYPE       DOIF
   Readings:
     2015-09-29 22:02:30   Device          EsKlingelt
     2015-09-29 22:03:32   cmd_event       EsKlingelt
     2015-09-29 22:03:32   cmd_nr          1
     2015-09-29 22:03:32   cmd_seqnr       3
     2015-09-29 22:02:30   e_EsKlingelt_events
     2015-09-29 22:03:32   error           {UDP_Msg("192.168.2.6" , "wolido:displayoff")}: send wolido:displayoff
     2015-09-29 22:03:32   state           cmd_1
     2015-09-29 22:03:32   wait_timer      no timer
   Condition:
     0          EventDoIf('EsKlingelt',$hash->{helper}{triggerDev},$hash->{helper}{triggerEvents},'')
   Devices:
     0           EsKlingelt
     all         EsKlingelt
   Do:
     0:
       0          trigger WEB JS:location="/fhem?room=Überwachung", {UDP_Msg("192.168.2.6" , "wolido:displayon")}
       1          {UDP_Msg("192.168.2.6" , "wolido:speak:Es hat geklingelt")},trigger WEB JS:location="/fhem?room=Küche"
       2          {UDP_Msg("192.168.2.6" , "wolido:displayoff")}
   Helper:
     globalinit 1
     last_timer 0
     sleepdevice EsKlingelt
     sleepsubtimer -1
     sleeptimer -1
     triggerDev EsKlingelt
     triggerEvents:

   Internals:
   Itimer:
   Readings:
   State:
   Trigger:
     all         EsKlingelt
Attributes:
   cmdpause   61
   do         always
   wait       0,3,59

[Damian]

Das sieht auch gut aus.

Du kannst auf die Details-Anzeige von di_EsKlingelt wechseln. Dann kann man beim Auslösen von EsKlingelt den Statuswechsel beobachten:

Der Statuswechsel sollte wie folgt stattfinden:

sofort: cmd_1_1
3 Sekunden danach: cmd_1_2
39 Sekunden danach: cmd_1

Gruß

Damian

[eberlrudi]

Puh...

Es werden ja ständig die Räume gewechselt....
Wie kann man das bewerkstelligen?

Morgen ist auch noch ein Tag.


Vielen Vielen Dank für deine Mühen bis hier hin.


mfg Rudi

[Toto1973]

Mir ist da heute morgen auch aufgefallen, das sich DOIF seit dem letzten Update etwas "komisch" verhält.
Ich habe ein DOIF, das mir den State eine Dummys Anwesend auf on oder off setzt.
Damit verbunden ist wiederum ein DOIF, das meine Heizungssteuerung übernimmt. Dort gibt es eine DOELSEIF-Zeile, die dann schalten soll, wenn der State von Anwesend auf off springt.
Heute morgen wurde der State von Anwesend aber mit on gemeldet, und dennoch wurde genau diese DOELSEIF-Zeile getriggert!

Ich hatte extra geschaut, wer da denn nun getriggert hatte.

Dann mal noch eine Verständnis-Frage:
Wenn jetzt ein Device einen Zustand meldet und daraufhin das DOIF geschallten wird, dann sollte doch das DOIF erst dann wieder schalten, wenn sich der Zustand dieses Device ändert!? Ausser ich habe natürlich Do always gesetzt.

Ich kann hier nämlich feststellen, das mir öfters mal der selbe Zustand wieder triggert!

[Damian]

Mir ist da heute morgen auch aufgefallen, das sich DOIF seit dem letzten Update etwas "komisch" verhält.
Ich habe ein DOIF, das mir den State eine Dummys Anwesend auf on oder off setzt.
Damit verbunden ist wiederum ein DOIF, das meine Heizungssteuerung übernimmt. Dort gibt es eine DOELSEIF-Zeile, die dann schalten soll, wenn der State von Anwesend auf off springt.
Heute morgen wurde der State von Anwesend aber mit on gemeldet, und dennoch wurde genau diese DOELSEIF-Zeile getriggert!

Ich hatte extra geschaut, wer da denn nun getriggert hatte.

Dann mal noch eine Verständnis-Frage:
Wenn jetzt ein Device einen Zustand meldet und daraufhin das DOIF geschallten wird, dann sollte doch das DOIF erst dann wieder schalten, wenn sich der Zustand dieses Device ändert!? Ausser ich habe natürlich Do always gesetzt.

Ich kann hier nämlich feststellen, das mir öfters mal der selbe Zustand wieder triggert!

Es kann tatsächlich passieren, dass der gleiche Zustand (ohne do always) zwei Mal nacheinander geschaltet wird, nämlich dann, wenn man einen Loop (eine Rekursion) direkt oder indirekt über mehrere Module einbaut, das hat aber nichts mit dem neuen Modul zu tun.

Ich könnte dieses Problem einfach lösen, wenn ich den Status vor der Ausführung setzen würde, da dieser auf jeden Fall gesetzt wird, unabhängig davon, ob sich das auszuführende Kommando fehlerhaft verhält oder nicht.

Das hätte auf der einen Seite den Vorteil, dass man sogar in der Ausführung bestimmte Readings des Moduls bereits abfragen könnte, auf der anderen Seite wäre das Modul nicht 100% kompatibel zu der jetzigen Version, insb. dann nicht, wenn jemand die Tatsache ausnutzt, dass der Zustand des Moduls sich erst nach der Ausführung verändert.

Ansonsten: Für eine Fehleranalyse sind genaue Angaben mit list des Moduls, Event-Log wichtig, sonst kann ich nichts zu einem möglichen Problem sagen.

Gruß

Damian

[Toto1973]

Alles klar!
Sobald ich den "Fehler" (vielleicht liegt der ja auch bei mir irgendwo) wieder aufspüre, werde ich alles loggen bzw dann hier Posten.

[Brockmann]

Sobald ich den "Fehler" (vielleicht liegt der ja auch bei mir irgendwo) wieder aufspüre, werde ich alles loggen bzw dann hier Posten.

Da ich selbst ein ganz ähnliches Problem mit der aktuellen DOIF-Version hatte, ein kleiner Hinweis: Möglicherweise war der Loop immer schon da, hat sich aber nie manifestiert, weil das Timing mehr oder weniger zufällig passte.
Durch marginale Änderungen an DOIF oder auch an FHEM selbst in Bezug auf das Abarbeiten der Queue hat sich das Timing verändert und nun manifestiert sich der Loop plötzlich. So in etwa war es jedenfalls bei mir. Durch Hinzufügen einer Bedingung, dass die fragliche Statusänderung mindestens x Sekunden her ist, konnte ich mein DOIF "reparieren".

[Damian]

Da ich selbst ein ganz ähnliches Problem mit der aktuellen DOIF-Version hatte, ein kleiner Hinweis: Möglicherweise war der Loop immer schon da, hat sich aber nie manifestiert, weil das Timing mehr oder weniger zufällig passte.
Durch marginale Änderungen an DOIF oder auch an FHEM selbst in Bezug auf das Abarbeiten der Queue hat sich das Timing verändert und nun manifestiert sich der Loop plötzlich. So in etwa war es jedenfalls bei mir. Durch Hinzufügen einer Bedingung, dass die fragliche Statusänderung mindestens x Sekunden her ist, konnte ich mein DOIF "reparieren".

Wenn du etwas Konkretes, Nachvollziehbares hast, dann kannst du es ja hier posten.

Gruß

Damian

[Brockmann]

Wenn du etwas Konkretes, Nachvollziehbares hast, dann kannst du es ja hier posten.

Warum sollte ich das? Wie ich schrieb, habe ich mein Problem gelöst.
Ich wollte mit meinem Hinweis nur dem Fragesteller behilflich sein, weil ich eine gewisse Parallele zwischen meinem Problem und seinem sehe.
Vielleicht hilft ihm ja die Perspektive "In meinem DOIF war immer schon was falsch, nur hat es bislang keine Rolle gespielt." bei der Fehlersuche weiter.

Falls Du aus dem Satz "Durch marginale Änderungen an DOIF oder auch an FHEM selbst in Bezug auf das Abarbeiten der Queue hat sich das Timing verändert" Kritik oder irgendeinen Vorwurf ablesen solltest, siehst Du das falsch.

[eberlrudi]

Also Ich verstehe bei meinem DOIF jetzt gar nichts mehr...

Ich muss das Notify aktiviert lassen, dass DOIF überhaupt funktioniert... Es sieht so aus, als würde DOIF doch nicht ausgelöst werden...


Damian möchtest du dir mein FHEM einmal anschauen? Ich könnte dir eine URL freigeben.