FHEM: Watchdog zur Automatisierung einsetzen

IM EINSATZ?

Dann schau dir UNSEREN LOXKURS an und profitiere von unserem Wissen!

Der Watchdog ist in FHEM im wahrsten Sinne des Wortes ein zuverlässiger Wachhund, welcher Zustandsänderungen innerhalb eines definierten Zeitraums überwacht und wenn nötig Alarm schlägt. Das ist praktisch, um bspw. eine automatische Flurbeleuchtung zu realisieren, bei der das Licht über den Bewegungsmelder eingeschaltet wird und nach 30 Sekunden ohne Bewegung wieder automatisch ausgeschaltet werden soll. Gerade wer noch nicht so gut mit dem Watchdog vertraut ist, kann vor allem am Anfang auf einige Probleme bei der Umsetzung stoßen. Aus diesem Grund werden in diesem Blogpost die Grundlagen des Watchdog erläutert und einige Beispiele zur Verdeutlichung gegeben, damit der Einstieg leichter fällt.

Watchdog-Zustände

Der Watchdog kennt drei verschiedene Zustände:

defined
Der Watchdog wartet auf das Eintreffen eines bestimmten Ereignisses (1), um mit seiner Überwachung zu beginnen.

Next: 21:17:07
Sobald das hinterlegte Ereignis (1) eingetroffen ist, beginnt der Watchdog mit seiner Überwachung. Die angegebene Uhrzeit gibt Auskunft darüber, wie lange diese Überwachung noch andauert.

triggered
Hat bis zum Ende der Überwachungszeit ein bestimmtes Ereignis (2) nicht stattgefunden, löst der Watchdog aus. Möchte man anschließend, dass der Watchdog wieder auf eintreffende Ereignisse (1) reagiert, muss man ihn wieder auf “defined” setzen. Details dazu im nachfolgenden Beispiel.

Watchdog am Beispiel der Anwesenheitserkennung

Mit FHEM ist es möglich, die Anwesenheit eines Smartphones durch einen Bluetooth-Dongle festzustellen. Welche Voraussetzungen dafür notwendig sind, wird im Artikel Howto: Mit FHEM Push-Nachrichten aufs iPhone schicken (Update) beschrieben.

In diesem Beispiel sucht der FHEM-Server alle 10 Sekunden per Bluetooth nach der hinterlegten Bluetooth-Mac-Adresse des gerade abwesenden Smartphones (“absent”). Weiterhin sucht der FHEM-Server fortlaufend alle 60 Sekunden nach dem Smartphone, sobald es anwesend, also “present” ist.

#Bluetooth-Anwesenheit
define HA.JayBluetooth PRESENCE local-bluetooth 28:E1:4C:91:AA:D5 10 60

Dabei kann es schon einmal vorkommen, dass sich die Bluetooth-Erkennung einmal verschluckt und das eigentlich anwesende Smartphone nicht korrekt erkennt und auf abwesend schaltet. Hat man dann bspw. hinterlegt, dass bei Abwesenheit die Beleuchtung deaktiviert werden soll, steht man unter Umständen schnell im Dunkeln. Hier kommt nun der Watchdog zum Einsatz, um solche kurzen Aussetzer auszubügeln. Damit das klappt, wird weiterhin noch der Dummy “HA.Jay” benötigt, welcher den verbesserten Anwesenheitsstatus ausgibt und vom Watchdog angesprochen wird. Dieser wird gleich noch mit dem Attribut “event-on-change-reading state” ausgestattet, so dass er selbst immer nur Befehle auslöst, wenn sich sein Status verändert und nicht jedes Mal, wenn sich sein Status nur aktualisiert und unverändert bleibt.

#Dummy definieren
define HA.Jay dummy
attr HA.Jay event-on-change-reading state

Der Dummy “HA.Jay” wird dann auf “on” geschaltet, sobald das Smartphone erkannt wird:

#HA.Jay auf on setzen
define SetHAJayOn notify HA.JayBluetooth:present set HA.Jay on

Und nun zum Watchdog:

#Watchdog definieren
define watchdogHAJayBluetooth watchdog HA.JayBluetooth:absent 00:03:10 HA.JayBluetooth:present set HA.Jay off;; setstate watchdogHAJayBluetooth defined
attr watchdogHAJayBluetooth regexp1WontReactivate 1

