Moin !
Ich habe einen Eltako Windsensor an einem AVR NetIO. Da ich FHEM die
Impulse (zumindest nicht unter Nutzung von ECMD) nicht mit watchasync
schicken kann, zähle ich ich die Impulse direkt mit einem C6 Skript
auf dem NetIO. Um Böen zeitnah mitzubekommen polle ich die gezählten
Werte recht häufig. Da hierzu der Scheduler die Kommandos mit "fhem"
aufruft, werden diese bei verbose 3 natürlich immer brav gelogged.
Dies möchte ich eigentlich nicht. Mit dem loglevel auf Device Ebene
habe ich bereits rumgespielt - leider ohne Erfolg. Derzeit habe ich
nun den global verbose Wert auf 2 runter gesetzt. Dadurch gehen mir aber
Informationen von anderen Devices verloren, die sehen möchte. Gibt es
einen Weg, die "set/get" Meldungen bei global verbose 3 gezielt für
einzelne Devices zu unterdrücken ?
Danke & Gruß, Marc
> Mit dem loglevel auf Device Ebene habe ich bereits rumgespielt - leider ohne Erfolg.
loglevel ist eigentlich der richtige Weg, erfordert aber den expliciten Support durch den Modulentwickler.
Wenn es nicht funktioniert, bitte den Modulentwickler (siehe MAINTAINER.txt) nerven, evtl direkt mit einem Patch. :)
Also bei mir funktioniert u. a.
attr Gerätename loglevel 6
Da kommt dann nix, im Eventlog sieht man es dann aber noch.
Wie geschrieben das haengt vom Modul ab.
Loglevel 6 hatte ich probiert, bringt bei einem
ECMDDevice aber scheinbar nichts, die "gets" landen
leider trotzdem jedes mal im log. Werde mal einen
Blick in 67_ECMDDevice.pm werfen.
Gruß, Marc
Hallo,
Zitat von Rudi:
ZitatWie geschrieben das haengt vom Modul ab.
Zitaterfordert aber den expliciten Support durch den Modulentwickler.
Zitat Ende
Sprich: Wenn der Modulautor diese Funktion in seinem Modul nicht implementiert hat klappt das auch nicht.
Grüße
Hi !
Hatte übrigens nichts mit dem Modul zu tun. Ich frage die Daten des Windsensors
aus einen Perl Routine in meinem 99_myUtils.pl ab und nutze daher entsprechend
die fhem Routine. Letztere schreibt grundsätzlich mit Level 3 ins Log, es sei denn
man übergibt einen zweiten Parameter $silent. War mir neu. Konnte den Hinweis in
der Doku auch nicht auf Anhieb finden. Anyway, jetzt funktioniert es wie
gewünscht.
Was ich hingegen nicht weg bekomme ist die "After sleep" Meldung im Log. Auch
hier ist der Loglevel in fhem.pl hart verdrahtet (Level 2). Leider sind an dieser
Stelle keine Informationen über das betroffene Device mehr verfügbar. GetLoglevel
geht also nicht. Vielleicht könnte man daher auch "sleep" einen zweiten Parameter
$silent übergeben, oder ein globales Attribut spendieren ?
Gruß, Marc
> Was ich hingegen nicht weg bekomme ist die "After sleep" Meldung im Log
Kommt deswegen, weil die Befehle nach dem sleep diesen Text/Fehler zurueckliefern.
Kannst Du bitte konkret zeigen was schiefgeht?
Hallo Rudolf,
der Schedule sieht wie folgt aus:
+*00:05 set Windsensor 1w_measure;; sleep 2;; get Windsensor 1w_temp
Hier die Auszüge aus der zugehörigen ECMD Class:
get 1w_temp cmd {"1w get 1020e98c02080096"}
set 1w_measure cmd {"1w convert"}
set 1w_measure postproc {s/^OK$/success/; "$_" eq "success" ? "ok" : "error";}
Das "1w get 1020e98c02080096" liefert gewollter Maßen einen Wert (Text) zurück, der
von WakeUpFn wie folgt protokolliert wird:
2013.07.24 23:28:17 2: After sleep: 1w_temp 23.7
2013.07.24 23:33:18 2: After sleep: 1w_temp 23.8
2013.07.24 23:38:17 2: After sleep: 1w_temp 23.5
2013.07.24 23:43:17 2: After sleep: 1w_temp 23.7
Gruß, Marc
sleep hat jetzt einen optionalen Parameter quiet bekommen.
Bin nicht ganz gluecklich damit, da es nicht intuitiv ist.
Ist aus meiner Sicht nicht mehr und auch nicht weniger intuitiv wie der Parameter silent
in der fhem Routine. Funktionieren tut es auf jeden Fall prima. Vielen Dank
hierfür !
Gruß, Marc
Zitat von: rudolfkoenig schrieb am Sa, 20 Juli 2013 10:10loglevel ist eigentlich der richtige Weg, erfordert aber den expliciten Support durch den Modulentwickler.
Hallo Rudolf,
Ich habe das in meinen Modulen bisher so implementiert, dass der loglevel (sofern gesetzt) direkt im aufruf von 'Log' benutzt wird, was aber zur Folge hat, dass bei gesetztem loglevel modulweit mit dem gleichen Loglevel geloggt (oder je nach verbose-level eben auch nicht) geloggt wird. (Ähnlich habe ich das auch in fremden Modulen gesehen). Damit bin ich aber nicht so recht glücklich - sinnvoller wäre es, wenn der modulspezifische loglevel eigentlich die Funktion eines modulspezifischen 'verbose-levels' hätte.
gibt's eigentlich irgendwo eine Seite die beschreibt, welche Semantic der Modulspezifische loglevel haben soll? Sowas wie 'Best Practice' ist?
Gruß,
Norbert
Artige Module sollten sowas wie
my $l3 = GetLogLevel($name,3);
Log $l3, "Text"
verwenden, das gilt dann pro definierte Instanz, und nicht Modulweit.
Die beabsichtigten Werte sind hier: http://fhem.de/commandref.html#verbose (//fhem.de/commandref.html#verbose) dokumentiert.
so habe ich das in meinen Modulen auch implementiert. Was mir daran nicht gefällt:
setzt man keinen loglevel, dann loggen alle Stellen im Modul mit dem Level, den man an der Stelle als Sinnvoll erachtet hat. Mit Verbose kann man dann einstellen, welchen Detailierungsgrad man sehen will.
setzt man den loglevel, dann loggen alle Stellen im Modul (für diese Instanz) mit dem gleichen Loglevel. Je nach Wert von 'verbose' sieht man dann alle Logausgaben der Modulinstanz oder gar keine, da ja zwischen den Logausgaben nicht mehr differenziert wird.
Irgendwie sollte sich das doch besser so verhalten, als ob man den Verbosity-level pro Modul-instanz einstellen würde. Also z.B. global verbose auf 3 und per loglevel 4 im Modul dafür sorgen, dass trotz verbose 3 auch die Stellen mit loglevel 4 gelogged werden.
Gruß
> Irgendwie sollte sich das doch besser so verhalten, als ob man den Verbosity-level pro Modul-instanz einstellen würde. Also z.B. global verbose auf 3 und per loglevel 4 im Modul dafür sorgen, dass trotz verbose 3 auch die Stellen mit loglevel 4 gelogged werden.
Entweder verstehe ich dich nicht, oder es ist schon so.
Es gibt mAn drei Einstellungen:
- loglevel nicht gesetzt: es wird so geloggt, wie der Modulautor das vorgesehen hat, idealerweise so, wie im commandref.html#verbose beschrieben ist.
- loglevel <= verbose: es werden alle Meldungen ausgegeben, die diese Instanz generieren kann. Gedacht fuer den Fall, dass ich ein bestimmtes Geraet debuggen will, der Rest soll leise weiterlaufen
- loglevel > verbose: diese Instanz soll keine Meldungen generieren. Gedacht fuer den Fall, dass ich mit den Entscheidungen des Modulautors nicht einverstanden bin, und ich nichts von dieser FHEM-Instanz hoeren will.
Genau so verhalten sich meine Module beim loggen. Man kann mit dem Loglevel entweder das logging komplett unterbinden, oder aber (ausnahmslos) alles loggen (und das ist dann meistens eher mehr als man sehen will). Wenn man nur für eine einzelne Modulinstanz einstellen möchte, dass etwas mehr (aber eben nicht alles) geloggt wird, dann geht das halt so nicht. Ich dachte halt, ich übersehe da was und frage erst mal nach...
Ich kann ja mal eine entsprechende Logfunktion implementieren mit der man das genauer steuern kann und hier vorstellen, dann hätten alle was davon...
Gruß,
Norbert
Hier auf Github habe ich mal abgelegt (//github.com/ntruchsess/fhem-mirror/blob/logging/fhem/fhem.pl#L581), wie ich mir das vorstelle. Rudolf, Was hälst Du davon?
Gruß,
Norbert
Viel, ich habe es als Log3 (wg. den 3 Parametern) uebernommen, und es in fhem.pl/00_CUL.pm/DevIo.pm/10_FS20.pm eingebaut. Falls keine Groesseren Widerstaende folgen, dann werde ich es in allen von mir gepflegten Modulen uebernehmen.
Folgendes sollte einem bewusst sein:
Fuer Module die schon Log3 nutzen gilt: das vom Benutzer gesetzte loglevel Attribut muss (analog zu verbose) auf einem grossen Wert (> 4) gesetzt sein, damit man debugausgaben sieht.
Fuer Module die noch GetLogLevel verwenden, muss dieses Attribut auf kleine Werte (< verbose) gesetzt sein.
Das ist zwar doof, habe aber keine Idee, wie man es besser machen koennte.
Falls jemanden etwas auffaellt, bitte melden.
Zitat von: rudolfkoenig schrieb am Sa, 10 August 2013 10:47Falls jemanden etwas auffaellt, bitte melden.
*meld*
Ich habe Log3 in 55_GDS eingebaut,
Log3($name, 3, "GDS $name: Decoding CAP record #".$datensatz);dabei ist mir aufgefallen, dass nun ein Attribut loglevel im device vorhanden sein MUSS, damit etwas geloggt wird. Vorher mit GetLogLevel und dem defaultwert war das irgendwie flexibler, da ging das auch ohne vorhandenes Attribut.
Vielleicht habe ich aber auch noch irgendetwas falsch verstanden?
Falls Attribut vorhanden ist, dann wird es beruecksichtigt, sonst verhaelt sich die Funktion wie das alte Log. Den Unterschied zum loggen mit GetLogLevel habe ich weiter oben erlaeutert, was anderes gibt es nicht.
Ich lass mich aber mit konkreten Beispielen ueberzeugen.
Zitat von: rudolfkoenig schrieb am Sa, 10 August 2013 14:23Ich lass mich aber mit konkreten Beispielen ueberzeugen.
Ich kapier einfach die Logik nicht.
In meinem Coding steht testweise:
my $llevel = GetLogLevel($name,3);
Log 1, "GetLogLevel liefert: $llevel";
Log $llevel, "(GLL) GDS $name: retrieving $dir".$dwd." from DWD server";
Log3($name, 3, "(Log3)GDS $name: retrieving $dir".$dwd." from DWD server");
Fall 1: gds hat kein Attribut loglevel:
2013.08.10 15:07:28 1: GetLogLevel liefert: 3
2013.08.10 15:07:28 3: (GLL) GDS gds: retrieving gds/specials/observations/tables/germany/* from DWD server
2013.08.10 15:07:28 3: (Log3)GDS gds: retrieving gds/specials/observations/tables/germany/* from DWD server
Fall 2: gds hat Attribut loglevel = 3
2013.08.10 15:08:19 1: GetLogLevel liefert: 3
2013.08.10 15:08:19 3: (GLL) GDS gds: retrieving gds/specials/observations/tables/germany/* from DWD server
2013.08.10 15:08:19 3: (Log3)GDS gds: retrieving gds/specials/observations/tables/germany/* from DWD server
Fall 3: gds hat Attribut loglevel = 2
2013.08.10 15:09:10 1: GetLogLevel liefert: 2
2013.08.10 15:09:10 2: (GLL) GDS gds: retrieving gds/specials/observations/tables/germany/* from DWD server
Fall 4: gds hat Attribut loglevel 4
2013.08.10 15:10:09 1: GetLogLevel liefert: 4
2013.08.10 15:10:09 3: (Log3)GDS gds: retrieving gds/specials/observations/tables/germany/* from DWD server
> Ich kapier einfach die Logik nicht.
Vermutlich hast Du meine Bemerkung ("Folgendes sollte einem bewusst sein:") nicht gelesen.
doch hab ich. Die Logik ist genau umgekehrt wie vorher. Hilft mir trotzdem nicht weiter. Naja, ich werde einfach mal drüber schlafen, vielleicht kommt mir eine Eingebung.
die logik ist nur auf den ersten Blick umgekehrt, man muss aufs Detail schauen:
- Bisher musste bei gesetztem loglevel-attribut selbiges kleiner als verbose sein, damit etwas geloggt wurde, der vom Modulentwickler an dieser Stelle vorgesehene Loglevel wurde dann ignoriert und durch den Wert des Loglevel-attributs ersetzt.
- Im Log3 wird bei gesetztem Loglevel-attribute der als Aufrufparameter übergebene Wert mit dem loglevel-attribut verglichen, dafür wird verbose ignoriert. Im Log erscheint als loglevel der vom Modulautor an dieser Stelle vorgesehene Wert.
- bei nicht gesetztem Loglevel-attribute ist das Verhalten gleich.
Gruß,
Norbert