Eigenes Log erstellen

Begonnen von Sidey, 22 November 2017, 21:16:06

Vorheriges Thema - Nächstes Thema

Sidey

Hi,

Ich und einige Anwender würde gerne ein eigenes Log aus einem Modul schreiben.

Im Groben habe ich da zwei Möglichkeiten gesehen:

1. Ich hau alles als Events raus, was das System wohl deutlich belasten dürfte und ein FileLog speichert es in eine Datei.

2. Ich schreibe es direkt aus dem Modul in eine Datei.


Die 1. Variante würde mit FHEM Bordmitteln auskommen, gefällt mir aber nicht so sehr. Bei der 2. Variante müsste ich wohl etliches selbst erstellen wie z.B. Logfile anzeigen, archivieren, alte Logs löschen.
Oder liege ich hier falsch?

Würde mich über Kommentare freuen.

Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

rudolfkoenig

Warum moechtest du was Separates?

Events belasten ein System nicht unbedingt stark, nur dann, wenn NOTIFYDEV in vielen Geraeten nicht gesetzt ist:
{ join("\n", grep { $modules{$defs{$_}{TYPE}}{NotifyFn} && !$defs{$_}{NOTIFYDEV} } sort keys %defs) }


Alternativ definierst du ein FileLog, und rufst (mit einem Wrapper?) FileLog_Log($$) direkt auf.

Sidey

Hallo Rudolf,

Ich denke Du meinst, dass die Belastung hoch ist, wenn NOTIFYDEV in vielen Geraeten nicht gesetzt ist.

Das eigene Log deshalb, da dort alle empfangenen Daten rein sollen die der SIGNALduino empfängt.
Bis ich das mal mit den Events und dem Log3 verstanden hatte, habe ich mich auch immer gewundert, wieso ich die Daten nicht in ein separate log bekomme.

Das geht halt heute noch einigen Anwendern so, dass sie die Daten nicht im FHEM Log haben möchten.


Die Idee, ein Filelog zu definieren und dann einfach FileLog_LOG aufrufen gefällt mir schon ganz gut.
Da muss ich nicht so viel machen :)

Danke für den Tip.

Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Markus Bloch

#3
Einige Module die eine NotifyFn besitzen, haben NOTIFYDEV nicht definiert, weil:

- zum Zeitpunkt der Erstellung/Aktualisierung eines Moduls NOTIFYDEV nicht verfügbar war
- falls NOTIFYDEV schon verfügbar, nur einen einzelnen Definitionsnamen zu diesem Zeitpunkt unterstützte
- notifyRegexpChanged nicht bekannt ist

Mittlerweile unterstützt NOTIFYDEV die Angabe von devspec und ist daher sehr einfach nutzbar um z.B. nur Events von CUL_HM-Definitionen und "global" zu erhalten: TYPE=CUL_HM,global
Leider sind die entsprechenden Module nie aktualisiert worden, weswegen NOTIFYDEV hier nicht genutzt wird um die Event-Last in FHEM zu minimieren.

Zitat von: Sidey am 22 November 2017, 21:59:44
Ich denke Du meinst, dass die Belastung hoch ist, wenn NOTIFYDEV in vielen Geraeten nicht gesetzt ist.

Nein, so wie es Rudi dargelegt hat ist das schon richtig. Die ganzen NOTIFYDEV-Expressions werden nur einmal geprüft und anschließend ein Mapping-Hash angelegt woran FHEM sofort weis, welche Events an welche einzelnen Definitionen getriggert werden müssen. Es werden also nicht sämtliche NOTIFYDEV-Expressions bei jedem Event neu evaluiert. Natürlich wird bei strukturverändernden Vorgängen die Mappingtabelle geleert und neu aufgebaut.

Gruß
Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

betateilchen

Die Idee, ein Log direkt aus einem Modul heraus befüllen zu wollen, finde ich ziemlich haarsträubend.

Warum hält man sich nicht an ,,übliche" Vorgehensweisen, die auch dann noch verständlich sind (und bleiben) wenn man den Inhalt einer Moduldatei und ihr Verhalten auswendig kennt?

Was durch solche unüberlegten Sonderlocken An Problemen auftreten kann, haben wir doch erst kürzlich bei der inflationären und oft völlig sinnlosen Nutzung von CommandSave() erlebt.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Sidey

Hallo Betateilchen,


Ich war auch lange Zeit der Meinung, ich implementiere das nicht.

Das Problem ist meiner Meinung nach in der Trennung zwischen Event und Log verankert.