Erkennt der Watchdog, dass das Smartphone abwesend ist (“HA.JayBluetooth:absent”) (Ereignis 1), beginnt die Überwachung innerhalb des Zeitraums von drei Minuten und 15 Sekunden (00:03:15). Sobald die Zeit abgelaufen ist, ohne dass das Smartphone wieder erkannt wurde (“HA.JayBluetooth:present”) (Ereignis 2), wird der nachfolgende Befehl ausgelöst. Der Befehl setzt dabei den Dummy “HA.Jay” auf “off” und den Zustand des Watchdogs wieder auf “defined”, damit dieser wieder auf das Eintreffen neuer Ereignisse vom Typ “HA.JayBluetooth:absent” reagieren kann. Würde man den Befehl “setstate watchdogHAJayBluetoothAbwesend defined” hingegen weglassen, würde der Watchdog auf “triggered” verbleiben und gar nicht mehr reagieren.

Durch den Watchdog können also bis zu drei nacheinander folgende (fehlerhafte) Abwesenheitsnachrichten (“HA.JayBluetooth:absent”) weggepuffert werden, was sich in der Praxis als recht valider Wert erweist. Dadurch wird die Erkennung insgesamt verbessert aber natürlich auch etwas träger. Denn sollte man wirklich das Haus verlassen, wird die Beleuchtung erst nach spätestens 3 Minuten und 15 Sekunden gelöscht. Hier muss jeder selbst abwägen, welcher Wert in welchem Kontext sinnvoll ist.

Watchdog am Beispiel der automatischen Flurbeleuchtung

Vom Aufbau her etwas anders verhält es sich bei der Realisierung einer automatischen Flurbeleuchtung, bei der ein Bewegungsmelder (“FL.Bewegungsmelder”) das Flurlicht (“FL.Deckenlampe”) beim Erkennen einer Bewegung einschaltet und der Watchdog nach 30 Sekunden ohne Bewegung automatisch wieder ausschaltet.

Als erstes sorgt ein notify dafür, dass bei Bewegung (motion) des Bewegungsmelders (FL.Bewegungsmelder) die Deckenlampe (FL.Deckenlampe) eingeschaltet wird.

#Bei Bewegung die Deckenlampe einschalten
define FLBewegungsmelderSchaltetFLDeckenlampeEin notify FL.Bewegungsmelder:motion set FL.Deckenlampe on

Damit das Licht automatisch wieder ausgeschaltet wird, sobald für 30 Sekunden keine Bewegung mehr registriert wird, kommt der Watchdog (watchdogFLBewegungsMelder) ins Spiel:

#Watchdog definieren
define watchdogFLBewegungsMelder watchdog FL.Bewegungsmelder:motion 00:00:30 SAME set FL.Deckenlampe off;; setstate watchdogFLBewegungsMelder defined

Wird dem Watchdog mitgeteilt, dass eine Bewegung erkannt wurde (“FL.Bewegungsmelder:motion“) (Ereignis 1), beginnt die Überwachung innerhalb des Zeitraums von 30 Sekunden (00:00:30). Sobald die Zeit abgelaufen ist, ohne dass eine erneute Bewegung erkannt wurde (“SAME”) (Ereignis 2), wird der nachfolgende Befehl ausgelöst. Der Befehl setzt dabei die “FL.Deckenlampe” auf  “off” und den Zustand des Watchdogs wieder auf “defined”, damit dieser wieder auf das Eintreffen neuer Ereignisse vom Typ “FL.Bewegungsmelder:motion” reagieren kann. Die Besonderheit ist dabei die zweite Bedingung “SAME”, was bedeutet, dass “FL.Bewegungsmelder:motion” gleichzeitig der Trigger ist, um den Watchdog zu aktivieren, gleichzeitig aber auch für dessen Abbruch zuständig ist. Alternativ kann man anstatt “SAME” auch natürlich auch den Befehl selbst (“FL.Bewegungsmelder:motion”) verwenden.

Besonderheit: Watchdog-Überwachung ohne Verlängerung des Überwachungszeitraums

