Seit Update vom 19.02.2013 kaum noch Einträge im Filelog

[ArminK]

Hallo habe gestern Abend ein Update durchgeführt. Die Version ist:
version Fhem 5.3 (DEVELOPMENT), $Id: fhem.pl 2752 2013-02-17 13:55:05Z rudolfkoenig $, pid 13767
Seit dem anschließenden shutdown restart habe ich kaum noch Einträge im Logfile. Z.B. von meinen Bewegungsmeldern im Treppenhaus, das Licht wird allerdings fhem-mässig getriggert, auch die device-abhängigen Logfiles werden erstellt. Kann mir jemand sagen warum das so ist?

Grüße aus Heidelberg
Armin

[rudolfkoenig]

Boris hat am Sonntag die "FS20 set devName cmd" Meldungen auf loglevel 4 gesetzt, von ehemalig 2. Ich habe es heute wieder auf 3 korrigiert, damit es mit http://fhem.de/commandref.html#verbose im Einklang ist, vorallem aber weil ich gerne haette, dass Anfaenger die Schaltbefehle aus notify/at im Log nachpruefen koennen. Fortgeschrittene koennen das Logging in der aktuellen Version mit "attr TYPE=FS20 loglevel 2" erzwingen.

[ArminK]

Hallo Rudolf,
das nenn' ich prompt! Vielen Dank für die Info! Dachte schon es liegt mal wieder an meiner Inkompetenz!

[Dr. Boris Neubert]

Hallo habe gestern Abend ein Update durchgeführt. Die Version ist:
version Fhem 5.3 (DEVELOPMENT), $Id: fhem.pl 2752 2013-02-17 13:55:05Z rudolfkoenig $, pid 13767
Seit dem anschließenden shutdown restart habe ich kaum noch Einträge im Logfile. Z.B. von meinen Bewegungsmeldern im Treppenhaus, das Licht wird allerdings fhem-mässig getriggert, auch die device-abhängigen Logfiles werden erstellt.

Hallo Armin,

beinhaltet Deine Nachfrage auch den Appell, die Einträge im Log sehen zu wollen? Falls ja, warum? Ich hatte es umgestellt, weil ich im globalen Log bei Loglevel 3 nur Auffälligkeiten sehen möchte und nicht normale Reaktionen. Mich interessiert Deine Meinung dazu.

Viele Grüße
Boris

[det.]

Hallo Boris,

genau so fände ich es prima - wenn im LOG eigentlich fast nichts stehen würde - mit Ausnahme der Sachen, die nicht sauber programmiert sind und zwar laufen, aber Fehlermeldungen erzeugen. Die wirklich schlimmen Module bringen FHEM leider sowieso ohne LOG Eintrag zu Absturz.

[Jörg]

Ist auch das Logverhalten von Dummys geändert worden?

Früher bekam ein set dummy on einen Logeintrag, jetzt aber leider nicht mehr.
Auch ein attr TYPE=dummy loglevel 2 hat daran nichts geändert. Oder geht das anders?

[Dr. Boris Neubert]

Ist auch das Logverhalten von Dummys geändert worden?

Ja. Denjenigen, die viel mit Dummys arbeiten, um damit bspw. virtuelle Zähler u.ä. zu realisieren, wurde bisher das globale Log vollgemüllt.

Was spricht gegen

define myGlobalLog FileLog path/file.log .*:.*

?

Darin sieht man alle Aktivitäten. Und das globale Log zeigt bei Level 3 nur Auffälligkeiten.

Viele Grüße
Boris

[Jörg]

Ist auch das Logverhalten von Dummys geändert worden?

Ja. Denjenigen, die viel mit Dummys arbeiten, um damit bspw. virtuelle Zähler u.ä. zu realisieren, wurde bisher das globale Log vollgemüllt.

Was spricht gegen

define myGlobalLog FileLog path/file.log .*:.*

?

Darin sieht man alle Aktivitäten. Und das globale Log zeigt bei Level 3 nur Auffälligkeiten.

