Umstellung von Log auf Log3 bzw. Ersetzung von loglevel durch verbose

[rudolfkoenig]

Durch Einfuehrung von Log3 sind die Inkonsistenzen der loglevel und verbose Logik deutlich geworden, und ich habe einen Vorschlag von Mattias implementiert:

- logfile ist ab sofort unerwuenscht (deprecated), damit auch GetLogLevel.
- Die Module sollten loglevel aus der Liste der angebotenen Attribute und aus der Doku entfernen, und statt Log die neue Funktion Log3 aufrufen.
- Das neue Attribut verbose muss weder in AttrList angegeben noch dokumentiert werden, da es global zur Verfuegung steht, mit der gleichen Semantik wie bisher bei global: grosse Werte bedeuten viel Log, kleine wenig Log, moeglich ist 0-5
- In allen Modulen sollte Log durch Log3 ersetzt werden: der einen zusaetzlichen ersten Parameter benoetigt: entweder $hash oder $name. Also aus

Code Auswählen Erweitern

Log 4, "Device $dev opened";
wird

Code Auswählen Erweitern

Log3 $name, 4, "Device $dev opened";

- Die 3 in Log3 steht fuer den Anzahl der Parameter (3 :).
- Falls man kein Geraet ($name/$hash) hat, dann kann man auch undef verwenden, dann wird es mit "global verbose" verglichen. In den XXX_Parse Funktionen verwendet man $iohash oder $iohash->{NAME}, solange das eigentliche Geraet noch nicht identifiziert wurde, danach wie ueblich $hash/$name.
- Log funktioniert weiterhin, und wird durch "Log3 undef, ..." implementiert, sollte aber nur noch von fhem.pl oder Enduser verwendet werden.

Ich habe alle von mir betreuten Module (51 an der Zahl) auf Log3 umgestellt, es waere nett, wenn alle Modulautoren das zuegig nachziehen wuerden, damit die Benutzer eine eindeutige Semantik vorfinden.

[betateilchen]

- Die Module sollten loglevel aus der Liste der angebotenen Attribute und aus der Doku entfernen,

55_GDS, 71_LISTENLIVE, 98_openweathermap = erledigt

[Markus Bloch]

Für die Module YAMAHA_AVR, FB_CALLMONITOR und PRESENCE ist die Umstellung bereits erfolgt, nur das Attribut "loglevel" inkl. Doku habe ich noch nicht gestrichen.

Kurze Frage:

Bedeutet dies, dass ich mit Log3 das Loglevel nur noch Systemweit mit "global verbose" beeinflussen kann? Ich habe meine Module auf Log3 umgestellt und konnte einzelne Definitionen mit "attr <name> loglevel 5" (vorher 2) dann gesprächiger machen.

Wenn das Attribut loglevel aber gestrichen werden soll, hätte ich diese Möglichkeit nicht mehr, sondern müsste das globale Loglevel via verbose hochdrehen?

Gruß
Markus

[rudolfkoenig]

> müsste das globale Loglevel via verbose hochdrehen?

Nein, alle Geraete haben ein verbose Attribut (genauso wie room, comment, etc), wenn man diesen hochdreht (und im Modul Log3 verwendet wird) dann kriegt man fuer dieses Geraet passend mehr. Frueher konnte man mit loglevel nur alles auf einmal fuer ein Geraet freischalten, jetzt geht es auch pro Geraet stufenweise.

[Markus Bloch]

Hab soeben ein Update gemacht, jetzt habe ich das Attribut "verbose" auch.

Alles klar, dann änder ich meine Module noch ab und dann ist alles fertig (zumindest aus meiner Sicht).

Gruß
Markus

[Willi]

Änderung finde ich grundsätzlich gut. Ich habe es bisher noch nie geschafft das Logging pro Modul zu beeinflussen....

Das werde ich bei mir nach Änderung bei meinen Modulen (RFXCOM, TRX, USBWDE1, ..) erst mal austesten, bevor ich es ins SVN packe. Kann also ein paar Tage dauern. Wenn ich es recht verstehe, ist der Leidensdruck gering, da ja Log so wie bisher (also global) funktioniert. Oder gibt es Grund zur Eile?

Verstehe ich richtig, dass man beim Logging sich für das Logging abhängig vom verbose beim Modul oder Gerät entscheiden muss?
Was macht man, wenn man das Logging für ein Modul hochdrehen will, ohne für alle Geräte verbose zu ändern.
Schön wäre, wenn man beides angeben könnte (evtl. als regex z.B. "($modulname|$devicename)" ).
Oder habe ich da etwas falsch verstanden?

Wenn ich es falsch verstanden habe, wären ein paar Beispiele für das neue verbose schön.
 
-- Willi

[rudolfkoenig]

>  Oder gibt es Grund zur Eile?

Nicht wirklich.

>  Oder habe ich da etwas falsch verstanden?

Ja. Modulabhaengige Parameter gibts es (noch?) keine, nur Geraeteabhaengige.

[Willi]

>  Oder gibt es Grund zur Eile?

Nicht wirklich.

>  Oder habe ich da etwas falsch verstanden?

Ja. Modulabhaengige Parameter gibts es (noch?) keine, nur Geraeteabhaengige.

