[gelöst] DOIF: Relative Zeitangaben

[flurin]

Ich habe ein Problem mit relativen Zeitangaben inkl. Sekunden [+HH:MM:SS]

Code Auswählen Erweitern


define di_init_test DOIF ([+00:00:01]) ({Log(3,"init_done")})


mit oder ohne "do always".

Nach dem "shutdown restart" triggert das DOIF nicht mehr.

So (ohne Sekunden) ist es OK:

Code Auswählen Erweitern


define di_init_test DOIF ([+00:01]) ({Log(3,"init_done")})


Gruss
flurin

[Damian]

Ich habe ein Problem mit relativen Zeitangaben inkl. Sekunden [+HH:MM:SS]

Code Auswählen Erweitern


define di_init_test DOIF ([+00:00:01]) ({Log(3,"init_done")})


wer macht denn sowas? 

Bei mir funktioniert es auch nach dem shutdown restart. Das dürfte eher ein Problem langsamer Hardware sein und nicht des Moduls. Mit der neuen Version von DOIF werden Timer sogar erst dann gesetzt, wenn die Startphase abgeschlossen ist. Triggerung im Sekundentakt würde ich bei FHEM meiden.

Gruß

Damian

[flurin]

wer macht denn sowas? 

Bei mir funktioniert es auch nach dem shutdown restart. Das dürfte eher ein Problem langsamer Hardware sein und nicht des Moduls. Mit der neuen Version von DOIF werden Timer sogar erst dann gesetzt, wenn die Startphase abgeschlossen ist. Triggerung im Sekundentakt würde ich bei FHEM meiden.

Gruß

Damian

Auch beispielsweise mit 30 Sekunden klappt es bei mir nicht. Wenn es bei Dir funktioniert, dann muss ich herausfinden, warum es bei mir nicht geht.

Hardware:
Mac mini, 2.4 GHZ Intel Core 2 Duo, 8 GB RAM, OS X 10.10.2, perl v5.18.2

DOIF:
98_DOIF.pm 8177 2015-03-08 20:24:27Z damian-s $

Gruss
flurin

[flurin]

Nachtrag:

Mit "at" geht's problemlos:

Code Auswählen Erweitern


define at_init_test at +*00:00:02 {Log(3,"at init_done")}


[Damian]

Auch beispielsweise mit 30 Sekunden klappt es bei mir nicht. Wenn es bei Dir funktioniert, dann muss ich herausfinden, warum es bei mir nicht geht.

Hardware:
Mac mini, 2.4 GHZ Intel Core 2 Duo, 8 GB RAM, OS X 10.10.2, perl v5.18.2

DOIF:
98_DOIF.pm 8177 2015-03-08 20:24:27Z damian-s $

Gruss
flurin

An der Hardware kann es also nicht liegen.

Du kannst mit list schauen, ob intern Realtime gesetzt wurde.

Gruß

Damian

[flurin]

An der Hardware kann es also nicht liegen.

Du kannst mit list schauen, ob intern Realtime gesetzt wurde.

Gruß

Damian

Code Auswählen Erweitern


Internals:
   DEF        ([+00:00:20]) ({Log(3,"init_done")})
   NAME       di_init_test
   NR         255
   NTFY_ORDER 50-di_init_test
   STATE      initialized
   TYPE       DOIF
   Readings:
     2015-03-18 17:15:03   cmd_event       timer_1
     2015-03-18 17:15:03   cmd_nr          1
     2015-03-18 17:15:34   state           initialized
     2015-03-18 17:16:18   timer_1_c1      18.03.2015 17:16:38
   Condition:
     0          DOIF_time_once($hash->{timer}{0},$wday,"")
   Days:
   Devices:
   Do:
     0          {Log(3,"init_done")}
   Helper:
     last_timer 1
     sleeptimer -1
   Internals:
   Itimer:
   Readings:
   Realtime:
     0          17:16:38
   State:
   Time:
     0          +00:00:20
   Timecond:
     0          0
   Timer:
     0          0
   Timerfunc:
   Timers:
     0           0
Attributes:
   disable    0
   group      Test


Realtime ist gesetzt.

Ab ca. 40 sec ist es OK.

