wait_timer: no timer -> Ausführungsteil wird nicht vollständig ausgeführt

[gadget]

Hallo,

Ich habe ein DOIF, das mir immer wieder Kummer macht.
Struktur ist (vereinfacht) so:

Code Auswählen Erweitern


( ([dummy1] eq "on")
   and
  ([06:30|1234])
)

(set lampe1 on)
(set lampe2 on)
(set lampe3 on)

DOELSEIF

( ([dummy1] eq "on")
   and
  ([07:30|1234])
)

(set lampe1 off)
(set lampe2 off)
(set lampe3 off)



Die Befehle im Ausführungsteil sind mit

attr ... wait 0,10,10:0,10,10

verzögert.

Es kommt immer wieder vor, dass im Ausführungsteil einzelne Befehle nicht ausgeführt werden (Lampen werden nicht eingeschaltet bzw. nicht wieder ausgeschaltet).

Wenn das passiert steht im Log

DOIF di_name wait_timer: no timer

Das ganze passiert sporadisch und ohne erkennbares Muster. Ich habe schon nach dieser "no timer" Meldung im Forum gesucht, aber alles was ich bislang gefunden habe passt nicht so recht zu meiner Situation.
Ich hatte einen leeren DOELSE Zweig, den ich auch schon entfernt habe, aber das hat nichts geändert.

Vorschläge oder Ideen wie ich der Sache auf den Grund gehen kann ?

Grüße,

gadget.

[Ellert]

no timer ist ein Event, wenn alle Waittimer eines Zweiges abgelaufen sind, also nichts besonderes.

Setze hinter jeden set-Befehl einen Log Befehl, dann kannst Du feststellen, ob der Zweig ausgeführt wurde oder die Timer wirklich abgebrochen wurden.

Beispiel:

Code Auswählen Erweitern

(set lampe 1 on, {Log 1, "lampe 1 on"})

Dass die Lampen nicht schalten kann auch am Übertragungsweg liegen.

set lampe 1 on

sieht irgendwie ungewöhnlich aus, was sind das für Lampen?

[Damian]

Insb. wird ein Timer abgebrochen (und damit die Ausführung des Befehls nicht erfolgt), wenn vor dem Ablauf des Timers aufgrund der Definition wieder ein anderer Zweig zuschlägt. Das ist im Konzept des DOIF-Moduls so vorgesehen.

[gadget]

Hallo,

Danke schon mal für die Antworten. Das mit lampe 1 on ist natürlich Quatsch, hab´s geändert. Ich wollte nur das allgemeine Schema darstellen, das DOIF schaltet diverse Aktoren und hat insgesamt 9 Fälle.

Das mit dem zusätzichen Log brauche ich eigentlich nicht, ich kann die Ausführung eines Zweigs ja erzwingen und dann sehe ich im Eventmonitor mit zugeschalteten fhem log  auch so schon was geschaltet wird und was nicht. Dass die Verarbeitung abgebrochen wird, wenn die Bedingungen eines anderer Zweigs wahr werden, leuchtet mir ein. Das wäre eine plausible Erklärung wenn lampe1 und lampe2 eingeschaltet werden und lampe 3 nicht. Ich habe aber auch den Fall, dass lampe1 eingeschaltet wird, bei lampe2 das "no timer" kommt und dann lampe3 eingeschaltet wird. Dass passt irgendwie nicht zusammen.

Was ich in der schematischen Darstellung als dummy1 drin habe ist übrigens ein reading aus dem presence modul, das in kurzen Abständen aktualisiert wird (sich aber typischerweise während der Ausführung eines DOIF-Zweigs nicht ändert). Ich habe PioTek-Tracker im Einsatz, die alle paar Sekunden ein "bin noch da" melden, erst wenn das für mehrere Minuten nicht mehr der Fall ist und ein watchdog abläuft, ändert sich das reading tatsächlich mal. Kann das hier eine Rolle spielen ?

Wenn ich aus meinen 9 DOIF Zweigen 9 getrennte DOIFs mache, dürfte das Problem des Abbruchs von timern ja dann eigentlich nicht mehr bestehen, oder ? Geht das nicht auch eleganter (über ein attr oder so) ?

Grüße,

gadget

[Damian]

Code Auswählen Erweitern

dass lampe1 eingeschaltet wird, bei lampe2 das "no timer" kommt und dann lampe3 eingeschaltet wird. Dass passt irgendwie nicht zusammen.


Dass lampe3 eingeschaltet wird, ohne dass zuvor lampe2 eingeschaltet wurde, kann aufgrund der Definition eigentlich nicht vorkommen.

[Ellert]

Hallo,

Danke schon mal für die Antworten. Das mit lampe 1 on ist natürlich Quatsch, hab´s geändert. Ich wollte nur das allgemeine Schema darstellen, das DOIF schaltet diverse Aktoren und hat insgesamt 9 Fälle.

Das mit dem zusätzichen Log brauche ich eigentlich nicht, ich kann die Ausführung eines Zweigs ja erzwingen und dann sehe ich im Eventmonitor mit zugeschalteten fhem log  auch so schon was geschaltet wird und was nicht. Dass die Verarbeitung abgebrochen wird, wenn die Bedingungen eines anderer Zweigs wahr werden, leuchtet mir ein. Das wäre eine plausible Erklärung wenn lampe1 und lampe2 eingeschaltet werden und lampe 3 nicht. Ich habe aber auch den Fall, dass lampe1 eingeschaltet wird, bei lampe2 das "no timer" kommt und dann lampe3 eingeschaltet wird. Dass passt irgendwie nicht zusammen.

Was ich in der schematischen Darstellung als dummy1 drin habe ist übrigens ein reading aus dem presence modul, das in kurzen Abständen aktualisiert wird (sich aber typischerweise während der Ausführung eines DOIF-Zweigs nicht ändert). Ich habe PioTek-Tracker im Einsatz, die alle paar Sekunden ein "bin noch da" melden, erst wenn das für mehrere Minuten nicht mehr der Fall ist und ein watchdog abläuft, ändert sich das reading tatsächlich mal. Kann das hier eine Rolle spielen ?

Wenn ich aus meinen 9 DOIF Zweigen 9 getrennte DOIFs mache, dürfte das Problem des Abbruchs von timern ja dann eigentlich nicht mehr bestehen, oder ? Geht das nicht auch eleganter (über ein attr oder so) ?

Grüße,

gadget

Der PRESENCE Standardwert ist 30 Sekunden , da könnte schon leicht ein Event dazwischen kommen.

Mehrere DOIF würde ich nehmen, wenn sie unabhängige Dinge bedienen, sonst nach der goldenen Regel, wer einschaltet, sollte auch ausschalten.

Man kann die Zweige auch gegeneinander verriegeln damit alle Timer ablaufen.

[gadget]

Man kann die Zweige auch gegeneinander verriegeln damit alle Timer ablaufen.

Wie macht man das ? Ich bin ja eigentlich davon ausgegangen dass das durch die unterschiedlichen Startzeiten der Zweige schon sichergestellt ist.

Grüße, gadget.

[Ellert]

Ich bin ja eigentlich davon ausgegangen dass das durch die unterschiedlichen Startzeiten der Zweige schon sichergestellt ist.

Für Dein Beispiel ist die Annahme richtig, Du hast uns aber 7 Zweige vorenthalten, da kann sonst was passieren, ich sag nur PRESENCE.

Wie macht man das ?

Der zu verriegelnde Zweig fragt den Status des Zweigs <x> ab, der vorher abgearbeitet sein soll, z.B.

Code Auswählen Erweitern

DOELSEIF (<Bedingung> and [$SELF] eq "cmd_<x>")
Bei Bedarf selftrigger verwenden.

[gadget]

Hallo,

Danke für die Erklärung zum "Verriegeln". Ein 100%iger Ersatz für ein Feature "immer erst einen Zweig abarbeiten bevor ein anderer Zweig berücksichtigt wird" ist das aber IMHO auch nicht, weil ich ja nicht immer eine eindeutige Abhängigkeit zu einem anderen Zweig habe, der vorher ausgeführt sein muss (insbesondere wenn die auslösenden Events nichtdeterministisch sind).

