Hallo liebe FHEMler,
ich bin noch recht am Anfang dieser ganzen Materie. Ich habe mir einen watchdog (watchdogSchlafen) geschrieben und in der Def steht folgendes:
FS20_02b700:off 00:00:03 SAME set Deckenbeleuchtung,LampeSofa,LEDStripe,FS_B2 off; setstate watchdogSchlafen defined
FS20_02b700 ist ein FS20 Funkschalter. Nun soll bei Auslösung der ersten Taste (off) die genannte Beleuchtung ausgeschaltet werden, sofern die Taste nicht innerhalb 3 Sekunden nochmal gedrückt wird. Danach soll der watchdog wieder auf defined zurückgesetzt werden. Das Licht wird ausgeschaltet, aber der watchdog behält den State triggered :(
Komischerweise funktioniert mein anderer watchdog problemlos:
Handy_chris:absent 00:03:00 Handy_chris:present set HomeStatusC off; setstate watchdogHomeStatusC defined
Ich sitzte nun echt seit 2 Tagen an nur diesem einen Problem und komme nicht weiter :(
Hat jemand eine Idee?
LG
kapiusers
Fuer diese Art von Problemen ist das sequence Modul zustaendig.
Ansonsten wuesste ich gerne, woher die Idee mit setstate kommt.
Laut Doku sollte fuers reaktivieren "trigger watchdogSchlafen ." verwendet werden.
Hi,
das setstate kommt zB aus dem Beitrag: http://forum.fhem.de/index.php/topic,23260 (http://forum.fhem.de/index.php/topic,23260).
Danke für den Hinweis auf die Doku, habs jetzt auf trigger name_des_watchdog geändert...
Dennoch schaffe is es nicht ihn vernünftig zu nutzen. Er macht meinen raspberry furchtbahr lahm und löst nie aus.
Ich habe diverse BMs und Lichtaktoren in ein structure gepackt, clientstate_behavior last und clientstate_priority on off. Dies schaltet per notify die anwesend auf on und startet den watchdog:
define W_anwesend watchdog anwesend_alle_bewegungsmelder:off|aus 00:30:00 anwesend_alle_bewegungsmelder:on|ein set anwesend value off;; trigger W_anwesend;; set MyTTS tts Niemand mehr da. Schalte alles ab.;;
attr W_anwesend room Startseite
ich steig einfach nicht durch. Mein erstes Problem scheint am structure zu liegen. das hat oft den Wert undefined. Mein zweites Problem ist der Watchdog.
Hat jemand einen Tip für mich, wo/wie ich suchen kann? Ist die Vorgehensweise überhaupt sinnvoll/richtig?
Kann ich eigentlich den Watchdog irgendwo in den Prozessen finden, dann könnte ich evtl. schonmal rausfinden, warum der rpi so lahm wird. Hab das Gefühl, der watchdog startet sich selbst mehrfach oder so...
Ich hänge mich hier mal dran.
Für meine Routine "Bügeleisen wird in FS20FMS eingeschaltet und Musik kommt auf den WLan-Lautsprecher" hatte ich mehrere Jahre einen Code mit setstate (woher der allerdings kommt, weiß ich nicht mehr):
Musik ein:FMS:on 00:00:15 FMS:off {Buegeln}; setstate watchdog_MyPlayer_On defined
Musik ausFMS:off 00:03:00 FMS:on set MyPlayer off; setstate watchdog_MyPlayer_Off defined
sub
Buegeln()
{
fhem("set MyPlayer on");
fhem("set MyPlayer volume 25");
fhem("set MyPlayer http://mp3-live.swr3.de/swr3_m.m3u");
}
Nach Änderung auf
FMS:on 00:00:15 FMS:off {Buegeln}; trigger watchdog_MyPlayer_On
bleibt der Status des watchdog auf "triggered" und beim nächsten Bügeln löst der Watchdog dann nicht mehr aus.
Wo liegt der Fehler, oder was ist mein Denkfehler? Nach Umbau auf die alte Definition mit setstate funktioniert es wieder und meine Frau ist glücklich :-)
Stefan
P.S. die Subroutine wird benötigt, um unterschiedliche Radiosender für bestimmte Aktionen (Wecken, Bettfertig, etc) zu streamen.
Zitattrigger watchdogSchlafen .
Zitat von: Brice am 10 Januar 2016, 14:10:55
...
Nach Änderung auf
FMS:on 00:00:15 FMS:off {Buegeln}; trigger watchdog_MyPlayer_On
bleibt der Status des watchdog auf "triggered" und beim nächsten Bügeln löst der Watchdog dann nicht mehr aus.
Wo liegt der Fehler...
Es fehlt der Punkt am Ende...
FMS:on 00:00:15 FMS:off {Buegeln}; trigger watchdog_MyPlayer_On .
Danke euch beiden. Den "Punkt" hatte ich in der commandref bzw. im Beitrag von Rudolf glatt übersehen. Funktioniert jetzt :-)
Frage (für mich zum Verstehen): ist "setstate <watchdog> defined" deprecated, oder war das eine "Krücke"? Nach Durchsicht meiner cfg-Sicherungen habe ich dies erstmalig ab 01/2013 für "Waschmaschine-fertig" mit FS20FMS genutzt. Lt. meiner Aufzeichnungen dient das gegenseitige "setstate" dazu, dass erst der Einschaltbefehl triggered sein muss, damit der Ausschaltbefehl redefined wird (was ja jetzt auch passiert).
setstate schein in einigen Faellen zu fuktionieren, aber dokumentiert ist es nicht, d.h. es kann ohne Warnung geaendert werden. Und wenn es nicht funktioniert, dann wird es auch nicht gefixt.
Zitat von: Brice am 10 Januar 2016, 17:12:09
...Frage (für mich zum Verstehen): ist "setstate <watchdog> defined" deprecated, oder war das eine "Krücke"? ...
Die Frage ist gar nicht so blöd, denn das "setstate ... defined" steht in diversen Codeschnipseln drin.
Kann es evtl. sein, dass die "Zielsetzung" etwas unterschiedlich ist...
- mit "trigger <watchdog> ." kann der watchdog NACH dem Auslösen wieder "scharf geschaltet" werden
- mit "setstate <watchdog> defined" kann der watchdog VOR dem Auslösen zurückgesetzt werden!?
Das mag alles sein, aber mir als Modulentwickler war das nicht bewusst, und es hat deswegen keinen Bestandschutz :)
Zitat von: rudolfkoenig am 12 Januar 2016, 09:46:43
Das mag alles sein, aber mir als Modulentwickler war das nicht bewusst, und es hat deswegen keinen Bestandschutz :)
Bin jetzt aber auch etwas verwirrt:
Habe gerade bei mir bei einem Watchdog getestet:
- Wenn der Trigger auf "DEFINED" steht, wird der durch "trigger <watchdogname> ." auch korrekt aktiviert
- Wenn der Trigger aktiviert ist, dann wird er durch ein erneutes "trigger <watchdogname> ." nicht abgeschaltet. Der Status bleibt gleich. Laut Doku müsste er doch auf "defined" zurückkehren, wenn er im Zustand "triggered" ist, oder? --> " ... setzt ihn in den Status defined wenn sein status triggered ist. ..."
- Wenn ich ein "setstate <watchdogname> defined" absetze, get der Zustand wieder auf "defined" zurück. Sieht aber so aus, als würde er trotzdem dann beim Erreichen der eingestellten Zeit noch schalten. Laut Deiner Aussage ist das ja auch weder supportet, noch muss es funktionieren? (obwohl ich es an vielen Stellen so gefunden habe ;-))
Was wäre also die korrekte Vorgehensweise, wenn ich einen getriggerten Watchdog abbrechen will, bevor er auslöst?
Moin,
da ich mich kuerzlich auch mit dem watchdog beschaeftigt habe, ist mir eben beim lesen des Threads aufgefallen, das tatsaechlich recht haeufig "setstate" verwendet wird. z.B. hier:
http://www.meintechblog.de/2014/12/fhem-watchdog-zur-automatisierung-einsetzen/
oder hier:
http://forum.fhem.de/index.php?topic=13357.0
ist aber alles halt schon "aelter". Irgendwas muss also mal dazu gefuehrt haben, es so zu verwenden...
Gruss,
Sven
Zitat- Wenn der Trigger aktiviert ist, dann wird er durch ein erneutes "trigger <watchdogname> ." nicht abgeschaltet. Der Status bleibt gleich. Laut Doku müsste er doch auf "defined" zurückkehren, wenn er im Zustand "triggered" ist, oder? --> " ... setzt ihn in den Status defined wenn sein status triggered ist. ..."
Status defined: watchdog ist definiert, und wartet auf Aktivierung. Passiert erstmal nichts.
Status active: wird ausgeloest, falls entweder re1 eintrifft, oder "trigger watchdog ." Falls innerhalb von timeout kein re2 passiert, wird das Kommando ausgefuehrt, und status wird auf triggered gesetzt.
Status triggered: passiert erstmal nichts, es sei denn, man reaktiviert ihn via "trigger watchdog ."
Ich habe das gerade getestet, und funktioniert wie beschrieben.
Ein "trigger watchdog ." im Status active hat keine Auswirkung, das steht aber auch nicht in der Doku.
Zitat von: rudolfkoenig am 10 Februar 2016, 09:41:29
Ein "trigger watchdog ." im Status active hat keine Auswirkung, das steht aber auch nicht in der Doku.
Ok, mir war der 3. Status "active" nicht so bewusst, hatte den eher als "triggered" gesehen.
Bleibt aber immer noch die Frage ob und ggf. wie man einen Watchdog im Status "active" vor Ablauf des Timeouts wieder abbrechen und in den Status "defined" zurückführen kann. Oder gehts das überhaupt nicht (in diesem Fall würde ich es begrüßen, wenn das irgendwann doch mal gehen würde ;-))
Hintergrund in meinem Beispiel: Der Status der zum Auslösen des Watchdogs geführt hat, kann sich nach Ablauf des Timeouts vielleicht schon wieder geändert haben und der Befehl soll dann nicht ausgeführt werden. "re2" hört auf einen anderen triggerals"re1" und kann daher nicht automatisch für einen Abbruch sorgen. Ist vielleicht auch ein wenig speziell.
Derzeit behelfe ich mich, dass ich im Befehl über ein IF abfrage, ob der ursprüngliche Zustand noch existiert und den Befehl nur dann ausführen lasse.
Zitat von: m0urs am 10 Februar 2016, 11:16:08
...Bleibt aber immer noch die Frage ob und ggf. wie man einen Watchdog im Status "active" vor Ablauf des Timeouts wieder abbrechen und in den Status "defined" zurückführen kann. Oder gehts das überhaupt nicht (in diesem Fall würde ich es begrüßen, wenn das irgendwann doch mal gehen würde ;-))
Besser kann man es nicht formulieren. :D
Genau das ist die wesentliche Frage.
Habs implementiert: Wenn der Watchdog aktiviert ist (STATE: Next:...), und "trigger w ." ausgeloest wird, dann wird der Status nach "defined" zurueckversetzt. Kommt mit update ab morgen.
Zitat von: rudolfkoenig am 10 Februar 2016, 19:26:50
Habs implementiert: Wenn der Watchdog aktiviert ist (STATE: Next:...), und "trigger w ." ausgeloest wird, dann wird der Status nach "defined" zurueckversetzt. Kommt mit update ab morgen.
Es ist wirklich unglaublich, wie das hier bei FHEM funktioniert. Ich bin begeistert. Vielen Dank für die Mühe!
Das Thema ist zwar alt, aber beschäftigt mich gerade.
Ich benötige eine Möglichkeit den WD abzubrechen, sodass er auch bei erneutem Tastendrück nicht wieder startet. Mit trigger WD in meinem Notify würde er beim zweiten drücken wieder aktiviert.
Das gleiche bräuchte ich für den aktivierten WD. Also einen Befehl der den WD auf defined setzt egal wie oft er gesendet wird und einen der den WD auf aktiv setzt egal wie oft er gesendet wird.
Bei uns werden die Lichtschalter oft mehrmals betätigt da meine Frau und mein Sohn immer wild und mehrfach auf den Tastern rumdrücken. Wenn dann jeweils der Status des WD gewechselt wird ist das schlecht für meinen Anwendungsfall.
Mit "setstate watchdog defined" kann man den Status zuruecksetzen.
Vielen Dank, dass hier auch meine Anfängerfragen beantwortet werden.
Ich werde also den WD auf defined setzen und danach auf inactiv.
Gibt es für den Fall, dass der watchdog auf per trigger Befehl auf (STATE: Next:...) steht und dort stehen bleiben soll auch einen speziellen Befehl? Ein erneuter trigger Befehl würde den WD ja wieder auf defined setzen.
Nicht das ich wuesste.