Grundsätzlich: wenn das Problem nur bei mir ist, dann lohnt es sich nicht, Zeit aufzuwenden.
Ich finde schon eine andere Lösung.

Gruss
flurin

[Damian]

Code Auswählen Erweitern


Internals:
   DEF        ([+00:00:20]) ({Log(3,"init_done")})
   NAME       di_init_test
   NR         255
   NTFY_ORDER 50-di_init_test
   STATE      initialized
   TYPE       DOIF
   Readings:
     2015-03-18 17:15:03   cmd_event       timer_1
     2015-03-18 17:15:03   cmd_nr          1
     2015-03-18 17:15:34   state           initialized
     2015-03-18 17:16:18   timer_1_c1      18.03.2015 17:16:38
   Condition:
     0          DOIF_time_once($hash->{timer}{0},$wday,"")
   Days:
   Devices:
   Do:
     0          {Log(3,"init_done")}
   Helper:
     last_timer 1
     sleeptimer -1
   Internals:
   Itimer:
   Readings:
   Realtime:
     0          17:16:38
   State:
   Time:
     0          +00:00:20
   Timecond:
     0          0
   Timer:
     0          0
   Timerfunc:
   Timers:
     0           0
Attributes:
   disable    0
   group      Test


Realtime ist gesetzt.

Ab ca. 40 sec ist es OK.

Grundsätzlich: wenn das Problem nur bei mir ist, dann lohnt es sich nicht, Zeit aufzuwenden.
Ich finde schon eine andere Lösung.

Gruss
flurin

Ich finde, wir sollten das Problem schon herausfinden - vielleicht bist du nicht der Einzige, bei dem es nicht geht.

Da es bei kurzen Zeiten nicht geht, scheint es ein Timingproblem zu sein (wahrscheinlich dauert die Hochfahrphase bei dir ca. 40 Sekunden)

Die Frage ist nun: Wird Realtime nach dem Hochfahren bei kurzen Zeiten z. B. bei +00:00:01 bei dir gesetzt?

Gruß

Damian

[flurin]

Die Frage ist nun: Wird Realtime nach dem Hochfahren bei kurzen Zeiten z. B. bei +00:00:01 bei dir gesetzt?

Ja, wie beim Beispiel mit 20 sec.

Ich habe bisher schon einige Stunden aufgewendet, bis ich eine einfache Definition hatte, die man leicht reproduzieren kann. Ich muss mal ein wenig abschalten, morgen ist auch ein Tag.

Evtl. hat jemand Zeit und Lust, das obere Beispiel zu testen.

Gruss
flurin

[flurin]

Mit DOIF funktioniert es bei mir nicht, ich habe es mit "at" gelöst.

Code Auswählen Erweitern


define at_init_test at +*00:00:01 {Log(3,"at init_done")}


Eine andere Frage:

Weiss jemand, wie man folgendes "notify" mit DOIF lösen kann?

Code Auswählen Erweitern


define n_init notify global:INITIALIZED {Log(3,"init_done")}


Gruss
flurin

[Damian]

Ja, wie beim Beispiel mit 20 sec.

Ich habe bisher schon einige Stunden aufgewendet, bis ich eine einfache Definition hatte, die man leicht reproduzieren kann. Ich muss mal ein wenig abschalten, morgen ist auch ein Tag.

Evtl. hat jemand Zeit und Lust, das obere Beispiel zu testen.

Gruss
flurin

Du kannst es noch mal mit der angehängten alten Version von DOIF testen:

Gruß

Damian

[flurin]

Du kannst es noch mal mit der angehängten alten Version von DOIF testen:

Gruß

Damian

Danke, leider geht es auch nicht.
Wenn sich sonst niemand mit einem ähnlichen Verhalten meldet, würde ich es nicht weiterverfolgen.

Gruss
flurin

[Damian]

Danke, leider geht es auch nicht.
Wenn sich sonst niemand mit einem ähnlichen Verhalten meldet, würde ich es nicht weiterverfolgen.

Gruss
flurin

OK. Dann weiß ich schon mal, dass es nicht mit dem neuen Mechanismus (setzen der Timer erst, wenn das System hochgefahren ist), den ich in der letzten DOIF-Version eingebaut habe, zusammenhängt.

