Hallo Forum,
vor kurzem habe ich versucht, orientiert an dieser Anleitung (http://www.meintechblog.de/2014/12/fhem-watchdog-zur-automatisierung-einsetzen/) einen watchdog zu konfigurieren, der mir per Pushbullet eine Nachricht schickt wenn das Fenster 15 Minuten geöffnet ist.
Mein Problem ist, dass der Watchdog immer auslöst und mir eine Benachrichtigung schickt, also auch wenn das Fenster z.B. nur eine Minute geöffnet ist.
Vielleicht kann mit jemand einen Tipp geben was ich falsch definiert habe. Die Einträge in der fhem.cfg sehen folgendermaßen aus:
define OG_AZ_Fenster_WatchD watchdog OG_AZ_Fensterkontakt:open 00:15 OG_AZ_Fensterkontakt:close set PushBulletX message Fenster im Arbeitszimmer seit längerem offen!;; setstate OG_AZ_Fenster_WatchD defined
attr OG_AZ_Fenster_WatchD room hidden
Hi Jebediah,
ne Lösung habe ich leider nicht direkt parat... Vllt. hilfts aber trotzdem, habe aktuell nämlich das selbe Problem! Allerdings setze ich den watchdog auch in weiteren notifys wieder auf defined. Laut commandref müsstest du trigger watchdog nehmen, glaube ich. Bei mir geht das wegen den notifys nicht.
Nach mehreren Versuchen und Eingrenzungen glaube ich langsam, dass es mit setstate für aktiven watchdog nicht funktioniert:
Mir ist aufgefallen, dass es nachdem getriggert wurde zum Reaktivieren des Watchdog geht.
Wurde der Watchdog allerdings gestartet, hat aber noch nicht getriggered, wird er nicht zurückgesetzt, sondern er löst nach der Zeit trotzdem aus.
Leider geht es (natürlich) auch nicht mit trigger watchdog, wenn er zwar gestartet, aber noch nicht ausgelöst hat. Das löst halt direkt aus...
Es gibt einige Posts hier mit ähnlichen "Anfängerfragen". Komme aber irgenwie nicht weiter.
Bei mir siehts so aus:
define W_anwesend watchdog STR_anwesend_alle_bewegungsmelder:off 00:30:00 STR_anwesend_alle_bewegungsmelder:on set anwesend off
attr W_anwesend alias Watchdog Anwesendschaltung
attr W_anwesend room Startseite
attr W_anwesend group Info
define N_W_anwesend notify W_anwesend:N.* set MyTTS tts Countdown bis zur Abwesendheit gestartet. Abschaltung in 30 Minuten.
define N_anwesend notify (STR_anwesend_alle_bewegungsmelder|anwesend) {\
my $r1 = Value("STR_anwesend_alle_bewegungsmelder");; \
my $r2 = Value("anwesend");; \
if ($r1 eq "on" && $r2 eq "off") { \
fhem("set anwesend on");; \
fhem("setstate W_anwesend defined");; \
fhem("set eg_ez_s1_anaus value on");; \
fhem("set MyTTS tts Willkommen zurück. Modus ist jetzt anwesend.");; \
fhem("set STR_heizung_gesamt 18,5");; \
}}
define N_anwesend_immernochda notify STR_anwesend_alle_bewegungsmelder:on set anwesend on;; setstate W_anwesend defined;;
Sorry für die Unübersichtlichkeit, ist in der cfg der "Spielwiese".
Und nach 30min sagt er eben "Willkommen zurück" und anwesend geht kurz aus, aber direkt wieder an. Ich lass mir noch die zwischengespeicherte Zeit des letzten Zustandes des watchdog anzeigen. Deswegen glaube ich, dass ein aktivierter Watchdog nach einem setstate defined trotzdem auslöst.
Ein getriggerter watchdog wird nicht mit setstate zurückgesetzt, sondern mit trigger und dem Wert . (also ein Punkt):
Beispiel:
trigger W_anwesend .
Dazu noch der obligatorische verweis auf die commandref (http://fhem.de/commandref_DE.html#watchdog) ;)
Hi Benni,
und wenn ich einen aktivierten watchdog habe, also state Next: 18:57 oder so, wie kann ich den dann wieder stoppen/auf defined setzen, ohne ihn auszulösen. Oder kann ich das gar nicht, zB über einen Taster an der Wand den Watchdog stoppen?
Genau dafür ist ja eigentlich regexp2 da.
Es ist ja immer wieder schön von denen, die schon länger FHEM einsetzen die Querverweise auf die Doku und die Befehlsreferenz als Antwort anstelle einer Hilfestellung zu bekommen, doch meist wird von denjenigen übersehen, dass im Wiki und auch in der Befehlsreferenz viele Fehler sind die nicht bereinigt werden
# Alarmiere einmalig wenn vom FHT80 für 15 Minuten keine Nachricht # emfpangen wurde.
define w watchdog HMS100-FIT 01:00:00 SAME "alarm-fit.sh"
# Sende eine Mail wenn das Fenster offen gelassen wurde
define w watchdog contact1:open 00:15 contact1:closed "mail_me close window1"
attr w regexp1WontReactivate
Darüberhinaus sind manche Beschreibungen in der Befehlsreferenz und auch im Wiki von den Verfassern so geschrieben dass sie nur von Insidern verstanden werden können. Das ist wie wenn ein Programmierer das Handbuch für den Endanwender für die von ihm entwickelte Software selbst schreibt. Der Endanwender steht dann, wie sagt man so schön, wie "der Ochs vorm Tor".
Was du da anführst sind die Beispiele und nicht die Erklärungen, die stehen weiter oben in der Commandref.
Aber ist schon klar! Es ist gar keine Hilfestellung erwünscht, sondern lediglich eine fertige Lösung inkl. funktionierendem Code für das konkrete Problem.
Entschuldige, dass ich durch meine versuchte Hilfestellung (!) für Unmut gesorgt habe!
Hallo Klaus!
Zitat von: raspklaus am 30 Dezember 2015, 11:29:20
doch meist wird von denjenigen übersehen, dass im Wiki und auch in der Befehlsreferenz viele Fehler sind die nicht bereinigt werden
Könntest Du diese Stellen bitte genau mit Erläuterung angeben, damit das dann auch korrigiert werden kann.
Fehler zur commandref bitte im passenden Unterforum zum Modul laut http://fhem.de/MAINTAINER.txt melden. Die Entwickler sind darüber immer dankbar.
Fehler im Wiki kannst Du, wenn Du sicher bist, eigenständig beheben. Anmeldung hier http://www.fhemwiki.de/wiki/FHEMWiki:Administratoren. Ansonsten kannst Du mir das auch angeben, ich kümmere mich dann darum.
ZitatDarüberhinaus sind manche Beschreibungen in der Befehlsreferenz und auch im Wiki von den Verfassern so geschrieben dass sie nur von Insidern verstanden werden können. Das ist wie wenn ein Programmierer das Handbuch für den Endanwender für die von ihm entwickelte Software selbst schreibt. Der Endanwender steht dann, wie sagt man so schön, wie "der Ochs vorm Tor".
Darum sind eben bei diesem Projekt "FHEM" gerne End-Anwender gesehen, die sich bspw. in die Doku einbringen und ihre Erfahrungen aus Ihrer Sicht aufschreiben, um anderen nachfolgenden Einsteigern den Anfang zu erleichtern. Hier ist jeder herzlich eingeladen bei FHEM mitzumachen. Die Entwickler sollen in Ruhe entwickeln, wofür ich sehr dankbar bin, und ich als Anwender versuche dann meinen Beitrag zu FHEM zu leisten (Ich bin auch kein Entwickler, sondern nur User ohne EDV-Hintergrund.).
Gruß, Christian
Das Beispiel oben:
# Alarmiere einmalig wenn vom FHT80 für 15 Minuten keine Nachricht # emfpangen wurde.
define w watchdog HMS100-FIT 01:00:00 SAME "alarm-fit.sh"
15 min ??? 01:00:00 sind aus meiner sicht 4*15 Minuten also 1 Stunde
Wir möchten keine fertigen Lösungen aber Hilfestellungen wenn etwas unklar ist oder die Erklärung z.B. in der Commandreferenz nicht ausreicht. Wobei keiner der jenigen immer voraussetzen kann dass der Anfänger erst mal einen Perlkurs belegt oder diverse xxx-seitige Threats durchliest in denen sich oft mehrere Teilnehmer auch noch wiedersprechen. ich habe das hier schon oft erlebt einer mag Doifelse, der andere meint dann das wäre zu umständlich und der dritte bis xte haben wieder eine andere Meinung. Für denjenigen der versucht selbst eine Lösung zu finden und eventuell nicht weiterkommt keine wirkliche Hilfe.
Als typisches Beispiel die Erklärung für watchdog:
Hinweise:
Wenn <regexp1> . (Punkt) ist, dann aktiviere den Watchdog zur definierten Zeit. Sonst wird er durch den Empfang des ersten passenden Events aktiviert.
<regexp1> Resetet den Timer eines laufenden Watchdogs. Um das zu verhindern wird das regexp1WontReactivate Attribut gesetzt.
Wenn <regexp2> SAME ist , dann ist es das gleiche wie das erste regexp, und wird reaktiviert wenn es empfangen wird.
trigger <watchdogname> . aktiviert den Trigger wenn dessen Status defined ist und setzt ihn in den Status defined wenn sein status triggered ist.
Der Watchdog musst immer mit diesem Befehl reaktiviert werden wenn er getriggert wurde.
Ein generischer Watchdog (ein Watchdog, verantwortlich für mehrere Devices) ist derzeit nicht möglich.
Bei modify sind alle Parameter optional, und werden nicht geaendert, falls nicht spezifiziert.
Die Beschreibung ist für einen Anfänger zu kark und nicht wirklich durchsichtig
Zitat von: raspklaus am 30 Dezember 2015, 15:08:13
ich habe das hier schon oft erlebt einer mag Doifelse, der andere meint dann das wäre zu umständlich und der dritte bis xte haben wieder eine andere Meinung. Für denjenigen der versucht selbst eine Lösung zu finden und eventuell nicht weiterkommt keine wirkliche Hilfe.
Habe ich auch schon erlebt und da bin ich auch absolut deiner Meinung! Allerdings hat das in diesem Thread so gar nicht stattgefunden!
Sowas (http://forum.fhem.de/index.php/topic,45573.msg381650.html#msg381650) hilft übrigens auch keinem weiter.
Zitat von: raspklaus am 30 Dezember 2015, 15:08:13
Die Beschreibung ist für einen Anfänger zu kark und nicht wirklich durchsichtig
Mag ja durchaus sein. Wenn du es aber besser kannst, dann kannst du es sicher gerne dem entsprechenden Maintainer vorschlagen oder noch besser gleich selbst im Wiki einpflegen. Eine Doku wird nicht davon besser, dass man sie nur als unverständlich anmahnt.
Übrigens erhält man diese Seitenhiebe, eine Hilfestellung sei nicht hilfreich, erstaunlicherweise oftmals gar nicht von denen, die die Hilfestellung bekommen haben. ;)
Zitat von: raspklaus am 30 Dezember 2015, 15:08:13
Das Beispiel oben:
# Alarmiere einmalig wenn vom FHT80 für 15 Minuten keine Nachricht # emfpangen wurde.
define w watchdog HMS100-FIT 01:00:00 SAME "alarm-fit.sh"
15 min ??? 01:00:00 sind aus meiner sicht 4*15 Minuten also 1 Stunde
Der Erläuterungstext ist in der deutschen Übersetzung mMn falsch vom Übersetzer hinzugefügt worden. Wenn Du das im englischen Original anschaust, siehst Du das so nicht. Die deutsche Übersetzung wurde
für die User und auf Wunsch der User hinzugefügt. Dies auch gegen den Willen einiger Entwickler, die zusätzlichen Aufwand und weniger Entwicklungszeit befürchteten. Einige User haben daher damals dankenswerterweise übersetzt. Dabei hat sich wohl ein Fehler eingeschlichen.
-> Könntest Du bitte im passenden Forum den Entwickler darauf aufmerksam machen und um Kontrolle ggfs. Korrektur bitten.
Zitat
Wir möchten keine fertigen Lösungen aber Hilfestellungen wenn etwas unklar ist oder die Erklärung z.B. in der Commandreferenz nicht ausreicht. Wobei keiner der jenigen immer voraussetzen kann dass der Anfänger erst mal einen Perlkurs belegt oder diverse xxx-seitige Threats durchliest in denen sich oft mehrere Teilnehmer auch noch wiedersprechen. ich habe das hier schon oft erlebt einer mag Doifelse, der andere meint dann das wäre zu umständlich und der dritte bis xte haben wieder eine andere Meinung. Für denjenigen der versucht selbst eine Lösung zu finden und eventuell nicht weiterkommt keine wirkliche Hilfe.
Es gibt eben x Wege und jeder so wie er mag. Ich will hier auch niemanden den Mund verbieten, nur weil er meint einen besseren Vorschlag zu habem. FHEM bietet unendliche Möglichkeiten und hat deshalb ein gewisses Komplexitätsniveau. Ohne gewisse Perl-Grundkenntnisse ist FHEM nicht nutzbar. Dessen muss man sich bewusst sein und sich darauf einlassen.
ZitatAls typisches Beispiel die Erklärung für watchdog:
Siehe oben. Von Anwendern für Anwender übersetzt.
ZitatDie Beschreibung ist für einen Anfänger zu kark und nicht wirklich durchsichtig
Das mag ja sein. Aber nur beschweren reicht nicht. Man muss es eben ändern, wenn es einem nicht passt. Ja, dazu muss man sich erst einarbeiten.
-> FHEM lebt vom (Mit-)machen, besser machen und nicht vom beschweren; letzteres ändert nämlich nichts.
Gruß, Christian
Ok, ich gebe zu, dass Modul watchdog ist nicht das beste Beispiel, denn es wurde von Rudolf König entwickelt und der kann sich wirklich nicht um alles kümmern, denn er hat sicherlich genug andere Projekte gleichzeitig in Arbeit.
Aber einem anderen Erfahrenen müsste doch auffallen, dass das Ganze etwas kark erklärt ist. Auch ich habe meine Probleme mit dem Modul und kann es deshalb nicht besser machen. Es ist mir halt nur aufgefallen und ich wollte es hier mal ansprechen.
Aber zu guterletzt dem Threateröffner ist hier eigentlich immer noch nicht geholfen worden, denn er will sicherlich nicht in seiner Config den Balast aus dem zweiten Beitrag haben
Hi Jebediah,
da hast du ja was ausgelöst ;-) Mich hat die Hilfe (in den ersten Posts) ein bischen geschubst ;-) Ich habe bei mir mal den umgekehrten Ansatz gemacht und einfach alle notifys, die setstate defined hatten auskommentiert.
Ausserdem in der Definition des Watchdog, wie bei dir Jebediah, das setstate watchdog defined wieder auf trigger watchdog gesetzt.
Was soll ich sagen, heute den ganzen Tag auf der Baustelle und das Licht ging nicht aus ;-) Also, wie gewollt. Bin jetzt mal gespannt, ob denn die Heizung runterfährt, wenn ich ne halbe Stunde weg bin.
Danach denke ich fast, ändere deinen Code am Schluss auch auf die "trigger" variante:
define OG_AZ_Fenster_WatchD watchdog OG_AZ_Fensterkontakt:open 00:15 OG_AZ_Fensterkontakt:close set PushBulletX message Fenster im Arbeitszimmer seit längerem offen!;; trigger OG_AZ_Fenster_WatchD
Ich denke, dann gehts auch bei dir, oder hast du auch noch notifys verbaut mit setstate watchdog defined? Ich war da wohl übervorsichtig mit den notifys...
@raspklaus:
Habe jetzt selbst Rudi über Dein Problem mit der commandref zum watchdog informiert http://forum.fhem.de/index.php/topic,46466.0.html, damit es nicht vergessen wird bzw. untergeht. Du brauchst also nichts mehr zu machen und nur abwarten. Danke für Deine Unterstützung. Gruß, Christian
Hmm, da habe ich ja in der Tat was ausgelöst was so gar nicht beabsichtigt war... Danke auf jeden Fall für alle Hinweise!
Mit simonTS's Vorschlag habe ich es jetzt mal versucht, aber leider funktioniert das bei mir auch nicht, jetzt erhalte ich keine Nachricht...
Wenn ich die Pushbullet-Anweisung einzeln in die FHEM-Kommandozeile eingebe wird sie ausgeführt. Die Readings beim Watchdog zeigen für Activated einen Zeitpunkt an und 15 Min. später eiinen Zeitpunkt für Triggered (wenn das Fenster nicht geschlossen wurde). Das scheint soweit richtig zu sein. Aber die Nachricht wird nicht abgeschickt...
Da werde ich wohl noch ein wenig experimentieren müssen...
Hallo Simon,
fehlt da nicht etwas ?
define OG_AZ_Fenster_WatchD watchdog OG_AZ_Fensterkontakt:open 00:15 OG_AZ_Fensterkontakt:close set PushBulletX message Fenster im Arbeitszimmer seit längerem offen!;; trigger OG_AZ_Fenster_WatchD
sollte es nicht so sein ?
define OG_AZ_Fenster_WatchD watchdog OG_AZ_Fensterkontakt:open 00:15 OG_AZ_Fensterkontakt:close set PushBulletX message Fenster im Arbeitszimmer seit längerem offen!;; trigger OG_AZ_Fenster_WatchD .
Der Punkt am Schluss ?
Hallo Jebediah,
wie raspKlaus schon schreibt, fehlt im trigger der Punkt. Zudem vermute ich aus Deiner letzten Fehlerbeschreibung, dass der Event zum Start <regexp1> nicht nur einmalig kommt, sondern wiederkehrend. Dadurch wird ohne das Attribut regexp1WontReactivate der Timer zum Auslösen des watchdogs immer wieder resetet und der watchdog löst nicht aus. Da ich die Events nicht kenne ist das wie gesagt Vermutung. Bitte probiere und berichte:
define OG_AZ_Fenster_WatchD watchdog OG_AZ_Fensterkontakt:open 00:15 OG_AZ_Fensterkontakt:close set PushBulletX message Fenster im Arbeitszimmer seit längerem offen!;; trigger OG_AZ_Fenster_WatchD .
attr OG_AZ_Fenster_WatchD regexp1WontReactivate 1
Gruß, Christian
Leider muss ich ein wenig Abbitte leisten, denn ich befürchte der eigentliche Fehler war ein Tipp-Fehler: Der Status des geschlossenen Fensterkontakts muss "closed" heißen, nicht "close", deshalb hat der Watchdog dann wohl auch immer ausgelöst selbst wenn das Fenster geschlossen war...
Mit dem "d" und dem Code von krikan funktioniert die Benachrichtigung jetzt wie gewünscht. Herzlichen Dank für die Unterstützung hier im Forum!
Ich muss hier auch mal ran.
Mein watchdog löst auch nur einmal aus, die Syntax ist aber mE OK.
FensterBuero:offen 00:01:00 FensterBuero:geschlossen { fhem ("set PushBenachrichtigungTom msg 'fhem' 'Fenster im Büro ist offen !'")}; trigger FensterBueroUeberwachung .
oder aus def fhem.cfg
define FensterBueroUeberwachung watchdog FensterBuero:offen 00:01:00 FensterBuero:geschlossen { fhem ("set PushBenachrichtigungTom msg 'fhem' 'Fenster im Büro ist offen !'")};; trigger FensterBueroUeberwachung .
auch so nur einmal
define FensterBueroUeberwachung watchdog FensterBuero:offen 00:01:00 FensterBuero:geschlossen set PushBenachrichtigungTom msg 'fhem' 'Fenster im Büro ist offen !';; trigger FensterBueroUeberwachung .
In den ganzen Beispielen zur Fensterüberwachung wird ja immer beim Auslösen der Watchdog zurückgesetzt. Das bedeutet doch aber, dass ein offenes Fenster immer wieder gemeldet wird. Oder habe ich das falsch verstanden?
Wie müsste ich vorgehen, wenn ich nur eine Meldung haben möchte, und der Watchdog erst wieder aktiviert werden soll, wenn das Fenster geschlossen wurde? Ich würde dann den trigger im Watchdog herausnehmen und stattdessen einen Notify nehmen, der beim Schließen des Fensters ausgelöst wird. Was muss ich dann aber in den Ausführungsteil des Notify schreiben?