Ok. Dann hatte ich das doch falsch verstanden. Ich habe mir gerade auch mal fhem.pl angesehen.

Bedeutet also, dass man verbose beispielsweise nur für das device CUL_0 setzen kann und dann in allen davon genutzten Untermodulen wie CUL_WS, CUL_HM, FS20, CUL_MAX, HMS, etc ... damit das Logging eingeschaltet wird?

Bei meinen TRX-Modulen würde das bedeuten, dass man verbose auf dem TRX-Device setzt und damit das Logging aller abhängigen Module wie TRX_WEATHER, TRX_SECURITY, TRX_LIGHT und TRX_ELSE gesetzt wird.

Bedeutet also, man kann beispielsweise nicht für CUL_HM das Logging separat das Logging einstellen, wenn man HM mit CUL nutzt.

Richtig?

-- Willi

[TeeVau]

70_VIERA.pm ist auf Log3 geändert und eingechecked

[Tobias]

für 93_DbLog.pm angepasst und engechecked

[Markus Bloch]

YAMAHA, PRESENCE und CALLMONITOR sind ebenfalls fertig.

[rudolfkoenig]

> Bedeutet also, dass man verbose beispielsweise nur für das device CUL_0 setzen kann und dann in allen davon genutzten Untermodulen wie CUL_WS, CUL_HM, FS20, CUL_MAX, HMS, etc ... damit das Logging eingeschaltet wird?

Nein. Man kann weiterhin nur fuer eine Instanz (ueber die Instanz-Eigene verbose) oder fuer alle (wie bisher ueber global verbose) das logging aendern, und nicht fuer alle Elemente eines Moduls und schon gar nicht fuer eine Nachricht, und den kompletten Verarbeitungsweg.

Dafuer aber kann man fuer eine Instanz das verbose feiner einstellen, bisher konnte man mit loglevel (fuer eine Instanz) nur alles oder nichts schalten.

[Willi]

Habe die RFXtrx433-Module (TRX, TRX_LIGHT, TRX_SECURITY_ TRX_WEATHER, TRX_ELSE) soeben mit Log3 ins SVN eingeckt.
98_dewpoint.pm habe ich noch auf meiner Liste.

Bin mir unsicher, ob es sich bei den anderen von mir supporteten Modulen (alter RFXCOM-Receiver, USBWX) lohnt die Änderung durchzuführen. Ich weiss zwar, dass diese noch genutzt werden, aber ansonsten habe ich den Zustand eingefroren, da die Geräte keine neue Firmware mehr vom Hersteller bekommen.

Ich würde die Änderung durchführen, wenn Du darauf bestehst. Einen wirklichen Nutzen außer Aufwand für die Umstellung und Test sehe ich aber nicht.

Nein. Man kann weiterhin nur fuer eine Instanz (ueber die Instanz-Eigene verbose) oder fuer alle (wie bisher ueber global verbose) das logging aendern, und nicht fuer alle Elemente eines Moduls und schon gar nicht fuer eine Nachricht, und den kompletten Verarbeitungsweg.

Scheint nicht ganz zu stimmen.

Ich habe gesehen, dass Du beispielsweise bei 11_FHT.pm bei FHT_Set nicht abhängig vom $hash, sondern von $name loggst.
Das habe ich bei mir im 46_TRX_LIGHT.pm jetzt auch gemacht und ausprobiert.

Bedeutet in diesem Fall beim set, dass man das Logging nicht abhängig vom verbose des Devicenamen (also TRX_0 oder CUL_0) erfolgt, sondern vom verbose des Gerätes, also FHT_1761 bzw. TRX_X10_A0 erfolgt. Hier ist ja $name nicht gleich $iohash->{NAME}.

Gefällt mir aber eigentlich so gut.

Andererseits sollten wir uns einigen, ob das so gewollt ist.

Grüße

Willi

[rudolfkoenig]

>  Ich habe gesehen, dass Du beispielsweise bei 11_FHT.pm bei FHT_Set nicht abhängig vom $hash, sondern von $name loggst.

Log3 kann man sowohl mit $hash oder $name (== $hash->{NAME}) als erstes Argument aufrufen, beides wird akzeptiert.

In FHT_Parse wird Log3 mit $hash der iodev aufgerufen, falls das Modul dem Nachricht keine definierte FHEM-FHT-Instanz zuordnen konnte. Wenn eine FHT-Instanz gefunden wurde, dann natuerlich mit dem Namen dieser Instanz. Darauf zielte meine Bemerkung von oben:

Code Auswählen Erweitern

In den XXX_Parse Funktionen verwendet man $iohash oder $iohash->{NAME}.

[Willi]

Die Frage ist jetzt, ob wir für das Logging eine Konvention festlegen wollen, was passiert, wenn man verbose auf einem Device hochdreht. Bei den derzeitigen Änderungen der meisten Module ist es so, dass bei verbose-Änderung beispielsweise des Devices CUL_0 oder TRX_0 zwar das Parsing geloggt wird, aber kein Logging beim Set erfolgt. Dies erfolgt erst dann, wenn man verbose beim entsprechenden Gerät, z.B. FHT_4711 setzt. Das muss man als Anwender erst mal wissen.

Wollen wir das so? Oder soll das jeder Modulauthor so festlegen wie er will?