Ich habe ein Problem mit relativen Zeitangaben inkl. Sekunden [+HH:MM:SS]
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:
define di_init_test DOIF ([+00:01]) ({Log(3,"init_done")})
Gruss
flurin
Zitat von: flurin am 18 März 2015, 14:05:39
Ich habe ein Problem mit relativen Zeitangaben inkl. Sekunden [+HH:MM:SS]
define di_init_test DOIF ([+00:00:01]) ({Log(3,"init_done")})
wer macht denn sowas? :o
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
Zitat von: Damian am 18 März 2015, 14:57:30
wer macht denn sowas? :o
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
Nachtrag:
Mit "at" geht's problemlos:
define at_init_test at +*00:00:02 {Log(3,"at init_done")}
Zitat von: flurin am 18 März 2015, 15:08:54
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
Zitat von: Damian am 18 März 2015, 16:52:21
An der Hardware kann es also nicht liegen.
Du kannst mit list schauen, ob intern Realtime gesetzt wurde.
Gruß
Damian
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
Zitat von: flurin am 18 März 2015, 17:23:14
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
Zitat von: Damian am 18 März 2015, 17:32:19
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
Mit DOIF funktioniert es bei mir nicht, ich habe es mit "at" gelöst.
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?
define n_init notify global:INITIALIZED {Log(3,"init_done")}
Gruss
flurin
Zitat von: flurin am 18 März 2015, 18:35:30
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
Zitat von: Damian am 19 März 2015, 21:25:36
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
Zitat von: flurin am 21 März 2015, 10:13:18
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
Zitat von: Damian am 21 März 2015, 10:30:58
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:
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.
Zitat von: flurin am 21 März 2015, 10:48:25
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.
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 ;)
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
Zitat von: Damian am 21 März 2015, 11:40:33
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.
Aktualisierung:
Ich habe heute mein Mac mini nach einem Update booten müssen. Ich vermute, dass irgendwas gesetzt war.
Zumindest funktioniert es jetzt ohne repeatesame!
Mit repeatsame geht es jedoch nicht.
Edit:
Ich vermute, es liegt am:
my $last_cmd=ReadingsVal($pn,"cmd_nr",0)-1;
Beim Start ist ReadingsVal($pn,"cmd_nr",0) = 1 => $last_cmd = 0
Im Betrieb ist ReadingsVal($pn,"cmd_nr",0) = 0 => $last_cmd = -1
Zitat von: flurin am 21 März 2015, 12:15:13
Aktualisierung:
Ich habe heute mein Mac mini nach einem Update booten müssen. Ich vermute, dass irgendwas gesetzt war.
Zumindest funktioniert es jetzt ohne repeatesame!
Mit repeatsame geht es jedoch nicht.
Edit:
Ich vermute, es liegt am:
my $last_cmd=ReadingsVal($pn,"cmd_nr",0)-1;
Beim Start ist ReadingsVal($pn,"cmd_nr",0) = 1 => $last_cmd = 0
Im Betrieb ist ReadingsVal($pn,"cmd_nr",0) = 0 => $last_cmd = -1
Dass nach dem Neustart mit repeatsame etwas nicht ausgeführt wird, ist ganz normal (es wurde ja bereits wiederholt). Genauso, wie der letzte Zustand auch nicht wiederholt wird, wenn du kein do always definiert hast.
Wenn du das Modul beim Neustart initialisieren möchtest, musst du das Attribut
initialize benutzen ;)
Gruß
Damian
Zitat von: Damian am 21 März 2015, 14:51:25
Dass nach dem Neustart mit repeatsame etwas nicht ausgeführt wird, ist ganz normal (es wurde ja bereits wiederholt). Genauso, wie der letzte Zustand auch nicht wiederholt wird, wenn du kein do always definiert hast.
Wenn du das Modul beim Neustart initialisieren möchtest, musst du das Attribut initialize benutzen ;)
Gruß
Damian
Okay, und warum hast Du nicht schon früher darauf hingewiesen, wenn das normal ist ;)
Gruss
flurin
Zitat von: flurin am 21 März 2015, 16:11:56
Okay, und warum hast Du nicht schon früher darauf hingewiesen, wenn das normal ist ;)
Gruss
flurin
Wir reden jetzt seit drei Tagen über ein Problem, was offenbar keins ist. Warum hast du heute erst zum ersten Mal repeatsame erwähnt?
Gruß
Damian
Zitat von: Damian am 21 März 2015, 16:37:40
Wir reden jetzt seit drei Tagen über ein Problem, was offenbar keins ist. Warum hast du heute erst zum ersten Mal repeatsame erwähnt?
Gruß
Damian
1.
Zitat
Grundsätzlich: wenn das Problem nur bei mir ist, dann lohnt es sich nicht, Zeit aufzuwenden.
2.
Zitat
Wenn sich sonst niemand mit einem ähnlichen Verhalten meldet, würde ich es nicht weiterverfolgen.
Ich hatte am Anfang
bei mir ein Problem auch ohne repeatsame!!!
Danke anyway. Ich habe schon lange eine andere Lösung :)
Gruss
flurin
Zitat von: flurin am 21 März 2015, 17:42:22
1.
2.
Ich hatte am Anfang bei mir ein Problem auch ohne repeatsame!!!
Danke anyway. Ich habe schon lange eine andere Lösung :)
Gruss
flurin
OK. Dann ist es für mich dennoch unerklärbar, wie sich dieses Problem in Luft auflösen kann, wenn wir vom Anfang an von der gleichen Version des Moduls reden.
Wenn es wieder ohne repeatsame nicht funktioniert, dann musst du dich noch mal melden.
Gruß
Damian
Zitat von: Damian am 21 März 2015, 18:48:30
... wie sich dieses Problem in Luft auflösen kann, ...
Eine Begründung habe ich doch gegeben:
Zitat
Ich habe heute mein Mac mini nach einem Update booten müssen. Ich vermute, dass irgendwas gesetzt war.
Eine Erklärung habe ich nicht aber die Tücken der Betriebssysteme (Linux, OS X, Windows usw.) sind allgemein bekannt.
Oft geht es nur nach einem Restart des Betriebssystems.
Zudem ist es für mich immer noch ein Rätsel, warum es mit einem "at" von Anfang an funktioniert hat (siehe oben).
Gruss
flurin
Zitat von: flurin am 21 März 2015, 20:50:05
Eine Begründung habe ich doch gegeben:
Eine Erklärung habe ich nicht aber die Tücken der Betriebssysteme (Linux, OS X, Windows usw.) sind allgemein bekannt.
Oft geht es nur nach einem Restart des Betriebssystems.
Zudem ist es für mich immer noch ein Rätsel, warum es mit einem "at" von Anfang an funktioniert hat (siehe oben).
Gruss
flurin
Ich gehe inzwischen eher von einem Verständnisproblem aus, denn im ersten list z. B. hast du kein do always angegeben und da gilt das Gleiche wie bei repeatsame: Bei modify über DEF-Editor wird das Modul initialisiert (der kommende Trigger führt zur Ausführung), beim Reboot dagegen nicht, deswegen wird in diesem Fall im Gegensatz zu at ein Befehl nicht erneut ausgeführt.
Gruß
Damian
Zitat von: Damian am 21 März 2015, 21:05:44
Ich gehe inzwischen eher von einem Verständnisproblem aus, denn im ersten list z. B. hast du kein do always angegeben und da gilt das Gleiche wie bei repeatsame: Bei modify über DEF-Editor wird das Modul initialisiert (der kommende Trigger führt zur Ausführung), beim Reboot dagegen nicht, deswegen wird in diesem Fall im Gegensatz zu at ein Befehl nicht erneut ausgeführt.
Gruß
Damian
Was das Verständnisproblem anbelangt, verweise ich auf mein erstes Posting in diesem Thread. Da steht auch ein Satz über "do always". So wie ich es sehe, ist die Lösung nicht so trivial, sonst wärst du bereits bei der ersten Antwort auf "initialize" gekommen.
Gruss
flurin
Zitat von: flurin am 22 März 2015, 16:22:13
Was das Verständnisproblem anbelangt, verweise ich auf mein erstes Posting in diesem Thread. Da steht auch ein Satz über "do always". So wie ich es sehe, ist die Lösung nicht so trivial, sonst wärst du bereits bei der ersten Antwort auf "initialize" gekommen.
Gruss
flurin
Doch ein Verständnisproblem. Bei do always ohne irgendwelche Übersteuerung brauchst du
kein initialize!. Beide lists die du geliefert hast, passen nicht zum Problem, da entweder kein do always oder repeatsame, welches do always übersteuert. Daher verhielt sich das Modul bei beiden Nachweisen korrekt wie programmiert.
Gruß
Damian
OK. Ich werde es nochmals untersuchen, wenn ich das ursprüngliche Verhalten reproduzieren kann.
Gruss
flurin