Der normale Anwender versteht überhaupt nicht, wieso er nicht durch ein FileLog die Nachrichten eines Moduls in ein eigenes Log schicken kann. Stattdessen soll er im globalen Logfile von FHEM nachsehen.
Das versteht man erst, wenn man den Unterschied zwischen Event, Log und Systemlast verstanden hat.
Aber auch dann findet man es nicht gut.

Vielleicht mache ich auch etwas grundlegendes falsch in meinem Modul.
Ich schicke halt Daten in das Log die für FHEM selbst nicht relevant sind, für den Anwender aber sein können.
Das können durchaus sehr viele Meldungen sein (Abhängig vom Verbose Level).

Deshalb hatte ich diesen Threads eröffnet um das ganze zu diskutieren.

Das mit den Events und Notify habe ich verstanden. So wie ich das einschätze, bräuchte man etliche Patches für Module, damit Events ressourcenschonend verarbeitet werden können.

Grundlegend müsste es doch so sein, dass z.B.  die NotifyFN die API für andere Module darstellt. Steht so zwar nirgendwo, aber das würde ich jetzt so interpretieren.
Wenn wir das so annehmen, dann sollte nichts dagegen sprechen, diese Funktion direkt aus einem anderen Modul aufzurufen.

Bliebe dann nur noch commandDefMod übrig, was vermutlich nicht gedacht war, um aus FHEM Modulen verwendet zu werden.

Viel mehr brauche ich glaube ich nicht zu nutzen, um in ein eigenes FileLog zu schreiben.

Basteln verstehe ich dann in soweit, da ich keine Events in das FileLog schreibe, die in FHEM irgendwo auftauchen. Da stimmt ich dir zu. Das könnte Anwender wieder verwirren.

Grüße Sidey

Gesendet von meinem XT1650 mit Tapatalk

Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

herrmannj

Was genau möchtest du den in dem log finden ?

Vg
Joerg

Sidey

In das Log sollen die Daten vom Signalduino IO Device, welches an FHEM übertragen wird.

Um dort neue Protokolle implementieren zu können ist es hilfreich die Meldungen wegschreiben zu können.

Zusätzlich sollen noch ein paar Daten zur Verarbeitung in das Log, damit man Problemstellen leicht identifizieren kann.

Grüße Sidey

Gesendet von meinem XT1650 mit Tapatalk

Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

herrmannj

im Prinzip also ein temporäres debug log ?

Variante 1, also das erzeugen von events und ein dazugehöriges filelog scheinen mir schon passend.

Die Formulierung "was das System wohl deutlich belasten dürfte" ist etwas irreführend.

Events sind ein zentraler Bestandteil von FHEM und die FHEM routinen, die sich um deren Verarbeitung kümmern, sind in der Regel optimiert. Natürlich können einzelne Module und/oder Usercode unterwegs sein die sich ungeschickt verhalten. Da überwiegt jedoch in meinen Augen der Vorteil des getesteten und standardisierten (dokumentierten) Verhaltens der event Routinen.

Du könntest doch, wenn das log nur bei Bedarf erstellt werden soll, Deinen code so gestalten das events (zum loggen) über einen Schalter (attribut?) an- und abgeschaltet werden können.


Sidey

Also gut, ich habe das ganze nun erprobt und auch auf einem Testystem laufen lassen.

Die Variante Filelog aus dem Modul erstellen und dann direkt in das Filelog schreiben habe ich versucht.
Allerdings ist das doch mehr gebastel als ich zuerst angenommen hatte.

Ich habe dann die Variante mit den Events implementiert und erst mal alles was geloggt wird auch als Event ausgelöst.
Da kommen einige Events zusammen.

Ich will nicht behaupten, dass Events keine Belastung für das System darstellen, aber im Vergleich zu meiner Read Funktion ist das erst mal vernachlässigbar:


name                                     function                               max  count    total  average maxDly TS Max call     param Max call
Logfile                                  FileLog_Log                             30 410819   398059     0.97      0 25.11. 12:58:36 HASH(Logfile);
sduino                                   SIGNALduino_Read                      4656  44285  8088208   182.64      0 25.11. 12:17:03 HASH(sduino)
SIGNALduino_FL                           FileLog_Log                             35 406099   826210     2.03      0 25.11. 21:12:51 HASH(SIGNALduino_FL); HASH(sduino)
sduino                                   SIGNALduino_Notify                      21      6      122    20.33      0 25.11. 04:18:51 HASH(sduino); HASH(global)



Also die Beschreibung im Wiki ist da etwas irreführend finde ich, bezüglich der Belastung.
Was der FHEM Prozess selbst an Zeit verbraucht habe ich so nun halt nicht gemessen.

Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker