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

Begonnen von rudolfkoenig, 18 August 2013, 16:39:25

Vorheriges Thema - Nächstes Thema

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
Log 4, "Device $dev opened";
wird
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

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

55_GDS, 71_LISTENLIVE, 98_openweathermap = erledigt
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

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
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

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
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

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
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

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

Zitat von: rudolfkoenig schrieb am Mo, 19 August 2013 07:43>  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
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

TeeVau

FHEM 5.8 dev (virtualisiert) / FBF 7390 (CUL 868MHz V 1.51 / panStick (AVR1))
FS20: fs20di,fs20pira,fs20sm8,fs20st2,fs20tfk,fs20ue1,fs20ws1
panStamp (AVR1): RGB Multi von ext23, 1W-DSxxxx, I/O Sketch, Spritzpumpe
Multimedia: Panasonic TV (VIERA), Kodi, Yamaha RX-V781, LMS
Sonstiges: XiaomiFlowerSen

Tobias

Maintainer: Text2Speech, TrashCal, MediaList

Meine Projekte: https://github.com/tobiasfaust
* PumpControl v2: allround Bewässerungssteuerung mit ESP und FHEM
* Ein Modbus RS485 zu MQTT Gateway für SolarWechselrichter

Markus Bloch

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

aktives Mitglied des FHEM e.V. (Technik)

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.

Zitat von: rudolfkoenig schrieb am Di, 20 August 2013 09:12Nein. 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
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

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:
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?
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

rudolfkoenig

> verbose-Änderung beispielsweise des Devices CUL_0 oder TRX_0 zwar das Parsing geloggt wird

Nicht ganz richtig. Es wird nur dann das IODev herangezogen, wenn es keinem in FHEM definierten zugeordnet werden kann, dieser Fall wird also vermutlich fuer genau eine Zeile pro Modul (Unknown FHT device XXX, usw). verantwortlich sein. Sonst ist immer das gefundene/definierte (FHT) Geraet massgebend.

Dr. Boris Neubert

Erledigt für

00_CM11.pm
02_HTTPSRV.pm
02_RSS.pm
09_BS.pm
09_USF1000.pm
10_OWServer.pm
11_OWDevice.pm
20_X10.pm
57_Calendar.pm
59_Weather.pm
80_M232.pm
81_M232Counter.pm
82_M232Voltage.pm

Grüße
Boris
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

justme1968

hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

ntruchsess

while (!asleep()) {sheep++};