Problem mit watchdog

[tomspatz]

Moin zusammen.
Dieser Hund läuft einwandfrei, ABER er löst nur einmal aus. So wie ich es verstehe musste er doch wenn einmal ausgelöst sofort wieder "scharf" sein und immer wieder auslösen bis das Ereignis vorbei ist.
Wo ist denn da mein Fehler?
Der Code ist direkt aus der fhem.cfg. Die kurze Zeit ist natürlich nur zum testen.

Code Auswählen Erweitern

define FensterBueroUeberwachung watchdog FensterBuero:offen 00:01:00 FensterBuero:geschlossen set PushBenachrichtigungTom msg 'fhem' 'Fenster im Büro ist offen !';; trigger FensterBueroUeberwachung .

Vielen dank

[marco-f]

Ich bin auch nur nach einer Anleitung vorgegangen. Bei mir sieht es wie folgt aus:

Code Auswählen Erweitern

define BadfensterWatch watchdog Bad.Fenster:open|Bad.Fenster:tilted 00:10 Bad.Fenster:closed set gcm send Achtung|Bad|Fenster offen;; setstate BadfensterWatch defined
Durch das setstate ... defined wird der Watchdog zurückgesetzt und löst dann bei erneutem Ereignis wieder aus.

[Otto123]

Hinweis zur Diskussion des Entwicklers 
Gruß Otto

[Benni]

Und in der offiziellen Doku steht auch nichts von setstate,
dafür steht unter Hinweise im 4. Punkt, wie es zu funktionieren hat.
Und ja, der Punkt (.)  dort ist entscheidend.

[tomspatz]

OK

vielleicht könnte mal der Modulentwickler etwas dazu sagen.
Ich denke das mein Ansatz nämlich verkehrt ist.
Der watchdog kann NICHT immer wieder feuern.
Er wird über regex1 gestartet, wartet auf ggf. regex2 innerhalb einer bestimmten Zeit, sonst FEUER.
Hat er aber abgefeuert wird er nur wieder mit regex1 aktiv.

Hoffe das es so richtig ist.
LG
Tom

[Benni]

Hoffe das es so richtig ist.

Nö! Ist es nicht!

Der Watchdog muss nach Auslösung explizit dazu aufgefordert werden wieder auf regex1 zu lauern.
Dazu muss er mit einem Punkt ge-triggert werden.

Dazu muss auch der Modulautor nichts mehr sagen, denn das hat er in der commandref so Beschrieben und sogar in einem Beispiel dargestellt.

[tomspatz]

Moin Benni

was stimmt denn dann zum Teu....l damit nicht?? grrrrrrr
Ich habe den jetzt schon Stunden dran verbracht.
Die Syntax ist richtig, der watchdog steht auf defined. Fenster auf, im state wird Next: 07:57:15 angezeigt (aktuell heute morgen) das ist dann auch der Zeitpunkt wo er auslöst wenn Fenster offen bleibt.
Fenster vorher wieder zu sofort defined im state.
Nach der Zeit löst er aus und dann steht er wieder im state auf defined.
Wobei der Punkt am Ende ja doch da ist.

konfus.

LG
Tom

[Benni]

Nach der Zeit löst er aus und dann steht er wieder im state auf defined.

Ja genau!
Und was erwartest du eigentlich?

[tomspatz]

das er solange das Fenster offen ist alle "eingestellte" Zeit feuert.

[Benni]

Das dachte ich mir 
Allerdings kann der Watchdog das nicht!

Es ginge eventuell, wenn du im Auslöseteil deines Watchdog erst den Watchdog mit trigger-Punkt wieder scharf schaltest und dann direkt nochmal das regex1-Ereignis per trigger (auf den Fensterkontakt) auslöst. Eventuell braucht es aber zwischen dem Scharfschalten und der erneuten Auslösung noch eine zeitl. Verzögerung.

Schau dir doch mal das hier an: http://forum.fhem.de/index.php/topic,36504.0.html

Und wenn du das versuchen möchtest dann bitte das Beispiel am erst einmal komplett 1:1 durcharbeiten und versuchen zu verstehen.

[Otto123]

Du dachtest eher an einen richtigen Wachhund. Das hättest Du aber auch mal so genau sagen können, dass das Dein Problem ist.

Es gibt mit DOIF einen Lösungsansatz mit wait und repeatcmd, kannst Du Dir ja mal in der commandref anschauen.

Auch wenn DOIF stark polarisiert    

Gruß Otto

[tomspatz]

@Qtto123
SORRY aber:

Das hättest Du aber auch mal so genau sagen können, dass das Dein Problem ist.

Habe ich hier:

So wie ich es verstehe musste er doch wenn einmal ausgelöst sofort wieder "scharf" sein und immer wieder auslösen bis das Ereignis vorbei ist.

Ich denke das mein Ansatz nämlich verkehrt ist.
Der watchdog kann NICHT immer wieder feuern.

Bennies Beispiel habe ich auch schon gesehen. Schien mir für einen Anfänger kompliziert.
Muss ich mal mit Zeit dran.

Auf jedem Falle ist es Fakt das der watchdog das so nicht kann.
Schade um die Zeit.

[Otto123]

War eher spaßig gemeint, klar hast Du es so geschrieben aber zumindest ich habe es nicht verstanden. Weil mir klar war, dass ein watchdog so nicht ist, der beißt nur einmal zu.

Wie gesagt der Ansatz mit DOIF ist simpel, Da ist ein konkretes Beispiel mit wait und kurz darunter steht repeatcmd...

Gruß Otto

[t.huber]

Ich hab auch einen ganzen Abend mit der Thematik Watchdog herumgesch.....
Egal was ich gemacht habe entweder waren falsche States geschrieben oder der Watchdog hat sich einfach nicht zurückgesetzt und war "triggered"
Ich hab alles mögliche versucht wie es in div. Anleitungen, HowTo's und CommandReferenzen steht.
Ich versuchte einen Bewegungmelder "einfach" wieder zurückzusetzten. So wie es "einfach" in mehreren Anleitungen steht.

In wirklich vielen Anleitungen steht (sinngemäß) zurücksetzten mit

Code Auswählen Erweitern

define wd watchdog Bewegungsmelder:motion 00:00:10 SAME setreading Bewegungsmelder state nomotion;; setstate wd defined

oder gemäß CommandRef

Code Auswählen Erweitern

define wd watchdog Bewegungsmelder:motion 00:00:10 SAME setreading Bewegungsmelder state nomotion;; trigger wd .

Aber das hat alles nicht zum Erfolg geführt.

Aber erst durch das entfernen des 2. Semikolon hat es bei mir funktioniert.

Code Auswählen Erweitern

define wd watchdog Bewegungsmelder:motion 00:00:10 SAME setreading Bewegungsmelder state nomotion; trigger wd .

Ich weiß dank "Erste Schritte in Fhem" daß ein Semikolon bedeutet daß der Befehl sofort bei Eingabe der Zeile bzw. dem Aufruf ausgeführt wird.
2 Semikolons würde bedeuten dass sofort getriggert wird und dann nach Erfüllung von "00:00:10 SAME" der State auf "nomotion" geändert wird.

Soweit meine (wahrscheinlich falsche) Logik.
Aber dann versteh ich noch weniger warum es mit nur einem Semikolon geht. 
Würde eine sofortige Auslösung des Triggers keine Endlosschleife verursachen ?

(In dem obigen Beispiel hab ich die Zeit absichtlich zum Testen auf 10 Sekunden gestellt; Der Bewegungsmelder kann frühestens nach 15 Sekunden wieder ein ..:motion bringen; also löst der Watchdog immer nach 10 Sekunden aus)

[Benni]

oder gemäß CommandRef

Code Auswählen Erweitern

define wd watchdog Bewegungsmelder:motion 00:00:10 SAME setreading Bewegungsmelder state nomotion;; trigger wd .

Aber das hat alles nicht zum Erfolg geführt.

Aber erst durch das entfernen des 2. Semikolon hat es bei mir funktioniert.

Code Auswählen Erweitern

define wd watchdog Bewegungsmelder:motion 00:00:10 SAME setreading Bewegungsmelder state nomotion; trigger wd .

Ich weiß dank "Erste Schritte in Fhem" daß ein Semikolon bedeutet daß der Befehl sofort bei Eingabe der Zeile bzw. dem Aufruf ausgeführt wird.
2 Semikolons würde bedeuten dass sofort getriggert wird und dann nach Erfüllung von "00:00:10 SAME" der State auf "nomotion" geändert wird.

Soweit meine (wahrscheinlich falsche) Logik.

Die Logik ist folgende:

Wenn der Befehl in der Befehlszeile im im WebIf (FHEMWEB) oder im telnet direkt eingegeben wird, so muss um die Befehle im Ausführungsteil des watchdog zu trennen ein doppeltes Semikolon eingegeben werden, da sonst der 2. Befehl nicht an den Ausführungsteil des watchdog angefügt wird, sonder direkt nach dem define sofort als Befehl ausgeführt wird.

Also 1 Semikolon würde in dem o.g. Beispiel erst den define des watchdog vornehmen und in dessen Ausführungsteil als Befehl das setreading aufhnehmen und nach dem define würde sofort versucht den watchdog mit Punkt zu triggern.

Mit 2 Semikolons wird der watchdog definiert und in den Ausführungsteil des watchdog werden dann die beiden Einzelbefehle setreading und trigger aufgenommen, so dass diese beide ausgeführt werden, wenn der watchdog anschlägt.

Das ist hier aber auch so beschrieben.

[t.huber]

Hm, also du meinst daß sich der Watchdog bzw. die Semikolonverwendung deswegen so "unlogisch" aus Sicht von Anfängern verhält weil sich die Commands wie Watchdogs u.ä. teilweise anders verhalten.
Je nach dem ob sie direkt oben in der Commandleiste eingegeben werden oder ob sie als fertige Definition in der fhem.cfg stehen ?

Wenn dem so wäre kann ich dazu in der FHEM-Referenz nichts zu dem Thema finden.
Das wäre auch doppelt schlecht da nahezu alle Beispiele und Anleitungen den Watchdog mit 2 Semikolons zeigen.

Das wäre ja für Anfänger katastrophal da eigentlich kein Anfänger gleich eine fertige Definiton fertig 100%ig richtig gleich oben eingeben kann.
Das entsteht speziell am Anfang immer durch Anpassen der DEF des Watchdogs im FHEMWEB.

Danke auf alle Fälle schon mal für deine Mühe.

Also 1 Semikolon würde in dem o.g. Beispiel erst den define des watchdog vornehmen und in dessen Ausführungsteil als Befehl das setreading aufhnehmen und nach dem define würde sofort versucht den watchdog mit Punkt zu triggern.

Also zuerst "setreading Bewegungsmelder state nomotion" und danach "trigger wd ."
Genau so macht er es tatsächlich richtig und so ist die praktische Beobachtung.
Aber das wäre genau das Gegenteil von den Anleitungen.

In der CommandRef steht:

Z.B. schaltet die erste der folgenden Befehlszeilen die Lampe 1 nur/erst zur Uhrzeit 07:00 Uhr aus, die Lampe 2 aber sofort und die zweite Befehlszeile schaltet Lampe 1 und 2 um 7:00 Uhr gleichzeitig aus.

define lampoff at 07:00 set Lamp1 off; set Lamp2 off
define lampoff at 07:00 set Lamp1 off;; set Lamp2 off

Also mit 1 Semikolon Lamp2 sofort und Lamp1 um 7Uhr.
Und mit 2 Semikolon beide um 7Uhr.

Genauso steht es in "Erste Schritt in FHEM":

Auch innerhalb eines notify (oder anderen fhem-Befehlen) kann man mehrere Befehle auflisten, jedoch ist hier eines zu beachten:

define n1 notify mySchalter1:on set myLampe1 on;set myLampe2 off