Bei obigem Beispiel beginnt der Überwachungszeitraum bei einem bereits gestarteten Watchdog (Status: “Next 21:17:07”) immer erneut, sobald eine weitere Bewegung registriert wird (“FL.Bewegungsmelder:motion“). Um das zu verhindern, existiert das Attribut “regexp1WontReactivate”. Wird dieses gesetzt, wird der Watchdog also nur bei der ersten Bewegung gestartet und der Überwachungszeitraum startet bei aktivem Watchdog auch bei nachfolgenden Bewegungen nicht mehr erneut. Das sieht dann so aus:

#Watchdog definieren
define watchdogFLBewegungsMelder watchdog FL.Bewegungsmelder:motion 00:00:30 SAME set FL.Deckenlampe off;; setstate watchdogFLBewegungsMelder defined
attr watchdogFLBewegungsMelder regexp1WontReactivate

Der Einsatz von “regexp1WontReactivate” kann bspw. in obigem Beispiel dann im Rahmen von Stromsparmaßnahmen Sinn machen, wenn man nach einer erstmaligen Bewegung, welche den Watchdog startet, das Licht zwingend nach der vorgegebenen Zeit (bzw. einem fixen Endzeitpunkt) ausschalten möchte, obwohl in der Zwischenzeit immer noch Bewegung registriert wird.

Aus meinem täglichen Leben

Richtig eingesetzt, kann der Watchdog viele Abläufe automatisieren und den Komfort enorm steigern. Gerade am Anfang kann man aber viel Zeit damit verbringen, um überhaupt herauszufinden, wie der Watchdog richtig funktioniert. Auch in letzter Zeit erreichten mich einige Mails von Lesern, die das Thema interessant finden, aber bei der Umsetzung noch Schwierigkeiten hatten. Ich hoffe deshalb, dass die Nutzung mit obigen Beispielen etwas verdeutlicht werden konnte und gerade auch die Nutzer den Einstieg schaffen, die von der FHEM Referenz evtl. etwas überfordert sind.

