notify auf Fehlermeldungen

[gero]

Seit ca. 3 Wochen habe ich das Problem, dass sich mein CUL disconnected und damit meine Heizungssteuerung nicht mehr läuft:

Code Auswählen Erweitern

2014.10.31 16:42:29 1: CUL_MAX_Parse: len mismatch
2014.10.31 16:42:32 1: /dev/ttyACM0 disconnected, waiting to reappear (CUL_0)
2014.10.31 16:42:32 1: Error in CUL_MAX_SendQueueHandler: CUL CUL_0 did not answer request for current credits. Waiting 5 seconds.
2014.10.31 16:42:34 1: Error in CUL_MAX_SendQueueHandler: CUL CUL_0 did not answer request for current credits. Waiting 5 seconds.
2014.10.31 16:42:39 1: Error in CUL_MAX_SendQueueHandler: CUL CUL_0 did not answer request for current credits. Waiting 5 seconds.


Die Ursache dieses Problems muß ich noch finden. Aber mich interessiert vor allem, ob solche Fehlermeldungen von FHEM (also kritische Fehlermeldungen) ein notify auslösen können, um mir z.B. eine Email zu schicken.
Bisher habe ich keinen Mechanismus gefunden. Aber vielleicht habe ich ihn nur übersehen(?) Welches Device könnte ein solches notify triggern?

Gruß,
Gero

[Elektrolurch]

Hallo,

Du kannst so was definieren:

(Bei mir heißt der CUL_0)

define CUL_0_not notify CUL_0:.* {cul_not($NAME,$EVENT);;}

in der sub:

