Hook für Logfile

[Ruebezahl]

Hallo,

ich würde mir wünschen, das Logfile etwas mehr zu beeinflussen außer der Möglichkeit, mit dem Loglevel zu arbeiten. In meinem Fall z.B. lasse ich alle 2 Sekunden einen Timer laufen der jeweils einen Eintrag im Log erzeugt. Das interessiert mich nicht wirklich im Log, daher würde ich es gerne unterdrücken. Loglevel des Eintrages ist 3 und leider sind einige interessante Einträge im Log auch auf Level 3.

Ich könnte mir vorstellen in der Subroutine Log von fhem.pl könnte ein anderes Perl-Modul aufgerufen werden (im Standardfall tut dieses Moduls nichts, ist aber vorhanden) und in diesem Perlmodul könnte eine Filterung oder was sonst noch für bestimmte Logeinträge stattfinden, das würde jeweils in der Verantwortung des Benutzers liegen, was er sich da hineinprogrammiert. Rückgabewert des Moduls ist halt der Text, der, wenn nicht leer halt im Log gespeichert wird. Wenn der Text leer ist, wird halt kein Eintrag im Log gespeichert.

Wäre so etwas realisierbar?

Viele Grüße,

Rübe

[Icinger]

Warum setzt du das verbose 2 nicht explizit für den Timer? Dann läuft alles andere trotzdem weiter ins Log.

lg, Ici

[Ruebezahl]

Das war meine erste Idee und wenn ich attr global verbose richtig verstanden habe, dann hätte ich in dem genannten Beispiel loglevel für diesen Timer auf >3 setzen müssen, wenn ich attr global verbose 3 gesetzt habe.

Aber wie das so ist, die Idee hat Begehrlichkeiten bei mir erzeugt und ich habe da so einige Ideen, was ich mit Meldungen aus dem Log anfangen könnte, daher habe ich mich mal mit meinen sehr bescheidenen Perlkenntnissen ans Werk gemacht und folgendes in fhem.pl eingebaut:

....
################################################
# the new Log with integrated loglevel checking
sub
Log3($$$)
{
  my ($dev, $loglevel, $text) = @_;

  $dev = $dev->{NAME} if(defined($dev) && ref($dev) eq "HASH");

  if (defined(&Hook_Mainlog))
  {
        $text = Hook_Mainlog($text);
        if ($text eq "")
        {
                return undef;
        }
  }

  if(defined($dev) &&
     defined($attr{$dev}) &&
     defined (my $devlevel = $attr{$dev}{verbose})) {
    return if($loglevel > $devlevel);
.....

Und dann noch ein Modul 99_Hooks.pm geschrieben, in der die Subroutine Hook_Mainlog auf den Text lauert und dann dementsprechend etwas anstellt,
respektive den Text für das oben genannte Beispiel einfach auf leer setzt oder auch unverändert zurück gibt. Das kann Hook_Mainlog ganz nach Wunsch machen.
Also läuft derzeit bei mir so und ich bin zufrieden.
Hook_Mainlog in 99_Hooks.pm bei mir filtert Meldungen aus und schickt bestimmte Meldungen an andere Rechner, weitere Ideen sind in Arbeit.


Vielleicht kann sich einer der Entwickler ja mal erbarmen, das zu überdenken und einzubauen??

Vielleicht wäre das mit den Hooks auch an anderer Stelle in fhem.pl eine Idee, dem Benutzer mehr Möglichkeiten zur Beeinflussung zu geben.
Mir ist aber auch klar, das dadurch im Wartungsbereich für die Kernroutinen einige Probleme entstehen können, wenn Benutzer Fehler melden, die durch Hooks verursacht werden, aber so nicht im Log beim Debug ersichtlich sind.
Da müsste man sicher ein zentrales Hook-Management einbauen, das zumindestens den Debug-Bereich abdeckt....und was weiß ich noch alles.


Viele Grüße,
Rübe

[JoWiemann]

Das war meine erste Idee und wenn ich attr global verbose richtig verstanden habe, dann hätte ich in dem genannten Beispiel loglevel für diesen Timer auf >3 setzen müssen, wenn ich attr global verbose 3 gesetzt habe.

Hm, in der Commandref steht:

•verbose
Setzt den Schwellwert für die Logfile-Meldungen. Mögliche Werte sind:
◦0 - Server start/stop
◦1 - Fehlermeldungen oder unbekannte Pakete
◦2 - bedeutende Ereigbisse/Alarme.
◦3 - ausgesendete Kommandos werden gelogged.
◦4 - von den einzelnen Geräten empfangene Daten.
◦5 - Fehlersuche.
Der für die global Instanz gesetzte Wert gilt als Voreinstellung für die Instanzen, die dieses Attribut nicht gesetzt haben.

Das heisst, hat ein Device ein eigenes attr verbose, dann gilt dieses und nur dieses.

Grüße Jörg

PS: Die Möglichkeit von Hooks halste ich trotzdem  für interessant. Die Frage ist nur, wo überall?

[gero]

Mit ist der Einsatzzweck für solche Hooks noch nicht klar. Kannst du ein konkretes Beispiel geben?
Alles worauf man programmtechnisch reagieren will, kann und sollte meiner Meinung nach über die vorhandenen fhem Mechanismen wie z.B. notify erledigt werden.
Falls du in solchen Hooks wirklich ein Pattern Matching auf Log-Meldungen machst, dürfte ja kein Modulautor seine Log-Nachrichten verändern ohne dies zu dokumentieren, habe ich das richtig verstanden?

Gruß,
Gero

[Ruebezahl]

Ein Hook ist ja per Definition eine Art Schnittstelle, mit der fremder Programmcode in eine bestehende Anwendung eingebunden werden kann. Warum macht man so etwas? Weil Bedarf dafür da ist, etwas in einer Umgebung anders zu machen.
Zum Beispiel, so auf die Schnelle, wenn ich vor/nach dem Rereadcfg noch etwas Spezielles machen möchte, oder bevor ein Save noch mal spezielle Backups haben will(gut, das könnte ich auch mit Bordmitteln lösen). Dann wäre es schön, wenn an den bestimmten Stellen im Code die Möglichkeit dazu bestehen würde, seine Ideen, die vielleicht nicht per Standardcommands lösbar sind, zu verwirklichen.  Über das WO ÜBERALL lässt sich auch sicher trefflich streiten, da wird jeder wieder eigene Vorstellungen haben, was strategisch wichtig ist. Da ist jeder sicher sein eigener König, aber kann er mit den passenden Hooks ja auch sein.

Zu dem Problem der Meldungen und dem Pattern Matching, und dies ist meine ureigenste Meinung und ich will da auch niemanden auf dem Schlips treten.....in einem so stark modularen System wie es z.B. FHEM ist, gehört schon aus Gründen der Wartbarkeit vor Meldungen ein Identifier, woher denn die Meldung kommt, also z.B. HMExxxx yyyyyyyyyyyyy steht halt für Meldungen aus dem Homematic Modul. Nun ist es sicher nicht sehr banal FHEM jetzt noch daraufhin zu tunen, aber für so ein Pattern Matching wäre es sicher ein echter Pluspunkt und in einem Debugfall sicherlich auch eine Hilfe. Aber wie gesagt, meine Meinung und ich will damit jetzt auch keine Grundsatzdiskussion  darüber lostreten.
Und um auf das Pattern Matching zurück zu kommen und einem Anwendungsbeispiel: Ich habe eine ganz spezielle Anwendung für meine Steuerung der Jalousie und die lässt sich leider, leider auch bei allerbestem Wille nicht mit FHEM-Kommandos lösen, also muss ich zu externem Coding greifen. Da wäre (und in meinem Fall   ist) es ja schön, wenn ich aus dem Log die dementsprechende Meldung extrahieren kann und damit auf einem anderen Rechner etwas bewirke, weil ich mittels IP die Meldung weiterschicken kann.

[gero]

Sieh die mal cmdalias in der commandref an.

Zum Triggern auf Log Meldungen:
Falls es wirklich wichtige Systemzustände gibt, bei denen kein event getriggert wird, solltest du dich an den zuständigen Modulautor wenden, damit daran etwas geändert wird.
Das Reagieren auf Log Meldungen halte ich nicht für zielführend.

Gruß,
Gero