29 Kommentare
  1. Hallo Jörg,
    wie immer ein toller Beitrag.
    Eine Frage habe ich aber noch: wie bringe ich dem Watchdog bei auch noch Zeitlich Flexibel zu reagieren ? beispiel: Licht im Flur nur zwischen 17:00 und 7:00 Uhr ?
    oder im Zusammenspiel mit Sunrise und Sunset ?
    Gruß
    GrayDeath

  2. Hallo Jörg
    Im Fhem webinterface kann man regexp1WontReactivate zustand 0 oder 1 auswählen. Wo ist der Unterschied?
    Ich habe bei meiner Anwesenheitserkennung mit watchdog “regexp1WontReactivate 0” eingetragen, nur ändert sich so der Zustand des dummys nicht mehr seit dem neuesten Update vom fhem.
    Gruß Inesa

    1. Hi Inesa,
      das mit dem regexp1WontReactivate hatte ich im Blogpost bereits erläutert. Hier der Ausschnitt:
      “Bei obigem Beispiel beginnt der Überwachungszeitraum bei einem bereits gestarteten Watchdog (Status: “Next 21:17:07”) immer erneut, sobald eine weitere Bewegung registriert wird (“FL.Bewegungsmelder:motion”). Um das zu verhindern, existiert das Attribut “regexp1WontReactivate”. Wird dieses gesetzt, wird der Watchdog also nur bei der ersten Bewegung gestartet und der Überwachungszeitraum startet bei aktivem Watchdog auch bei nachfolgenden Bewegungen nicht mehr erneut.”
      regexp1WontReactivate 0 bedeutet also, dass das Attribut deaktiviert ist.
      regexp1WontReactivate 1 hingegen, dass es aktiviert ist.
      Hoffe das hilft weiter!

      Grüße
      Jörg

  3. Hi,
    ich habe den Verdacht, ich bin zu dusselig, das korrekt hin zu bekommen.
    Ich habe folgendes Coding:

    #Bluetooth-Anwesenheit
    define aPhoneBT PRESENCE local-bluetooth xx:xx:xx:xx:xx:xx 10 60

    #Arnes iPhone definieren
    define aPhone dummy
    attr aPhone alias Arne sein iPhone
    attr aPhone event-on-change-reading state
    attr aPhone eventMap 1
    attr aPhone room Mobile Geräte
    define FileLog_aPhone FileLog ./log/aPhone-%Y-%m.log aPhone
    attr FileLog_aPhone logtype text

    #aPhone auf on setzen bei Anwesenheit
    define aPhoneOn notify aPhoneBT:present set aPhone on

    #aPhone auf off setzen nach 3 Min Abwesenheit
    define WD.aPhoneBT watchdog aPhoneBT:absent 00:03 aPhoneBT:present set aPhone off;; setstate WD.aPhoneBT defined

    Das setzen von On bei :present funktioniert einwandfrei. Aber der Watchdog scheint nichts von :absent mitzubekommen und bleibt permanent auf On.

    Was mache ich denn falsch?

    LG,
    A

  4. hallo jörg,
    super blog!
    imho fehlt bei deinem ersten beispiel ein

    attr watchdogHAJayBluetooth regexp1WontReactivate 1

    ohne den funzt es nicht.
    sollte auch die lösung für das o.g.problem sein.

    wo wir gerade dabei sind:

    ich habe zwei watchdogs angelegt- einer fürs iphone und einer fürs ipad.
    wenn ich die beide dabei habe bin ich ganz ganz sicher weg.
    habe also erkennung & watchdog auf der fritzbox laufen.
    und dadurch 2 dummys die, WENN beide off sind dieses an den PI weitergeben sollen um dort verschieden lightscenes (da oder weg) zu aktivieren.

    define Tim_Iphone_Anwesenheit dummy

    attr Tim_Iphone_Anwesenheit event-on-change-reading state
    attr Tim_Iphone_Anwesenheit room Anwesenheit

    define SetTim_Iphone_AnwesenheitOn notify Iphone:present set Tim_Iphone_Anwesenheit on
    attr SetTim_Iphone_AnwesenheitOn room Anwesenheit

    # watchdog
    define watchdogIphone watchdog Iphone:absent 00:03:10 Iphone:present set Tim_Iphone_Anwesenheit off;; setstate watchdogIphone defined
    attr watchdogIphone regexp1WontReactivate 1
    attr watchdogIphone room Anwesenheit

    define Tim_Ipad_Anwesenheit dummy
    attr Tim_Ipad_Anwesenheit event-on-change-reading state
    attr Tim_Ipad_Anwesenheit room Anwesenheit

    define SetTim_Ipad_AnwesenheitOn notify Ipad:present set Tim_Ipad_Anwesenheit on
    attr SetTim_Ipad_AnwesenheitOn room Anwesenheit

    # watchdog
    define watchdogIpad watchdog Ipad:absent 00:03:10 Ipad:present set Tim_Ipad_Anwesenheit off;; setstate watchdogIpad defined
    attr watchdogIpad regexp1WontReactivate 1
    attr watchdogIpad room Anwesenheit

    define Tim_Anwesenheit dummy
    define Tim_Anwesenheit_PI dummy

    define tim_weg notify (Tim_Iphone_Anwesenheit|Tim_Ipad_Anwesenheit) {
    my $r1 = $value{“Tim_Iphone_Anwesenheit”};;
    my $i2 = $value{“Tim_Ipad_Anwesenheit”};;
    if ($r1 eq “off” && $r2 eq “off”) { fhem “set Tim_Anwesenheit_PI off” } else { fhem “set Tim_Anwesenheit_PI on” } }

    Fehlermeldung beim speichern ist:

    Unknown command my, try help. Unknown command my, try help. IF: no left bracket: { fhem “set Tim_Anwesenheit_PI off” } else { fhem “set Tim_Anwesenheit_PI on” } }

    siehst du den fehler?

    VG,
    Tim

    1. Hi Tim,
      wenn du mit neuen Zeilen in deinen Befehlen arbeitest, musst du am Zeilenende vor den gewünschten Umbrüchen jeweils ein \ einfügen.

      Also muss es bspw. so aussehen:

      define tim_weg notify (Tim_Iphone_Anwesenheit|Tim_Ipad_Anwesenheit) {\
      my $r1 = $value{“Tim_Iphone_Anwesenheit”};;\
      my $i2 = $value{“Tim_Ipad_Anwesenheit”};;\
      if ($r1 eq “off” && $r2 eq “off”) { fhem “set Tim_Anwesenheit_PI off” } else { fhem “set Tim_Anwesenheit_PI on” } }

      Hoffe das hilft dir weiter!
      Grüße
      Jörg

    2. Hi Jörg,
      das war es! Herzlichen Dank!
      Kleiner Schreibfehler war (von mir) noch drin-
      my $i2 = $valu….

      muß natürlich
      my $r2 = $valu….
      heißen…

      VG,
      Tim

  5. Danke für den Beitrag, hat genau auf meine Anforderung zur Abwesenheitserkennung per Handy gepasst (wobei ich per WLAN anpinge und nicht per Bluetooth). Das “attr watchdogHAJayBluetooth regexp1WontReactivate 1” gehört aber mit rein – bin eine Stunde lang fast verzweifelt, bevor ich endlich auch mal die Kommentare gelesen habe 😉

    1. Hi Carzl,
      vielen Dank für den Hinweis. Ich habe es im Blogpost entsprechend angepasst. So sollte es jetzt stimmen, aber trotzdem bitte nochmal kontrollieren…

      Grüße
      Jörg

  6. Die erste Frage von GrayDeath bzgl. zeitlicher Flexibilität würde ich gerne nochmal anwärmen, ich überlege gerade wie ich meine Anwesenheitserkennung (so gebaut wie hier beschrieben, nur mit WLAN-Abfrage der Handys) zwischen 00:00 und 06:00 aussetzen kann, denn das ist meine WLAN-down-Zeit. Im Moment sagt mein Fhem natürlich nachts dass keiner zu Hause ist da die Handys nicht per WLAN erreichbar sind. Wie könnte man das am geschicktesten für die Nachtstunden deaktivieren? Vielleicht könnte man ja einen dummy definieren, der den Handystatus um 23:55 aufzeichnet und dann als festen Status bis 06:00 vorgibt? Hmmm…?! Vielleicht hat ja einer der mitlesenden eine schicke Idee?

    1. Hi Carzl,
      spontan würde ich das über einen zusätzlichen Dummy HAJayBluetooth_real lösen, welcher dann für entsprechende Regeln genutzt werden kann. HAJayBluetooth_real wird dann immer nur zwischen 6 und kurz vor 24 Uhr mit dem aktuellen Wert von HAJayBluetooth gefüttert und erhält einmal direkt um 6 Uhr den aktuellen Wert mitgeteilt. Oben beschriebenes Szenario würde man dann so erweitern:

      define HAJayBluetooth_real dummy

      define HAJayBluetoothrealSet notify HAJayBluetooth {if ($hour>=6 && $hour<24) {fhem ("set HAJayBluetooth_real %")}}

      define HAJayBluetoothrealSetUm6Uhr at *06:00 {my $status=ReadingsVal("HAJayBluetooth","state","");; {fhem ("set HAJayBluetooth_real $status")}}

      Viel Erfolg
      Jörg

  7. Ja, genau so ist es, was die Flurbeleuchtung angeht!Die LED Spots zum Beispiel sind bestens dafür geeignet, denn im Flur braucht man eigentlich nicht so viel Licht und trotzdem kann das Licht als Akzent genutzt werden. Ich habe mich persönlich für diese Variante entschieden.

  8. Hallo Jörg,

    ich würde gern den Watchdog nutzen, um einen “virtuellen Schalter” zu überwachen.
    Ich habe mir einen Dummy “Beregnung_aus” angelegt, den ich für die Bewässerung abfrage. Standardmäßig steht dieser auf “on”.

    Sobald dieser händisch auf “off” gesetzt wird, würde ich jetzt gern nach einer gewissen Zeit (bspw. 24h), eine pushover Nachricht o.ä. bekommen, und nach einer weiteren Zeit (bspw. nach 48h) eine weitere Nachricht erhalten und den Dummy wieder auf “on” setzen.

    Die Bewässerung, Pushover/Whatsapp o.ä. funktioniert, beim Watchdog tue ich mich etwas schwer. Wie lässt sich denn so etwas lösen?

    Viele Grüße
    Chris

  9. Hallo, ich hab ein Problem mit der BT-Schaltung:
    Einschalten klappt beim Aktivieren des BT am Handy sofort. Nur aus klappt nicht mehr. Kann da mal jemand bitte drüber schauen?

    #– HA.Jay definieren
    define HA.Jay dummy
    attr HA.Jay eventMap 1
    attr HA.Jay room Haus
    define FileLog_HA.Jay FileLog ./log/HA.Jay-%Y-%m.log HA.Jay
    attr FileLog_HA.Jay logtype text

    #– HA.Jay auf on setzen bei Anwesenheit
    define HAJayOn notify HA.JayBluetooth:present {system(“sudo send 00010 1 1 &”)}

    #– HA.Jay auf off setzen nach 3 Min Abwesenheit
    define watchdogHAJayBluetoothAbwesend watchdog HA.JayBluetooth:absent 00:00:10 HA.JayBluetooth:present {system(“sudo send 00010 1 1 &”)}
    attr watchdogHAJayBluetoothAbwesend regexp1WontReactivate 1
    attr watchdogHAJayBluetoothAbwesend room Haus

    1. Hi Tobias,
      versuch es mal mit:

      #– HA.Jay definieren
      define HA.Jay dummy
      attr HA.Jay eventMap 1
      attr HA.Jay room Haus
      define FileLog_HA.Jay FileLog ./log/HA.Jay-%Y-%m.log HA.Jay
      attr FileLog_HA.Jay logtype text

      #– HA.Jay auf on setzen bei Anwesenheit
      define HAJayOn notify HA.JayBluetooth:present {system(“sudo send 00010 1 1 &”);; fhem(“setstate watchdogHAJayBluetoothAbwesend defined”)}

      #– HA.Jay auf off setzen nach 3 Min Abwesenheit
      define watchdogHAJayBluetoothAbwesend watchdog HA.JayBluetooth:absent 00:00:10 HA.JayBluetooth:present {system(“sudo send 00010 1 1 &”)}
      attr watchdogHAJayBluetoothAbwesend regexp1WontReactivate 1
      attr watchdogHAJayBluetoothAbwesend room Haus

      Grüße
      Jörg

  10. Hi Jörg,

    super! Erstmal danke fuer deine Seite, hat mich bewogen vor ein paar Wochen FHEM aufzusetzen und die ersten Komponenten zu kaufen. 🙂

    Ich habe aufgrund deiner Artikel watchdog und prowl mal meinen Fenstersensor hinterlegt damit er nach x Minuten eine Meldung sendet. Irgendwie klappt etwas nicht…

    Ueber das Eingabefeld in FHEM kann ich eine Benachrichtung versenden:
    {prowl(“Das Badezimmerfenster ist auf”,”Bad”,”1″)}

    Der Trigger scheint auch zu funktionieren, nur versendet er die Benachrichtigung nicht.
    Habt ihr eine Idee?

    CMD
    {\{prowl(“Das Badezimmerfenster ist auf”,”Bad”,”1″)};\\ fhem(‘setstate watchdog_hm_Badezimmer defined’);\\ } attr watchdog_hm_Badezimmer regexp1WontReactivate 1

    DEF
    HM_3EB449:open 00:12 HM_3EB449:closed {\{prowl(“Das Badezimmerfenster ist auf”,”Bad”,”1″)};\\ fhem(‘setstate watchdog_hm_Badezimmer defined’);\\ } attr watchdog_hm_Badezimmer regexp1WontReactivate 1

    NAME watchdog_hm_Badezimmer
    NR 108
    NTFY_ORDER
    50-watchdog_hm_Badezimmer
    RE1
    HM_3EB449:open
    RE2
    HM_3EB449:closed
    STATE
    Next: 20:51:42
    TO
    720
    TYPE
    watchdog
    Readings
    Activated
    activated
    2015-10-25 20:39:42
    Triggered
    triggered
    2015-10-25 20:31:15

    Ueber einen Tipp bin ich dankbar 😉

    VG
    Mark

  11. Hallo Jörg,
    Ich habe folgendes Problem, Vielleicht kannst du mir weiterhelfen.
    Ich habe einen Fensterkontakt und einen Schaltaktor wo eine Lampe angeschlossen ist.
    Nun soll die Lampe eingeschaltet werden wenn der Fensterkontakt “open” meldet. Soweit kein Problem. Hab ich mit einem einfachen notify geregelt. Die Lampe soll aber nur zwischen 22:00 Uhr und 6:00 Uhr geschaltet werden.
    Wie kann ich das realisieren?

    Grüße David

    1. Hi David,
      sowas lässt sich wohl recht gut mit einer DOIF-Anweisung lösen. Les am besten mal in der FHEM-Referenz nach, da gibt es gute Beispiele. Ich werde hoffentlich auch bald mal Zeit haben, mich damit intensiver zu beschäftigen. Dazu werden dann sicherlich auch Inhalte auf dem Blog folgen.

      Grüße und viel Erfolg
      Jörg

  12. Moin Moin
    Haben diesen Watchdog im Einsatz

    define watchdog_Flur_Schalter_Bewegungsmelder_Motion watchdog Flur_Schalter_Bewegungsmelder_Motion:motion 00:00:20 SAME set Schalter_Flur_Haustuer off;; setstate watchdog_Flur_Schalter_Bewegungsmelder_Motion defined

    Möchte jetzt das der Befehl nicht zwischen 05:00-06:00 schaltet.
    Wie setze ich das jetzt am besten um?

    1. Hi Dennis,
      spontan würde ich es so machen (konnte es aber leider nicht testen):

      define watchdog_Disable at *5:00:00 attr watchdog_Flur_Schalter_Bewegungsmelder_Motion disable 1
      define watchdog_Enable at *6:00:00 attr watchdog_Flur_Schalter_Bewegungsmelder_Motion disable 0;; setstate watchdog_Flur_Schalter_Bewegungsmelder_Motion defined

      Grüße und viel Erfolg
      Jörg

    2. Eine Frage hätte ich da noch

      Wie bekomme ich es jetzt noch hin das der Watchdog nur bei einer bestimmten Helligkeit auslöst ?

      Mein Befehl Funktioniert nicht

      define watchdog_Flur_Schalter_Bewegungsmelder_Motion watchdog Flur_Schalter_Bewegungsmelder_Motion:motion if ( ReadingsVal(“Flur_Schalter_Bewegungsmelder_Motion”,”brightness”,0) < 60);;00:00:20 SAME set Schalter_Flur_Haustuer off;; setstate watchdog_Flur_Schalter_Bewegungsmelder_Motion defined

  13. Hallo Jörg, erstmal vielen Dank für die gute Anleitung.

    Ich habe gerade ein kniffliges Problem: Ich habe einen Rechner mit einem Wechselrahmen. In diesen Wechselrahmen stecke ich entweder die Festplatte rein, auf der mein Arbeitssystem drauf ist, oder die Festplatte, auf der mein Spielesystem drauf ist. Demzufolge haben sowohl das Arbeitssystem, als auch das Spielesystem die selbe IP-Adresse.

    Nun möchte ich, dass wenn der Rechner an ist und es zwischen Sonnenuntergang und Sonnenaufgang ist, das Licht an der Decke angeht. Das ganze habe ich folgendermaßen “gelöst”:

    define Arbeitssystem PRESENCE lan-ping 192.168.x.xxx 20
    attr Arbeitssystem event-on-change-reading state

    ### Wenn Arbeitssystem an und Zeit zwischen Sonnenuntergang und Sonnenaufgang, dann Licht Decke an ###
    define Arbeitssystem_an_Licht_Decke_an watchdog Arbeitssystem:present 00:00:05 Arbeitssystem:absent set Licht_Decke on;;setstate Arbeitssystem_an_Licht_Decke_an defined
    attr Arbeitssystem_an_Licht_Decke_an disable 0
    attr Arbeitssystem_an_Licht_Decke_an regexp1WontReactivate 1
    define watchdog_Arbeitssystem_Disable at *{sunrise(0)} attr Arbeitssystem_an_Licht_Decke_an disable 1
    define watchdog_Arbeitssystem_Enable at *{sunset(-1200)} attr Arbeitssystem_an_Licht_Decke_an disable 0;; setstate Arbeitssystem_an_Licht_Decke_an defined

    Wenn das Arbeitssystem an ist und es zwischen Sonnenuntergang und Sonnenaufgang ist, geht das Licht auch an (so, wie es soll). Wenn das Spielesystem an ist, geht das Licht unter diesen Bedingungen nicht an, soll es aber. Nun habe ich das ganze in FHEM zwar “Arbeitssystem” und nicht “Spielesystem” genannt. Aber ich glaube nicht, dass das FHEM interessiert. Ich denke, dass FHEM auf die IP-Adresse achtet. Oder sehe ich das falsch?

    Vielen Dank schon mal für jede Hilfe 🙂

    1. Hi Max,
      ich vermute, dass deine beiden Systeme doch unterschiedliche IP-Adressen (IPv4) haben, sonst müsste es eigentlich so funktionieren, wie von dir beschrieben. Am besten einmal in den Netzwerkeinstellungen prüfen. Zur Not kannst du beiden Systemen, da diese ja nie gleichzeitig aktiv sein können, manuell die selbe IP im passenden Adressbereich zuweisen.

      Grüße und viel Erfolg
      Jörg

    2. Hi Jörg, danke für deine Antwort. Nein meine beiden Systeme haben die selbe IP-Adresse. Ich habe aber herausgefunden woran es liegt: Da ich zwei unterschiedliche Systeme habe, reagieren auch die Firewalls unterschiedlich. Beim Arbeitssystem hat es ja funktioniert. Beim Spielesystem wollte der Raspberry auch eingreifen, wurde jedoch durch die Firewall des Spielesystems daran gehindert, sodass ich die Firewalleinstellungen noch anpassen musste. Nun funktioniert es mit der selben IP-Adresse, sowohl vom Arbeitssystem, als auch vom Spielesystem.

  14. Hallo Jörg
    Wie kann ich die:
    #HA.Jay auf on setzen
    define SetHAJayOn notify HA.JayBluetooth:present set HA.Jay on#
    In der Nacht von 00:00 bis 08:00 auszetzen

    attr SetHAJayON disabledForIntervals 06:00-24:00
    Damit hat es nicht funktioniert.
    Hast du eine Idee?
    Danke

  15. Servus zusammen,

    ich habe hier einen Gedankenknoten, gepaart mit Unfähigkeit!
    Folgende Situation:
    2 Handys per BT Überwachung im System.
    Min. 2 Rollos sollen automatisch bei Abwesenheit runter gefahren werden.
    Meine Idee war, bei Handys per Structure zu binden. Aber dann würde es ja reichen, wenn ein Handy absent ist. Geht so also nicht.
    Zweite Idee: Notifiy mit & Verknüpfung und Befehl an eine Gruppe von Rollos.

    Ich kriegs nicht hin… Achja, und nochwas. Um die Cul´s nicht über zubelasten wäre es sicher sinnvoll, die Schaltbefehle im 10 Sekunden Takt auszulösen.

    Hat jemand eine Idee für mich?
    Wäre euch echt dankbar.
    mfg
    Mike

  16. Hallo Jörg,

    danke für deinen Blog – echt Klasse 🙂
    Hat mir sehr weitergeholfen.

    Bin aber über eine Anmerkung aus dem FHEM-Wiki (https://wiki.fhem.de/wiki/Watchdog) gestolpert:

    “Die Reaktivierung des watchdog hat mit trigger . oder durch Setzen des Attributs autoRestart zu erfolgen. Die in Blogs und Forumsbeiträgen häufiger zu findende Variante mit setstate entspricht nicht und entsprach nie der commandref. Sie funktioniert nur “aus Versehen”. Es existiert dafür kein Bestandsschutz und unerwünschte Seiteneffekte sind nicht auszuschließen!”

    Gruß Patrick

    1. Hi Patrick,
      danke für den Hinweis. Bin aus dem Thema leider mittlerweile völlig raus. Außerdem gibt es ja in der Zwischenzeit auch doif, wodurch der watchdog sowieso obsolet geworden ist.

      Grüße
      Jörg

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Das könnte dir auch gefallen