Watchdog State triggered obwohl setstate defined

Begonnen von kapiusers, 12 November 2015, 20:16:07

Vorheriges Thema - Nächstes Thema

kapiusers

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

rudolfkoenig

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.

simonTS

Hi,

das setstate kommt zB aus dem Beitrag:  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...
FHEM auf wheezy@RPI-->
KNX: MDT STV-0320.01|SCN-IP000.01|AMI-1216.01|JAL-0810.01|AKD-0401.01|AKH-0800.01|BE-GTT4W.01|SCN-P360D1.01|SCN-G360K3.01|ABB-MRS/W Magnet-Reedkontakt|Zisterne:SRF06|LED:XCSOURCE WIFI Controller|

Brice

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.
FHEM auf RPi 4 4GB (Buster) | produktiv) CUL 868 für FS20 | S300TH | KS300 | Max!Cube als CUN 868 für TechemWZ | HM-MOD-RPI-PCB für HM | Z-Wave ZME_UZB1 | FRITZ!DECT 200 | HUE | Lightify | Echo Dot | WS3080

justme1968

hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Hollo

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 .
FHEM 6.x auf RPi 3B Buster
Protokolle: Homematic, Z-Wave, MQTT, Modbus
Temp/Feuchte: JeeLink-Clone und LGW mit LaCrosse/IT
sonstiges: Linux-Server, Dreambox, "RSS-Tablet"

Brice

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).
FHEM auf RPi 4 4GB (Buster) | produktiv) CUL 868 für FS20 | S300TH | KS300 | Max!Cube als CUN 868 für TechemWZ | HM-MOD-RPI-PCB für HM | Z-Wave ZME_UZB1 | FRITZ!DECT 200 | HUE | Lightify | Echo Dot | WS3080

rudolfkoenig

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.

Hollo

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!?
FHEM 6.x auf RPi 3B Buster
Protokolle: Homematic, Z-Wave, MQTT, Modbus
Temp/Feuchte: JeeLink-Clone und LGW mit LaCrosse/IT
sonstiges: Linux-Server, Dreambox, "RSS-Tablet"

rudolfkoenig

Das mag alles sein, aber mir als Modulentwickler war das nicht bewusst, und es hat deswegen keinen Bestandschutz :)

m0urs

#10
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?

Darkman

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

rudolfkoenig

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.

m0urs

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.

Hollo

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.
FHEM 6.x auf RPi 3B Buster
Protokolle: Homematic, Z-Wave, MQTT, Modbus
Temp/Feuchte: JeeLink-Clone und LGW mit LaCrosse/IT
sonstiges: Linux-Server, Dreambox, "RSS-Tablet"