sub cul_not($$)
{
my ($name,$event) = @_;
Log(1,"cul_not: name: $name  event $event");

Das kannst Du Dir dann schon mal ins log schreiben

mit

my $s = fhem("get $name raw T02");

Hast Du in $s den Status des Sendebuffers stehen

my ($code) = split(':',$s);

Der ist entweder n/a - leer

oder sowas wie

12345:xxxx,aaa,dddd

Das vor dem : also das 12345 ist der Code des devices, dessen Daten noch im Puffer des CULs sthen:

Der Code steht im internen Hash des devices:

$hash->{CODE}

Auf diese Weise habe ich die FHTs gefunden, die daran Schuld sind, dass der CUL ab und zu mal aussteigt.

foreach my $d (values $defs)
{
Log(1,"$d->{NAME} ist der Übertäter!") if($code eq $d->{CODE});
} # end foreach


Gruß

Elektrolurch


P.S.: ist nur eine Anleitung, ein bisserl Mitdenken ist ev. auch noch notwendig!

[gero]

@ Elektrolurch: Danke für deine Antwort. Ich habe inzwischen etwas ähnliches eingebaut, um eine Email zu bekommen , sobald  mein CUL disconntected. Aber es muß doch möglich sein eine allgemeine Notification zu bekommen, sobald ein kritisches Ergeignis auftritt. Z.B. etwas, was mit verbositiy Level 1 im Filelog gemeldet wird!?

Gruß,
Gero

[Elektrolurch]

Sorry, aber wie man auf Log(1,... etwas triggert, ist mir nicht bekannt.

[QuaGS]

Der Fehler läuft bei mr auch schon eine Weile auf. Hast Du die Ursache gefunden und vielleicht eine Lösung parat?
Gruß, Ernst

Code Auswählen Erweitern


2014.10.31 16:42:32 1: Error in CUL_MAX_SendQueueHandler: CUL CUL_0 did not answer request for current credits. Waiting 5 seconds.
2014.10.31 16:42:34 1: Error in CUL_MAX_SendQueueHandler: CUL CUL_0 did not answer request for current credits. Waiting 5 seconds.
2014.10.31 16:42:39 1: Error in CUL_MAX_SendQueueHandler: CUL CUL_0 did not answer request for current credits. Waiting 5 seconds.


Die Ursache dieses Problems muß ich noch finden. ...

Gruß,
Gero

[gero]

Es gab einen Fehler im CUL Modul. Wenn du fhem aktualisierst, sollte der Fehler weg sein.

[Sithonia]

Hallo,
hatte gerade selbige Fehlermeldung. Bei mir lag es an der Antenne am SCC1101. Habe mit verschiedenen Typen experimentiert. Nach Anschluß der mitgelieferten Stummelantenne, ist wieder alles ok und das Logfile sauber!
Gruß

[Dietmar63]

Ich habe diesen Fehler auch schon seit geraumer Zeit - wenn auch selten, Ursache unbekannt.

Das Problem dabei, es werden nach dem Fehler keine Nachrichten mehr an die FHT gesendet, ich meine sogar, dass keine Befehle mehr gesendet werden - blöd, wenn  Heating_Control keine Temperaturaktualisierungen mehr senden kann, und ich abends in eine kalte Wohnung komme.

Ganz zu schweigen von dem Ärger mit der Familie.

Langezeit konnte ich den Fehler nicht nachstellen.
Durch ein wenig Probiererei habe ich den Absturz des CUL dann nachahmen können, indem ich in fhem im CUL "get raw" ohne Parameter eingeben habe. Danach ist mein CUL tot. 

... und nun helfe ich mir so:

Code Auswählen Erweitern

define CULautoRepair          notify CUL_0:.* {Log 3, "Nachricht von @: %";; fhem ("set CUL_0 reopen") }

Es ist nicht einmal nötig ein wenig zu warten:

Code Auswählen Erweitern


2014.12.17 20:26:59 3: CUL_0: Possible commands: BbCFiAZEGMKUYRTVWXefmltux
2014.12.17 20:26:59 1: /dev/ttyACM0 reappeared (CUL_0)
2014.12.17 20:26:59 3: Setting CUL_0 baudrate to 96
2014.12.17 20:26:59 3: Nachricht von CUL_0: DISCONNECTED
2014.12.17 20:26:59 1: /dev/ttyACM0 disconnected, waiting to reappear (CUL_0)


Das bringt den CUL wieder auf Trabb.
Habt ihr auch dieses Problem?
Weiß jemand von Euch warum der CUL so außer Tritt gerät, wenn man ihn mit "get raw" abfragt?

Also bei mir ist das Problem wahrscheinlich durch den automatischen reopen gelöst!!!

@gero:
vielleicht kannst du die Überschrift des threads verbessern. Man weiß nicht gleich worum es geht.

[gero]

@gero:
vielleicht kannst du die Überschrift des threads verbessern. Man weiß nicht gleich worum es geht.

Es ging mir darum, zu klären, ob es möglich ist auf Kritische Fehler irgendwelche Aktionen zu triggern.
Ich finde den Titel also ganz passend. Falls du aber einen besseren Vorschlag hast, werde ich ihn gerne ändern.

Die CUL-Problematik war nur ein Beispiel und das Problem wurde in einem anderen Thread geklärt.
Ich fände es wichtig, wenn man sich über wichtige Fehler (z.B. defniert über ein spezielles Loglevel) informieren lassen könnte, egal wodurch sie erzeugt werden, denn das weiß man ja vorher meist nicht . Es geht aber leider zur Zeit nicht.

Gruß,
Gero

[Elektrolurch]

Hallo,

fhem weiß leider mal nicht was "kritisch" sein soll, denn es behandelt ja alle devices, ob CUL oder Thermostat oder Türkontakt zunächst einmal gleich. Jeder Modulautor muss dann über den log-level entscheiden, welche Ereignisse ins logfile geschrieben werden sollen. Da gibt es dann die Regel, dass der loglevel 1 als "sher kritisch" eingestuft wird usw.
Leider kann man m.K.n. nicht auf Eintragungen im logfile ein notify setzen.
Dasss mit den Mailbenachrichtigungen habe ich über eine eigene Funktion bewerkstelligt, die bei typ = INFO in ein eigenes Logfile schreibt und bei Typ = ALARM dann auch noch eine Mail versendet. Das sind aber alles "höhöherwertige" Ereignisse, wie "Alarmanlage eingeschaltet", "Alarm ausgelöst", "Fenster auf, Raumtemperatur sinkt unter 16 Grad" oder auch "CUL gestört".

Zum Thema CUL: Ich habe das Problem mit dem disconnect bei einem CUNO (gibt es auch einen Beitrag dazu: CUNO status disconnect), leider funktioniert das reopen beim CUNO nicht, das scheint nur bei USB-Geräten zu funktionieren.

Elektrolurch