Hallo zusammen,
seit mehreren Monaten empfängt mein Jeelink die Temp/Feuchtedaten von DREI verschiedenen LaCrosse ohne Pronbleme.
Seit einigen Tagen empfange ich jedoch kein Signal mehr von dem Sensor, der nur knapp 2 Meter (im selben Raum) hängt.
Ich habe mich jetzt auch schon einige Monate nicht mehr mit FHEM beschäftigt, weils es halt einfach lief.
Wie kann ich mich auf Fehlersuche begeben?
Oder hatte evtl. schonmal jmd dieses Problem?
Danke und Gruß
duffy6
Da stellen sich eine Menge Fragen:
FHEM-Update gemacht?
Firmware auf dem JeeLink geändert?
Sendet der Sender noch?
Gibt es eine Wetterstation, die den Sender empfängt?
Batterien aus dem Sender rausgehabt?
Batterien evtl. fast leer?
JeeLink mal auf einen Rechner mit einem Terminalprogramm stecken und schauen, was da so ankommt.
Das sind Pakete die so aussehen.:OK 9 41 1 4 164 50
Bei drei Sensoren müssen Pakete mit drei unterschiedlichen Adressen an der fett markierten Stelle kommen.
Damit wäre dann getestet, ob der JeeLink den Sensor nicht mehr empfängt oder es erst in FHEM auf der Strecke bleibt.
Falls der JeeLink schon nichts mehr liefert, dann Batterie aus dem Sensor raus und wieder rein, evtl. sendet er ja nach einem Reset wieder (hatte ich aber noch nie)
Danach ist aber ein neues Pairing erforderlich, weil sich die Adresse ändert.
FHEM-Update gemacht? JA, irgendwann mal in den letzten Wochen - aber Update habe ich schon oft gemacht und immer lief es noch danach..
Firmware auf dem JeeLink geändert? NEIN
Sendet der Sender noch? HMM, Gute Frage...
Gibt es eine Wetterstation, die den Sender empfängt?
NEIN, nichts bekannt!
Batterien aus dem Sender rausgehabt?
Batterien evtl. fast leer?
Batterien sind langsam dem Ende zugegangen, dann hab ich neue Batterien in den Sensor.
Muss ich nach einem batterienwechsel irgendwas beachten?
ich hab mal meinen Log (ab 22.11.2014) angehängt.
Das letzte Mal hab ich Daten am 23.11.2014 von dem besagten Sensor empfangen (04Thermo; keller)
Bringt das jmd weiter?
Zitat von: duffy6 am 27 November 2014, 14:10:52
Batterien sind langsam dem Ende zugegangen, dann hab ich neue Batterien in den Sensor.
Muss ich nach einem batterienwechsel irgendwas beachten?
Ja.
Schau mal in der commandref nach replaceBatteryForSec.
Beim Wechsel der Batterien ändert sich die Adresse des Sensors.
Eigentlich müsste replaceBatteryForSec und erneutes raus rein der Batterien jetzt nochmal gehen.
Ich hänge mich mal dran.
Mein JeeLink empfängt einen TX29 T. FHEM läuft auf dem Raspi, mit den neuesten Updates.
Ein paar Wochen lief es einwandfrei, jetzt stoppt nach einem halben bis ganzem Tag die Aufzeichnung der Daten.
Der JeeLink empfängt nichts mehr, im Eventmonitor ist nichts mehr zu sehen und es wird auch nicht mehr gelogged.
Ich bin mir sicher das der Sensor noch sendet:
Sobald ich fhem "shutdown restart" wird wieder gelogged. Ich habe versucht den JeeLink alleine mal zu rebooten mit raw set B00, was aber nicht zum Ziel führte.
Jemand einen Tip um bei der Fehlersuche voranzukommen?
den jeelink kannst du mit set <jeelink> resetneu starten.
lass den jeelink mal mit einer seriellen konsole laufen und schau was passiert.
gruss
andre
;D werde ich...in so 6h mal testen
Danke
So...es waren dann nur 4h. "set myJeeLink reset" hilft sofort, er läuft dann wieder.
Ich helfe mir übergangsweise mit einem watchdog zum resetten und benachrichtigen.
Was meinst du damit ihn an einer seriellen Konsole anzuschliessen? Sobald ich ihn ja ausstecke und eventuell am PC anschließe ist er ja resettet.
Zitat von: RitterSport am 01 Dezember 2014, 13:51:34
Was meinst du damit ihn an einer seriellen Konsole anzuschliessen? Sobald ich ihn ja ausstecke und eventuell am PC anschließe ist er ja resettet.
Ich vermute, dass er meint, dass Du den JeeLink mal an einen Rechner stecken sollst, auf dem ein Terminalprogramm läuft. Da sollten dann Daten in der Art
OK 9 41 1 4 164 50 eingehen. Und dann mal einen Tag abwarten, ob der JeeLink irgendwann die Arbeit einstellt und nichts mehr kommt.
Damit wäre getestet, ob der Sketch stehen bleibt oder FHEM irgendwann nicht mehr will.
Welche Version vom Sketch hast Du denn drauf?
Momentan läuft er am Terminalprogramm und gibt aus:
OK 9 240 1 3 18 106
oder
OK 9 8 1 4 4 106
Welche Sketch-Version ich drauf habe , konnte ich nicht rausfinden bisher nur beim Auslesen/Abspeichern gibt er folgenden Namen:
sketch_dec02a
Ich warte jetzt mal ab.
Hallo
ich habe seit gestern das gleiche Problem. JeeLink lief seit einem Monat problemlos.
Bei mir kommt als Ereignis hinzu, dass mein NAS mit mit der DbLog fast 24h nicht erreichbar war, ehe ich es gemerkt und einen Reset gemacht habe. Den Raspberry mit fhem habe ich danach auch rebooted, und dann festgestellt, dass der JeeLink nach ein paar Sekunden nichts mehr empfängt.
myJeeLink_MSGCNT und myJeeLink_TIME bleiben einfach stehen. Nun habe ich auch erstmal einen watchdog erstellt um zu sehen, wie oft das auftritt, aber eher unregelmäßig. Manchmal steigt er schon nach ein paar Sekunden aus, mal ein paar Minuten. Ich beobachte nun erstmal.
Ich habe den JeeLink an einem Arduino Nano mit CH340 chipsatz, vielleicht liegt es daran.
Hat schon jemand rausgefunden, ob es am Sketch oder an FHEM liegt?
Danke, THomas
Ich habe gerade nochmal nachgeschaut. Der JeeLink ist vor dem NAS ausgefallen, hat damit also wohl nix zu tun.
Ich kann mich nicht mehr erinnern wo, aber in einem anderen Thread hat mal jemand ähnliche Probleme mit einem JeeLink an einem Raspi berichtet und dass das Problem weg war, nachdem er ein besseres Netzteil verwendet hat.
Hast Du LEDs mit drauf gebaut? Die erste Frage ist, ob der JeeLink steht oder ob er noch empfängt aber über die Schnittstelle nichts mehr auf Deinem Server rein kommt.
Hallo
ich habe den Watchdog mit 60 Sekunden seit gestern nachmittag laufen und keinen weiteren Ausfall gehabt.
Ich hatte bemerkt, dass der JeeLink direkt neben das Netzteil des RPi gerutscht war (alles noch im Bastelstadium, noch nicht ordentlich verbaut), evtl. lag es daran? Seitdem ist der JeeLink 20cm weiter weg.
Heute Abend setze ich den Watchdog auf 30 Minuten. Sollte es nochmal passieren hänge ich den Arduino mal an den Rechner und schaue, ob er sich irgendwann aufhängt. Allerdings kann man mit dem Watchdog einfach einen Reset machen, und danach geht er ja wieder, das wäre für mich als Lösung ausreichend.
Thomas
Hallo
Im Moment habe ich auch das Problem das der Jeelink (Clone) keine aktuellen Daten mehr empfängt. LaCrosse_MSGCNT und LaCrosse_TIME bleiben stehen. Eine LED zeigt mir aber an das die Daten der Sensoren empfangen werden.
Über set LaCrosse reset lässt es sich sofort wieder starten.
Jetzt würde ich gerne erst einmal einen Watchdog einrichten damit es wenigstens weiter läuft.
Thedude kannst du mir deinen Code zeigen? Leider weiß ich noch nicht wie man den Watchdog genau einrichten muss
Gruß Kalli
Hallo Kalli
Hier mein Code:
define JeeLinkDown watchdog (Sensor1|Sensor2|Sensor3|Sensor4) 00:30 SAME { DebianMail('beispiel@provider.de','Betreff','Text');; fhem("set myJeeLink reset");; fhem("trigger JeeLinkDown .");;}
attr JeeLinkDown room System
Zur Erklärung (s. auch http://fhem.de/commandref_DE.html#watchdog (http://fhem.de/commandref_DE.html#watchdog))
JeeLinkDown: frei gewählter Name des watchdog
(Sensor1|Sensor2|Sensor3|Sensor4) : Das sind die am JeeLink angeschlossenen Sensoren, mit denen der watchdog gestartet wird
00:30 bedeutet, dass er, sobald ein Ereignis des JeeLink registriert wird, den Prüfzeitpunkt auf diesen Zeitpunk+30 Minuten verschiebt, das passiert bei jedem Ereignis (Es gehen auch Sekunden, 03:30:13 bedeutet 3 Stunden, 30 Minuten und 13 Sekunden)
SAME bedeutet, dass ebenfalls die Sensoren (Sensor1|Sensor2|Sensor3|Sensor4) den Prüfzeitpunkt verschieben, hier kann man auch zwei unabhängige Sensoren/Ereignisse verknüpfen. Falls man zB einen Türsensor hat und daneben einen mit FHEM verbundenen Knopf könnte man hier mit einem Watchdog einen Alarm auslösen, wenn nicht innerhalb von X Sekunden nach Ereignis "Türsensor" das Ereignis "Knopf" empfangen wird, was zB dem Entschärfen einer Alarmanlage entsprechen würde. Das Ereignis, mit dem der Watchdog gestartet wird und das Ereignis, mit dem er verlängert wird, können also unterschiedlich sein.
Nach SAME kommen beliebige Befehle, in meinem Fall eine Email und das zurücksetzen des JeeLink (weil er ja irgendwie hing und nach dem reset wieder da war) und des watchdog (trigger), damit die Prüfperiode erneut beginnt, sonst würden keine weiteren Aktionen passieren. Somit bekommt man dann alle 30 Minuten eine Email und sieht, dass der JeeLink länger weg ist, aber muss nicht gleich auf die erste Email reagieren. Ich hatte den Wert am Anfang auf 1 Minute und habe ihn jetzt auf 30 Minuten hochgesetzt, seither keine Aussetzer mehr.
Grüße, Thomas
Danke Thomas,
das habe ich verstanden und es funktioniert auch schon.
Ich hatte versucht den Jeelink selbst aus Auslöser für den Watchdog zu nutzen.
Meinst du mit keine Aussetzer mehr das es mit dem Watchdog durchgängig funktioniert oder hast du eine Lösung für die Aussetzer selbst gefunden?
Bei mir läuft es nicht mal eine Stunde am Stück.
Gut so kann ich erst einmal weiter machen.
Kalli
Hallo Kalli,
ich habe seitdem keine Aussetzer mehr, aber das liegt nicht am Watchdog, sondern anscheinend hat das Raspberry Netzteil meinen JeeLink gestört. Nun haben sie beide etwas Abstand und es gibt keine Aussetzer mehr.
Thomas
Sent from my Nexus 5 using Tapatalk
Habe ihn jetzt mal mit einem Kabel weiter weg gelegt aber es ist nicht wirklich besser geworden.
Der Platz ist nicht optimal. Firtzbox, Decttelefon und viele Netzteile.
Mal weiter beobachten.
Gruß Kalli
Hallo - ich habe seit 2 Tagen das gleiche Problem mit meinem JeeLink, den Watchdog werde ich gleich einbauen...@Kalli01: Kpnntest die Ursache für die Ausfälle bei Dir feststellen?
Ich werde den JeeLink auch mal aus FHEM rausnehmen und per serieller Konsole überwachen...
Hallo SVLoneStar
Bei mir hängt es mit dem Netzteil für den Raspberry Pi zusammen. Ein Netzteil von einer Powerbank mit 1A funktioniert fehlerfrei aber wird sehr warm.
Ich habe dann noch zwei stärkere versucht aber die sind wieder schlechter. Im Moment bleibt nur mir nur die Lösung mit dem Watchdog.
Hmmm...interessant...bei mir ist's ein CubieTruck, an dem 5 CULs hängen, die Probleme fingen gestern plötzlich an. Danke für Deine Antwort!
Sent from my iPhone using Tapatalk
Anstatt watchdog kann man seit kurzem auch das timeout Attribut des JeeLink device verwenden.
siehe hier: http://forum.fhem.de/index.php/topic,14786.msg342764.html#msg342764
Es zeigt sich aber immer mehr, dass das wohl ein Spannungsversorgungs-Thema ist.
Das 2A auf einem Netzteil drauf steht, hat auch nicht viel zu bedeuten.
Das Netzteil, das den Cubie versorgt, von dem der angehängte Plot ist, ist ein 2A Netzteil.
Nachts um zwei Uhr, wenn er Backups macht, hat er mal etwas Last und da bricht die Spannung bei ca. 600mA schon teilweise auf 4,8V ein.
Wenn so ein Netzteil bei Lastspitzen üble peaks nach unten hat, könnte das dann einen JeeLink vielleicht aus der Bahn werfen.
Interessant wäre, wenn mal jemand, bei dem das öfters passiert, Spannung und Strom plotten würde, dann könnte man evtl. einen Zusammenhang erkennen.
Mache ich gerne...per PCA301 vor dem Netzteil des CT oder wie?
Sent from my iPhone using Tapatalk
Mit dem SYSMON Modul
So (stumpf rauskopiert, musst es evtl. für Dich sinnvoll anpassen):
define sysmon SYSMON 1 1 1 10
attr sysmon event-on-update-reading power_ac_stat,power_battery_stat,cpu_temp,cpu_freq
attr sysmon filesystems /, /mnt/usb/backup, /mnt/usb/nas
attr sysmon group SYSMON
attr sysmon room System
define FileLog_sysmon FileLog ./log/sysmon-%Y-%m.log sysmon
attr FileLog_sysmon group SYSMON
attr FileLog_sysmon logtype text
attr FileLog_sysmon room System
define sysmon_plot_1 SVG FileLog_sysmon:mySysmon_1:CURRENT
attr sysmon_plot_1 label $data{currval1}::$data{currval2}::$data{currval3}
attr sysmon_plot_1 room Cubie
Nachtrag: filesystems passt bei Dir so natürlich nicht.
Ok, sorry für die Frage... ;)
Sysmon läuft schon, aber ohne die Power-Readings...ich baue die gleich mal ein. Danke!
Sent from my iPhone using Tapatalk
Anbei die ersten Screenshots....ich habe folgende Charts übereinander gestellt:
- Power Consumption
- 'Alive'-Signale eines TX25 (wo's grau wird, ist der Empfang beim JeeLink abgebrochen)
- Load auf dem CubieTruck
Alle Carts gehen über die letzten 3 Tage. Da die Charts unterschiedlich groß waren, musste ich sie resizen.
Meines Erachtens passiert zum Zeitpunkt des 'Jeelink-Ausfalls' nix Besonderes beim Strimbedarf oder der CPU-Last...?
NACH dem Reset des JeeLink geht die CPU-Last hoch, vermutlich weil die ganzen LaCrosse-Geräte (8 Stück) zeitgleich 'abgearbeitet' werden...?
Die Schwankungen bei Spannungsvesorgung und Stromverbrauch kommen mir trotzdem 'extrem' vor...schaut so aus, als könnte ein besseres Netzteil 'generell' helfen...?
Danke für Deine Unterstützung!
Zitat von: SVLoneStar am 20 Oktober 2015, 11:51:57Anbei die ersten Screenshots....
Für die hat wohl der Strom nicht mehr gereicht ;D
Hier noch ein Schirmschuss von meinem Test-System, das an einem anderen Netzteil (keine Ahnung auswendig, was es ist) hängt.
Der Unterschied ist deutlich.
Nachtrag: das System weiter oben ist auch schon einige male Nachts bei den Backups gestorben und musste von Debian-WatchDog gerettet werden.
Das Test-System noch nie.
Ich denke, eine zuverlässige Spannungsversorgung ist die Grundlage von Allem.
Eigentlich müsste man mit dem Cubie und FHEM drauf in den Elektronikladen und erst mal dort schauen, wie sich die Netzteile so geben ;D
Habe jetzt ein paar Minuten den Strom in einen Kondensator laufen lassen, jetzt sollte auch der Upload der Screenshots klappen... :o ;D
Dein Nezteil taugt auch nicht mehr als das eine von mir.
Das sind auch gute 0,4V was das bei Last rumeiert.
Die Frage ist, ob die zeitliche Auflösung der Messung reicht, um sehr kurze, heftige Peaks zu sehen, die den JL dann aus der Bahn werfen.
Aber generell macht das Netzteil keinen guten Eindruck.
Kannst ja mal ein anderes probieren und schauen, ob das von den Kurven her besser aussieht und das Problem dann auch weg ist.
Werde ich tun. Dieses Netzteil kam mit dem CT und ist von daher vermutl. schon eher 'günstig' als 'gut'... :)
Ich besorge eines, lasse das ein paar Tage laufen und melde mich dann nochmal (mit Status & Screenshots).
Hi
kann ich mir mit Hilfe von Sysmon auch bei einem Raspberry Pi die Spannung und den Strom anzeigen lassen? Unter den Readings finden ich keinen Eintrag mit Power.
Zitat von: Kalli01 am 20 Oktober 2015, 17:34:36
kann ich mir mit Hilfe von Sysmon auch bei einem Raspberry Pi die Spannung und den Strom anzeigen lassen? Unter den Readings finden ich keinen Eintrag mit Power.
Frag mal im SYSMON thread
@Kalli01: Ich hab's schnell mal ausprobiert...geht auf einem RasPi wohl nicht. Das erklärt auch, warum ich keinen Plot vom Stromverbrauch hatte...meine 'produktive' FHEM-Instanz war mal ein RasPi und wurde später ein CubieTruck...und auf dem RasPi wird das Reading nicht geliefert. :)
Sent from my iPhone using Tapatalk
Oh, noch was...irgendwelche Empfehlungen für ein stabiles 2A Netzteil? Oder Try and Error? :)
Nachtrag: Das hier sollte doch taugen, oder?
http://www.amazon.de/Anker-Ladeger%C3%A4t-PowerIQ-Technologie-Motorola/dp/B00WLI5E3M (http://www.amazon.de/Anker-Ladeger%C3%A4t-PowerIQ-Technologie-Motorola/dp/B00WLI5E3M)
Vielleicht ein bisserl oversized, aber damit wäre man wohl 'auf der sicheren Seite'...
Sent from my iPhone using Tapatalk
So habe ich es auch gemacht.
Das hier hat 2A aber ist nicht besser als mein altes.
http://www.amazon.de/gp/product/B00GM0305Y
Zitat von: SVLoneStar am 20 Oktober 2015, 20:49:17
Nachtrag: Das hier sollte doch taugen, oder?
http://www.amazon.de/Anker-Ladeger%C3%A4t-PowerIQ-Technologie-Motorola/dp/B00WLI5E3M (http://www.amazon.de/Anker-Ladeger%C3%A4t-PowerIQ-Technologie-Motorola/dp/B00WLI5E3M)
Dieser Satz aus der Produktbeschreibung würde mich etwas nervös machen:
PowerIQ Erkennt Ihr Gerät. Liefert die schnellste Ladung.
Die exklusive intelligente Anker PowerIQ Amp-Anpassungstechnologie identifiziert Ihr Gerät und liefert die schnellstmögliche Ladung.Als was erkennt es denn einen Cubie und was gesteht es ihm dann zu?
Ja, da bin ich auch dran hängen geblieben...
Die Idee war, was von einer 'Marke' zu nehmen statt ein NoName-2A-Netzteil...so eines ist schon dran :(
Ich hab's mal bestellt...schaumermal...ich werde berichten (wohl am Sa. oder So.)
Sent from my iPhone using Tapatalk
Das Anker-Netzteil (bzw. Ladegerät) wurde gestern geliefert. Ok, schaut jetzt irgendwie nicht sooo viel besser aus... :(
Andererseits hatte ich seit 3 Tagen keinen JeeLink-'Ausfall' mehr. Alles sehr seltsam, das...
Gegen Mittag habe ich mal ein Backup in FHEM angestossen - Spannung geht etwas hoch, Strom etwas runter...könnte das eine Folge des 'PowerIQ' des Ladegeräts sein?
Das liegt mit der Spannung ja deutlich zu niedrig.
Läuft der Cubie damit stabil?
Bis jetzt ja, keine Probleme
Sent from my iPhone using Tapatalk
Hatte in 2 Monaten Laufzeit auch schon zwei mal einen unresponsive jeelink.
Hoffentlich liegts wirklich nur an der Stromversorgung.
Werds jetzt mal mit einem 12V Netzteil und einem externen Schaltregler und fetten Stützkos probieren.
Überleg noch ob ich die Einspeisung in den Raspberry nach der Sicherung mach.
Die 12V haben auch noch den Vorteil, dass ich direkt auf einen Bleigelakku fahren kann.
Zitat von: thedude am 07 Juni 2015, 13:39:56
Hallo Kalli
Hier mein Code:
define JeeLinkDown watchdog (Sensor1|Sensor2|Sensor3|Sensor4) 00:30 SAME { DebianMail('beispiel@provider.de','Betreff','Text');; fhem("set myJeeLink reset");; fhem("trigger JeeLinkDown .");;}
attr JeeLinkDown room System
Zur Erklärung (s. auch http://fhem.de/commandref_DE.html#watchdog (http://fhem.de/commandref_DE.html#watchdog))
JeeLinkDown: frei gewählter Name des watchdog
(Sensor1|Sensor2|Sensor3|Sensor4) : Das sind die am JeeLink angeschlossenen Sensoren, mit denen der watchdog gestartet wird
00:30 bedeutet, dass er, sobald ein Ereignis des JeeLink registriert wird, den Prüfzeitpunkt auf diesen Zeitpunk+30 Minuten verschiebt, das passiert bei jedem Ereignis (Es gehen auch Sekunden, 03:30:13 bedeutet 3 Stunden, 30 Minuten und 13 Sekunden)
SAME bedeutet, dass ebenfalls die Sensoren (Sensor1|Sensor2|Sensor3|Sensor4) den Prüfzeitpunkt verschieben, hier kann man auch zwei unabhängige Sensoren/Ereignisse verknüpfen. Falls man zB einen Türsensor hat und daneben einen mit FHEM verbundenen Knopf könnte man hier mit einem Watchdog einen Alarm auslösen, wenn nicht innerhalb von X Sekunden nach Ereignis "Türsensor" das Ereignis "Knopf" empfangen wird, was zB dem Entschärfen einer Alarmanlage entsprechen würde. Das Ereignis, mit dem der Watchdog gestartet wird und das Ereignis, mit dem er verlängert wird, können also unterschiedlich sein.
Nach SAME kommen beliebige Befehle, in meinem Fall eine Email und das zurücksetzen des JeeLink (weil er ja irgendwie hing und nach dem reset wieder da war) und des watchdog (trigger), damit die Prüfperiode erneut beginnt, sonst würden keine weiteren Aktionen passieren. Somit bekommt man dann alle 30 Minuten eine Email und sieht, dass der JeeLink länger weg ist, aber muss nicht gleich auf die erste Email reagieren. Ich hatte den Wert am Anfang auf 1 Minute und habe ihn jetzt auf 30 Minuten hochgesetzt, seither keine Aussetzer mehr.
Grüße, Thomas
Ich hätte da eine Frage zum Watchdog. Ich versuche gerade den Sensor X durch den MSGCNT zu ersetzten. Allerdings mit mäßig Erfolg :(
Wie kann ich die Internals abfragen und in dem WD verwenden? Wenn ich mit
list myJeeLink myJeeLink_MSGCNT bekomme ich den Wert des Counters. Wenn ich versuche myJeeLink myJeeLink_MSGCNT als <regexp1> zu setzen bekomme ich einen Fehler. In Klammern kann ich das nicht auch nicht setzten.
Also das tut so nicht:
define JeeLinkDown watchdog (myJeeLink myJeeLink_MSGCNT) 00:30 SAME { DebianMail('beispiel@provider.de','Betreff','Text');; fhem("set myJeeLink reset");; fhem("trigger JeeLinkDown .");;}
Da bekomme ich nur "Bad regexp 1: Unmatched ( in regex; marked by <-- HERE in m/^( <-- HERE myJeeLink$/ at ./FHEM/91_watchdog.pm line 49."
Irgendwie stehe ich gerade auf dem Schlauch....
internals erzeugen keine events und lassen sich nicht per notify überwachen.
deine regex ist nicht die aus dem code weiter oben. dort ist nur der device namen angeben. MSGCNT taucht nicht auf.
leerzeichen in einer notify regex müßen durch . oder \s ersetzt werden. und zwischen device und reading würde ein : gehören.
Zitat von: thedude am 07 Juni 2015, 13:39:56
Hallo Kalli
Hier mein Code:
define JeeLinkDown watchdog (Sensor1|Sensor2|Sensor3|Sensor4) 00:30 SAME { DebianMail('beispiel@provider.de','Betreff','Text');; fhem("set myJeeLink reset");; fhem("trigger JeeLinkDown .");;}
attr JeeLinkDown room System
Zur Erklärung (s. auch http://fhem.de/commandref_DE.html#watchdog (http://fhem.de/commandref_DE.html#watchdog))
JeeLinkDown: frei gewählter Name des watchdog
(Sensor1|Sensor2|Sensor3|Sensor4) : Das sind die am JeeLink angeschlossenen Sensoren, mit denen der watchdog gestartet wird
00:30 bedeutet, dass er, sobald ein Ereignis des JeeLink registriert wird, den Prüfzeitpunkt auf diesen Zeitpunk+30 Minuten verschiebt, das passiert bei jedem Ereignis (Es gehen auch Sekunden, 03:30:13 bedeutet 3 Stunden, 30 Minuten und 13 Sekunden)
SAME bedeutet, dass ebenfalls die Sensoren (Sensor1|Sensor2|Sensor3|Sensor4) den Prüfzeitpunkt verschieben, hier kann man auch zwei unabhängige Sensoren/Ereignisse verknüpfen. Falls man zB einen Türsensor hat und daneben einen mit FHEM verbundenen Knopf könnte man hier mit einem Watchdog einen Alarm auslösen, wenn nicht innerhalb von X Sekunden nach Ereignis "Türsensor" das Ereignis "Knopf" empfangen wird, was zB dem Entschärfen einer Alarmanlage entsprechen würde. Das Ereignis, mit dem der Watchdog gestartet wird und das Ereignis, mit dem er verlängert wird, können also unterschiedlich sein.
Nach SAME kommen beliebige Befehle, in meinem Fall eine Email und das zurücksetzen des JeeLink (weil er ja irgendwie hing und nach dem reset wieder da war) und des watchdog (trigger), damit die Prüfperiode erneut beginnt, sonst würden keine weiteren Aktionen passieren. Somit bekommt man dann alle 30 Minuten eine Email und sieht, dass der JeeLink länger weg ist, aber muss nicht gleich auf die erste Email reagieren. Ich hatte den Wert am Anfang auf 1 Minute und habe ihn jetzt auf 30 Minuten hochgesetzt, seither keine Aussetzer mehr.
Grüße, Thomas
Hi,
ich habe manchmal Probleme zwischen meinem
"JeeLink" und meiner "LaCrosse" "WS-16000" Wetterstation.
Die Entfernung ist scheinbar etwas zu weit und daher bricht manchmal die Verbindung ab.
Ich suche eine Möglichkeit um den JeeLink automatisch zu resetten wenn keine Daten mehr von der WS-1600 übertragen werden.
Weiterhin ist noch ein zweiter LaCrosse Sensor am JeeLink, der immer Verbindung hat. Also der Jeelink bekommt immer Daten, nur halt manchmal von der WS-1600 nicht.
bringt mir in diesem Fall dieser wtchdog etwas?
defmod JeeLinkDown watchdog (LaCrosse_1F) 00:10 SAME { fhem("set Pushover_Pushnachrichten msg 'Wetterstation' 'DOWN' 'iPhoneThomas' 0 'none' 0 0 ");; fhem("set myJeeLink reset");; fhem("trigger JeeLinkDown .");;}Oder wie könnte ich einen automatischen JeeLink reset erzwingen wenn die WS-1600(LaCrosse_1F) keine Daten mehr liefert?
LG Thomas