Wird denn Realtime fortlaufend hochgesetzt in dem Falle, wo es nicht funktioniert? Das wäre ein Zeichen dafür, das das Modul getriggert wird aber nichts macht.

Gruß

Damian

[flurin]

OK. Dann weiß ich schon mal, dass es nicht mit dem neuen Mechanismus (setzen der Timer erst, wenn das System hochgefahren ist), den ich in der letzten DOIF-Version eingebaut habe, zusammenhängt.

Wird denn Realtime fortlaufend hochgesetzt in dem Falle, wo es nicht funktioniert? Das wäre ein Zeichen dafür, das das Modul getriggert wird aber nichts macht.

Gruß

Damian

Ja, es sieht so aus:

Code Auswählen Erweitern


Internals:
   DEF        ([+00:00:01]) ({Log(3,"init_done")})
   NAME       di_init_test
   NR         262
   NTFY_ORDER 50-di_init_test
   STATE      initialized
   TYPE       DOIF
   Readings:
     2015-03-21 10:39:27   cmd_count       5
     2015-03-21 10:39:27   cmd_event       timer_1
     2015-03-21 10:39:27   cmd_nr          1
     2015-03-21 10:39:51   state           initialized
     2015-03-21 10:44:23   timer_1_c1      21.03.2015 10:44:24
   Condition:
     0          DOIF_time_once($hash->{timer}{0},$wday,"")
   Days:
   Devices:
   Do:
     0          {Log(3,"init_done")}
   Helper:
     last_timer 1
     sleeptimer -1
   Internals:
   Itimer:
   Readings:
   Realtime:
     0          10:44:24
   State:
   Time:
     0          +00:00:01
   Timecond:
     0          0
   Timer:
     0          0
   Timerfunc:
   Timers:
     0           0
Attributes:
   disable    0
   do         always
   group      Test
   repeatsame 5

Sowohl  timer_1_c1 wie auch Realtime werden erhöht, wenn ich list mehrmals ausführe.

Gibe es eine nähere Beschreibung über die Bedeutung eines List "DOIF"?

Gruss
flurin

Ergänzung:

Wenn ich das DOIF im laufenden Betrieb starte (DEF-Editor öffnen und schliessen), dann wird der Befehl 5 mal ausgeführt und das Reading (state) rot aktualisiert. Das ist nicht der Fall bei einem Restart, die Aktualisierung ist nur mit einem List DOIF ersichtlich.

[Damian]

Sowohl  timer_1_c1 wie auch Realtime werden erhöht, wenn ich list mehrmals ausführe.

Das ist schon mal gut. Es scheint also ein Problem in DOIF zu sein und nicht in fhem.pl. Es muss irgendeine Information fehlen oder falsch gesetzt sein, dass DOIF meint den Befehl nicht ausführen zu müssen.

Code Auswählen Erweitern

Gibe es eine nähere Beschreibung über die Bedeutung eines List "DOIF"?

Nein. Das sind Interna, die sich immer wieder ändern können. Wozu die gut sind muss ich selbst immer wieder im Sourcecode nachschauen

Code Auswählen Erweitern

Ergänzung:

Wenn ich das DOIF im laufenden Betrieb starte (DEF-Editor öffnen und schliessen), dann wird der Befehl 5 mal ausgeführt und das Reading (state) rot aktualisiert. Das ist nicht der Fall bei einem Restart, die Aktualisierung ist nur mit einem List DOIF ersichtlich.


Das ist für mich logisch und passt zum beschriebenen Fehlverhalten.

Da werden wir ein paar Testausgaben einbauen müssen, um den Fehler bei dir einzukreisen.

Edit:

Den Test solltest du am besten möglichst einfach nur mit dem Attribut do always (ohne repeatsame) ausführen, um weitere Seiteneffekte auszuschließen.

Gruß

Damian

[flurin]

Test solltest du am besten möglichst einfach nur mit dem Attribut do always (ohne repeatsame) ausführen, um weitere Seiteneffekte auszuschließen.

Gruß

Damian

OK, ich hab mir 98_DOIF.pm kurz angeschaut, und Logs eingebaut:

Das kann ich bestätigen: DOIF_cmd wird nicht ausgeführt.