Hallo Boris,
ich finde, das ist eine Ansichtssache. Um einem Dummy, den ich als Zähler brauche, einen Wert zuzuweisen reicht ein setstate, was nicht im Log aufgelistet wurde. Mit einem set bei einem Dummy, der als virtuelles Device im Frontend aufgelistet ist, wurde es auch (wie es soll) gelogt.

Daher fände ich es schön, wenn man das als Option wieder einschalten könnte.

[Dr. Boris Neubert]

Ist auch das Logverhalten von Dummys geändert worden?

Ja. Denjenigen, die viel mit Dummys arbeiten, um damit bspw. virtuelle Zähler u.ä. zu realisieren, wurde bisher das globale Log vollgemüllt.

Was spricht gegen

define myGlobalLog FileLog path/file.log .*:.*

?

Darin sieht man alle Aktivitäten. Und das globale Log zeigt bei Level 3 nur Auffälligkeiten.

ich finde, das ist eine Ansichtssache. Um einem Dummy, den ich als Zähler brauche, einen Wert zuzuweisen reicht ein setstate, was nicht im Log aufgelistet wurde. Mit einem set bei einem Dummy, der als virtuelles Device im Frontend aufgelistet ist, wurde es auch (wie es soll) gelogt.

Wir haben unterschiedliche Anwendungsfälle im Auge. setstate verwendet nicht den readingsUpdate-Mechanismus und bietet daher nicht alle Möglichkeiten, die ein set bietet.

Nochmal die Frage: warum läßt Du Deinen Dummy nicht in eine extra Datei loggen?

Viele Grüße
Boris

[Jörg]

Wir haben unterschiedliche Anwendungsfälle im Auge. setstate verwendet nicht den readingsUpdate-Mechanismus und bietet daher nicht alle Möglichkeiten, die ein set bietet.

Gut, das akzeptiere ich bedingt. Wäre es denn nicht möglich, dass man dem Dummy ein zusätzliches Attribut wie z.B. attr Dummydevice VirtDevice 1 setzen kann, um FHEM mitzuteilen, dass das Device geloggt werden soll?

Nochmal die Frage: warum läßt Du Deinen Dummy nicht in eine extra Datei loggen?

Ich benutze als Webfrontend PGM3, dass ich mit Martins Einverständnis seit letztem Jahr um viele Punkte, wie Darstellung von HM-Devices uvm. erweitert habe.

Einer der für meine Begriffe Vorteile von PGM3 ist, dass im unteren Bereich immer das Globallog angezeigt wird. Dadurch sehe ich direkt, welches Device wann ein, oder ausgeschaltet worden ist. Was ja auch der primäre Zweck eines Globallogs ist. Ich sehe keinen Sinn darin, nur um zusätzlich auch noch meine Dummydevices sehen zu können, eine zusätzliche Logdatei anlegen zu müssen.

[Jörg]

Hab noch eine Idee:

Wenn ein Dummy eine Raumzuordnung, wie z.B. attr Dummydevice room Wohnzimmer, dann wird gelogt, sonst nicht.

Denn einem virtuellen Zähler braucht man doch keinen Raum zuordnen.

[ArminK]

Hallo Boris,

sorry für die späte Reaktion, war geschäftlich ziemlich unterwegs! Zu Deiner Frage: nein, kein Apell generell finde ich es schon besser wenn im Logfile nur die Einträge auftauchen die Probleme verursachen. Alles andere kann man sich ja zurechtbauen wie man es braucht. Ich habe mich halt nur gewundert...
In diesem Zusammenhang noch eine Anmerkung:
Wäre es nicht möglich nach (oder auch vor) einem Update eine kurze Zusammenfassung anzuzeigen was sich durch das fhem-update alles geändert hat? Das würde glaube ich vielen Usern viel Zeit sparen, weil sie nicht (so wie ich schon einige male) im Dunklen tappen müssten um den vermeintlichen Fehler in der eigenen cfg. zu suchen. Evtl. würde es auch schon helfen die aktuellen Neuerungen in der commandref farbig darzustellen.

Gruß aus Heidelberg
Armin