Die Befehle sind durch ein Semikolon getrennt. Effekt ist: Das notify schaltet myLampe1 wann immer mySchalter1 den Event on sendet. Der nächste Befehl in dieser Zeile ist set myLampe2 off. Dieser wird sofort bei der Eingabe der o.g. Befehlszeile abgearbeitet. Es schaltet also myLampe2 sofort, myLampe1 erst nach dem Event von mySchalter1.
Soll auch der zweite Befehl set myLampe2 off erst nach dem Event ausgeführt werden, muss ein doppeltes Semikolon genutzt werden:

define n1 notify mySchalter1:on set myLampe1 on;;set myLampe2 off

Das es in der Praxis sich genau anders herum verhalten kann steht nirgends.
Und leider steigert das meine Verwirrung eher als mich eindeutig zu einem "Aha !!" zu bringen.

[Benni]

Das es in der Praxis sich genau anders herum verhalten kann steht nirgends.

Das ist definitiv auch nicht der Fall, es verhält sich so, wie es da beschrieben steht, das war auch genau das was ich beschrieben habe.

[t.huber]

Ich glaube ich habe die Ursache des Problems gefunden.

Im DEF steht was anderes wie in der gespeicherten fhem.cfg 

Im DEF des Watchdogs:
(http://gdurl.com/vpjm)

In der fhem.cfg steht dann:
(http://gdurl.com/xilK)

Deswegen verhält sich der Watchdog auch mit einem eingestellten Semikolon im DEF anders als in den Anleitungen beschrieben.

Aus ;; im DEF wird dann z.B. ;;;; in der fhem.cfg


Ihr könnt mir natürlich irgendwas erzählen von "das ist schon richtig so" oder "It's no Bug its a feature" ...
Das ist in meinen Augen ein Fehler.
Es mag sein daß es aus Programmierer-Sicht logisch und richtig ist.
Aber genau so was führt dazu daß kein Anfänger die watchdogs versteht.
Sieht man ja schon allein daran wie oft das Problem im Forum angesprochen wird.

[Benni]

Jetzt wirfst du hier aber auch vollends alles durcheinander, DEF-Bereich, fhem.cfg und WebIF-Kommandozeile.

Ich habe deswegen explizit nur von der WebIF Kommandozeile (oder telnet) gesprochen und von der geht die Commandref an der Stelle auch aus.

Also nochmal, diesmal noch etwas abstrakter:
In der Kommandozeile musst du zwei Semikolons eingeben, wenn du nachher im DEF-Bereich eines stehen haben willst.

Genauso werden in die fhem.cfg 2 Semikolons geschrieben, wenn nachher im DEF-Bereich eines stehen soll. Es wird ja beim Start von FHEM im wesentlichen auch erst mal nichts anderes gemacht, als die devices wieder per define anzulegen, so als ob sie über die Kommandozeile eingegeben würden.

Und dass man sich als Anfänger am besten auch erst mal gar nicht um den Inhalt fhem.cfg kümmern sollte wurde ja auch schon in unzähligen Threads hier diskutiert.

[t.huber]

In der Kommandozeile musst du zwei Semikolons eingeben, wenn du nachher im DEF-Bereich eines stehen haben willst.

Genauso werden in die fhem.cfg 2 Semikolons geschrieben, wenn nachher im DEF-Bereich eines stehen soll.

Dann sind die sinngemäßen Inhalte der WebIF-Kommandozeile und der fhem.cfg gleich und nur in der DEF steht immer was anderes.
Oder ?

Dann wäre es egal das ich die fhem.cfg "dazugenommen habe".
Weil ja auch WebIF-Kommandozeile und DEF unterschiedlich sind. 
Das ist ja genauso schlimm.


Auf was beziehen sich dann die ganzen Anleitungen und Command-Ref's ?
Auf WebIF-Kommandozeile und fhem.cfg
oder auf die Definitionen in der DEF ?

[marvin78]

Leider ist das sehr unterschiedlich. Das ist sehr schade, ist aber so.

[Otto123]

Auf was beziehen sich dann die ganzen Anleitungen und Command-Ref's ?
Auf WebIF-Kommandozeile und fhem.cfg
oder auf die Definitionen in der DEF ?

Das ist wirklich schwierig