Events per $TYPE ins Filelog schreiben

Begonnen von hmtec99, 26 März 2017, 12:06:07

Vorheriges Thema - Nächstes Thema

hmtec99

Hallo Leute,

wäre es nicht sehr hilfreich für die Fehlersuche, wenn man (zeitweise) Events in FileLog schreiben lassen könnte? Am besten fände ich einen Filter
vom Typ $TYPE um alle Events aus dem EventMonitor abhängig von einem Modul ins Log zu übernehmen und das selbe nochmal für FileLog selbst,
dann hätte man alles beisammen und könnte auch im Nachhinein gewisse Abläufe wesentlich besser nachvollziehen (z.B. nach einem Absturz).

War mein Wunsch verständlich?  :o

Gruß, Oliver

betateilchen

Zitat von: hmtec99 am 26 März 2017, 12:06:07
War mein Wunsch verständlich?

Den Wunsch habe ich verstanden, den Sinn dahinter allerdings noch nicht.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

hmtec99

Der Sinn?

Das Logfile enthält ja nur per Modul defnierte Meldungen eines bestimmten Loglevels (richtig?).

Wenn ich also wissen will, wie genau der Ablauf eines ... wie soll ich das mal nennen... "Event" wäre nicht treffend... nennen wir
es mal ..."Vorgang"... wenn ich also einen kompletten "Vorgang" aufgezeichnet haben will, also:

- Gerät löst durch Modul Event aus
- Notify löst durch Event Ereignis aus
- Modul tut aufgrund des Ereignisses irgendwas

Dann hätte ich den gesamten Ablauf des Ereignisses (also auch die Events aus dem Eventmonitor). Das ganze dann möglicherweise in ein eigenes
Logfile - wäre doch für die Fehlersuche sehr hilfreich oder nicht?

Also im Endeffekt eine Aufzeichnung des Eventmonitors mit angehaktem FHEM Log (gefiltert durch $TYPE um nur ein Modul aufzuzeichen). Damit hätte
ich dann auch im Nachhinein eine übersichtliche Aufzeichnung für die Fehlersuche ohne die Events und Logeinträge aller anderen Module.


hmtec99

#3
Nochmal mit Bild  ;)

Ich kann natürlich jedes ein Modul betreffendes Event per Regex in ein Logfile schreiben, aber:

- das wären je nach erzeugten Events pro Modul sehr viele
- bei Änderungen im Modul müßte man wieder prüfen ob alles im Logfile aufläuft
- man hätte wieder 2 Orte, die man zur Fehlersuche zusammenführen müßte:FHEM Logfile und o.g. Logfile

Deshalb wäre es doch viel einfacher per $TYPE (z.B. CUL_HM siehe Screenshot) definierte Events ins FHEM Logfile zu schreiben.

Grundsätzlich wäre es manchmal gut Events in eine Datei zu schreiben zu können (und nicht nur per FHEMWEB den aktuellen Status zu haben).

igami

Leg dir ein notify mit einerm userattr TYPE an das auf alles triggert.
Beim Auslösen prüfst du dann ob das device denbetroffenen TYPE hast und machst ein trigger auf das eigene notify mit dem Event.
Für das Notify machst du dann noch ein FileLog. Es fehlen dann nur noch die Log einträge, dafür hat notify das readLog attribut
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

hmtec99

Zitat
Leg dir ein notify mit einerm userattr TYPE an das auf alles triggert.

Wie wirkt sich das auf die Systemlast aus? Oder habe ich das falsch verstanden?

betateilchen

Zitat von: hmtec99 am 26 März 2017, 12:38:48
Also im Endeffekt eine Aufzeichnung des Eventmonitors

Nichts einfacher als das. Verlassen wir mal das Klicki-Bunti-Browser-Denken und besinnen uns auf die Ursprünge funktionierender IT zurück. Damals gab es nur eine Systemconsole, die uns auch heute noch gute Dienste leistet, weil sie "unlösbare" Aufgaben einfach per Befehlszeile löst...


telnet localhost 7072 |tee -a -i tn.log


dann gibst Du in der telnet Session "inform timer" ein und schon gehts los. Sobald Du telnet mit "quit" verlassen hast, findest Du in der Datei tn.log die gewünschte Aufzeichnung des EventMonitors während Deiner Experimente.

Eine Filterung auf TYPE finde ich zu Fehlersuche sogar eher kontraproduktiv. Gerade bei der Fehlerursache sind manchmal Module verantwortlich, an die man erstmal gar nicht denkt.

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!