Für mein Problem habe ich mir nun folgende Simulation gebaut:

Code Auswählen Erweitern


defmod di_test DOIF ( ([dummy1] eq "on")\
   and\
  ([12:08])\
)\
\
(set lampe1 on)\
(set lampe2 on)\
(set lampe3 on)\
\
DOELSEIF\
\
( ([dummy1] eq "on")\
   and\
  ([12:09])\
)\
\
(set lampe1 off)\
(set lampe2 off)\
(set lampe3 off)
attr di_test room Test
attr di_test wait 0,10,10:0,10,10


defmod dummy1 dummy
attr dummy1 room Test
attr dummy1 webCmd on:off

defmod lampe1 dummy
attr lampe1 room Test
attr lampe1 webCmd on:off
setstate lampe1 off

defmod lampe2 dummy
attr lampe2 room Test
attr lampe2 webCmd on:off
setstate lampe2 off

defmod lampe3 dummy
attr lampe3 room Test
attr lampe3 webCmd on:off
setstate lampe3 off


Den dummy1 lasse ich von der Shell aus jede Sekunde auf on setzen (simulation des geschwätzigen Presence Moduls:

Code Auswählen Erweitern


while true; do /opt/fhem/fhem.pl localhost:7072 "set dummy1 on"; sleep 1; done


Im Eventmonitor sieht das dann so aus:

Code Auswählen Erweitern



2018-02-04 12:07:47 dummy dummy1 on
2018-02-04 12:07:49 dummy dummy1 on
2018-02-04 12:07:50 dummy dummy1 on
2018-02-04 12:07:57 dummy dummy1 on
2018-02-04 12:07:58 dummy dummy1 on
2018-02-04 12:08:00 dummy lampe1 on
2018-02-04 12:08:00 DOIF di_test cmd_nr: 1
2018-02-04 12:08:00 DOIF di_test cmd_seqnr: 1
2018-02-04 12:08:00 DOIF di_test cmd: 1.1
2018-02-04 12:08:00 DOIF di_test cmd_event: timer_1
2018-02-04 12:08:00 DOIF di_test cmd_1_1
2018-02-04 12:08:00 DOIF di_test wait_timer: 04.02.2018 12:08:10 cmd_1_2 timer_1
2018-02-04 12:08:00 dummy dummy1 on
2018-02-04 12:08:01 dummy dummy1 on
2018-02-04 12:08:02 dummy dummy1 on
2018-02-04 12:08:04 dummy dummy1 on
2018-02-04 12:08:05 dummy dummy1 on
2018-02-04 12:08:07 dummy dummy1 on
2018-02-04 12:08:08 dummy dummy1 on
2018-02-04 12:08:09 dummy dummy1 on
2018-02-04 12:08:10 DOIF di_test wait_timer: no timer
2018-02-04 12:08:10 dummy lampe2 on
2018-02-04 12:08:10 DOIF di_test cmd_nr: 1
2018-02-04 12:08:10 DOIF di_test cmd_seqnr: 2
2018-02-04 12:08:10 DOIF di_test cmd: 1.2
2018-02-04 12:08:10 DOIF di_test cmd_event: timer_1
2018-02-04 12:08:10 DOIF di_test cmd_1_2
2018-02-04 12:08:10 DOIF di_test wait_timer: 04.02.2018 12:08:20 cmd_1_3 timer_1
2018-02-04 12:08:11 dummy dummy1 on
2018-02-04 12:08:12 dummy dummy1 on
2018-02-04 12:08:13 dummy dummy1 on
2018-02-04 12:08:15 dummy dummy1 on
2018-02-04 12:08:16 dummy dummy1 on
2018-02-04 12:08:17 dummy dummy1 on
2018-02-04 12:08:19 dummy dummy1 on
2018-02-04 12:08:20 DOIF di_test wait_timer: no timer
2018-02-04 12:08:20 dummy lampe3 on
2018-02-04 12:08:20 DOIF di_test cmd_nr: 1
2018-02-04 12:08:20 DOIF di_test cmd_seqnr: 3
2018-02-04 12:08:20 DOIF di_test cmd: 1.3
2018-02-04 12:08:20 DOIF di_test cmd_event: timer_1
2018-02-04 12:08:20 DOIF di_test cmd_1
2018-02-04 12:08:20 dummy dummy1 on
2018-02-04 12:08:22 dummy dummy1 on
2018-02-04 12:08:23 dummy dummy1 on
2018-02-04 12:08:24 dummy dummy1 on
2018-02-04 12:08:26 dummy dummy1 on
2018-02-04 12:08:27 dummy dummy1 on
2018-02-04 12:08:29 dummy dummy1 on

(...)

2018-02-04 12:08:49 dummy dummy1 on
2018-02-04 12:08:50 dummy dummy1 on
2018-02-04 12:08:56 dummy dummy1 on
2018-02-04 12:08:57 dummy dummy1 on
2018-02-04 12:08:59 dummy dummy1 on
2018-02-04 12:09:00 dummy lampe1 off
2018-02-04 12:09:00 DOIF di_test cmd_nr: 2
2018-02-04 12:09:00 DOIF di_test cmd_seqnr: 1
2018-02-04 12:09:00 DOIF di_test cmd: 2.1
2018-02-04 12:09:00 DOIF di_test cmd_event: timer_2
2018-02-04 12:09:00 DOIF di_test cmd_2_1
2018-02-04 12:09:00 DOIF di_test wait_timer: 04.02.2018 12:09:10 cmd_2_2 timer_2
2018-02-04 12:09:00 dummy dummy1 on
2018-02-04 12:09:02 dummy dummy1 on
2018-02-04 12:09:03 dummy dummy1 on
2018-02-04 12:09:04 dummy dummy1 on
2018-02-04 12:09:06 dummy dummy1 on
2018-02-04 12:09:07 dummy dummy1 on
2018-02-04 12:09:08 dummy dummy1 on
2018-02-04 12:09:10 DOIF di_test wait_timer: no timer
2018-02-04 12:09:10 dummy lampe2 off
2018-02-04 12:09:10 DOIF di_test cmd_nr: 2
2018-02-04 12:09:10 DOIF di_test cmd_seqnr: 2
2018-02-04 12:09:10 DOIF di_test cmd: 2.2
2018-02-04 12:09:10 DOIF di_test cmd_event: timer_2
2018-02-04 12:09:10 DOIF di_test cmd_2_2
2018-02-04 12:09:10 DOIF di_test wait_timer: 04.02.2018 12:09:20 cmd_2_3 timer_2
2018-02-04 12:09:10 dummy dummy1 on
2018-02-04 12:09:11 dummy dummy1 on
2018-02-04 12:09:13 dummy dummy1 on
2018-02-04 12:09:14 dummy dummy1 on
2018-02-04 12:09:15 dummy dummy1 on
2018-02-04 12:09:17 dummy dummy1 on
2018-02-04 12:09:18 dummy dummy1 on
2018-02-04 12:09:19 dummy dummy1 on
2018-02-04 12:09:20 DOIF di_test wait_timer: no timer
2018-02-04 12:09:20 dummy lampe3 off
2018-02-04 12:09:20 DOIF di_test cmd_nr: 2
2018-02-04 12:09:20 DOIF di_test cmd_seqnr: 3
2018-02-04 12:09:20 DOIF di_test cmd: 2.3
2018-02-04 12:09:20 DOIF di_test cmd_event: timer_2
2018-02-04 12:09:20 DOIF di_test cmd_2
2018-02-04 12:09:21 dummy dummy1 on
2018-02-04 12:09:22 dummy dummy1 on
2018-02-04 12:09:23 dummy dummy1 on




Die Dummy-Lampen schalten also wie gewünscht (trotz der "no timer" Meldungen). Das DOIF lässt sich in der Abarbeitung auch nicht durch das Hämmern auf dummy1 aus dem Tritt bringen. Da muss ich dann mein Real-World Problem wohl noch etwas weiter zerlegen.

Trotzdem natürlich nochmal danke für Euere Vorschläge und Erklärungen.

Grüße,

gadget