Eintragung "Logfile" fehlt im Menü nach Neuinstallation

Invers · 02 April 2014, 08:30:58

Naja, Habe meine Fritzbox und FHEM neu aufgesetzt. Nun will ich ins Logfile gucken (alle Updates sind erledigt) und sehe den Eintrag im Menü nicht mehr. Vor dem Restart war er aber da.
Das Problem müssten ja nun theoretisch alle haben, die neu aufsetzen? Was kann ich tun, damit ich über die Oberfläche von FHEM wieder an mein Logfile komme?

marvin78 · 02 April 2014, 08:34:27

Kann ich bestätigen und auch aus der Config ist alles, was das Log betrifft verschwunden. Das Modul FileLog kann nicht mehr geladen werden.

Auch ein reload führt nicht zum Ziel

Code Auswählen



Global symbol "$re" requires explicit package name at ./FHEM/92_FileLog.pm line 60.

Invers · 02 April 2014, 08:39:33

Was mach ich nun? Soll ich trotzdem weiter installieren?
Eigentlich wollte ich durch die Neuinstallation alle Fehler finden und beseitigen.

marvin78 · 02 April 2014, 08:41:53

Als Workaround kannst du die Zeile 60 in 92_FileLog.pm einfach auskommentieren. Dort wird eine Variable verwenden, welche nicht korrekt initialisiert wurde. wichtig für die Funktionalität ist die Zeile aber nicht.

marvin78 · 02 April 2014, 08:46:00

... aber hier haben wir wieder das Problem, dass Devices, die nicht korrekt funktionieren, nicht einfach verschwinden sollten, was sie zumindest nach einem save config tun.

Klaus Rubik · 02 April 2014, 09:22:30

Sollte mit erneutem Update Erledigt sein, ggf. vorher noch den letzten Backup wieder einspielen.

siehe auch http://forum.fhem.de/index.php/topic,22094.0.html

Invers · 02 April 2014, 09:26:55

Vielen Dank, auskommentieren hat funktioniert.

Backup nutzen? Genau das will ich ja gerade nicht, da ich neu aufgesetzt habe. Ich will ja alles neu machen.

Klaus Rubik · 02 April 2014, 09:36:12

Zitat von: Invers am 02 April 2014, 09:26:55
Backup nutzen? Genau das will ich ja gerade nicht, da ich neu aufgesetzt habe. Ich will ja alles neu machen.

Ok, ich dachte nur, dass du bereits einige FileLogs definiert hattest. Ansonsten Update ohne Backup

betateilchen · 02 April 2014, 10:22:35

Zitat von: marvin78 am 02 April 2014, 08:46:00
... aber hier haben wir wieder das Problem, dass Devices, die nicht korrekt funktionieren, nicht einfach verschwinden sollten, was sie zumindest nach einem save config tun.

Hier haben wir eher wieder das Problem, dass die User nicht genug mitdenken. Denn wenn ich nach dem Start feststelle, dass ich eine Konfiguration habe, in der etwas nicht stimmt, dann mache ich einfach KEIN "save config"

marvin78 · 02 April 2014, 10:28:34

Das ist MIR klar. Aber ich bin auch jemand der das "über den Tellerand" denken täglich beruflich macht. Das kann man nicht von jedem Anwender verlangen. Das ist auch etwas, was man mit der Erfahrung in so einem Job lernt.

Zudem merkt man so etwas, wie das fehlende Log, unter Umständen gar nicht sofort, weil die Fehler nicht offensichtlich sind und evtl. erst auffallen, wenn man sich das Log ansehen möchte.

Es gibt genügend Szenarios, in denen ein Anwender zu spät merken kann, das etwas fehlt. Also entweder muss man deutlich darauf aufmerksam gemacht werden (nervende Fehlermeldung, wie ein Popup oder ähnliches), dass etwas nicht stimmt (fehlendes Log bspw.), es darf nicht gelöscht werden oder beides. Das ist und bleibt mein Standpunkt. Sorry, aber das hier ist kein Problem, welches man auf den Anwender abwälzen kann. Nicht jeder kann dieses Verständnis für die Umgebung haben.

betateilchen · 02 April 2014, 10:57:17

Zitat von: marvin78 am 02 April 2014, 10:28:34es darf nicht gelöscht werden

Nochmal: es wird nicht aktiv gelöscht. Es wird einfach nicht angelegt. Beim "save config" wird immer die aktuell im Speicher gehaltene Konfiguration gesichert, völlig unabhängig, wie diese Konfiguration beim Systemstart aussah. Und da das Logfile in diesem Fall einfach nicht im Speicher vorhanden ist, kann es logischerweise auch nicht mitgesichert werden.

Übrigens: das war genau einer der Gründe für mich, die Konfigurationslösung mit der SQL Datenbank als Ersatz für die Konfig-Datei zu schaffen. Dort werden nämlich keine Konfigurationen gelöscht, sondern jeweils als neue Version angelegt. Und selbstverständlich gibt es die Möglichkeit, eine vorherige Version wieder zu aktivieren.

Man könnte eventuell darüber nachdenken, den Startvorgang selbst zu kontrollieren und eine Info auf die erste Seite im Frontend schreiben, wenn man sich zum ersten Mal dorthin verbindet. Vielleicht könnte man dazu sogar einfach das Attribut "motd" verwenden. Es wäre ja schon ausreichend, einen Hinweis wie "Error on loading fhem. Please check configuration." zu bekommen.

marvin78 · 02 April 2014, 11:05:01

Ich weiß, was da passiert und ich weiß, dass es nicht gelöscht wird. Deine Erklärung war für mich schon beim ersten mal nicht nötig. Trotzdem ist der Effekt in vielen Fällen, als wäre es gelöscht weil man es unter Umständen nicht rechtzeitig bemerkt. Und das wird auch jeder User, der sich nicht näher damit befassen kann/will, so sehen. Das darf, weil es ein ernsthaftes Problem ist, nicht ohne Hinweis geschehen. Gerade in der Anfangsphase experimentiert der User doch viel herum und speichert dann evtl. auch voreilig mal die config, weil er es nicht vergessen will o.ä..

Die Kontrolle des Startvorgangs mit Hinweis auf der Startseite ist eine gute und Hilfreiche Idee, ich bin und bleibe trotzdem der Meinung, dass dieses "nicht anlegen" falsch ist. Ich habe verstanden warum, das so ist und auch warum es passiert, aber das macht es nicht richtig.

betateilchen · 02 April 2014, 11:06:33

Zitat von: marvin78 am 02 April 2014, 11:05:01
Gerade in der Anfangsphase experimentiert der User doch viel herum und speichert dann evtl. auch voreilig mal die config, weil er es nicht vergessen will o.ä..

Aus Schaden wird man klug. Man sollte den Lerneffekt durch dieses Verhalten nicht unterschätzen

marvin78 · 02 April 2014, 11:12:30

Da sind wir uns sogar einig. Aber Benutzerfreundlichkeit kann auch nicht schaden.

Nochmal: Ich brauche diese Hinweise nicht, weil ich (meistens) weiß, was ich tue. Aber in meiner Tätigkeit habe ich täglich mit Anwendern von Software zu tun und ich weiß, wie wichtig aussagekräftige Fehlermeldungen für den Erfolg einer Software sind. Für mich ist FHEM fast optimal, wie es ist, weil ich mir vieles selbst hin"zaubern" kann. Das hier ist, meiner Ansicht nach für den Durchschnittuser, jedoch ein so schwerwiegendes Problem, dass man nicht einfach sagen kann "sei eben vorsichtig". Zumal er ja gar nicht wissen kann, worauf er achten muss.

betateilchen · 02 April 2014, 11:27:00

so sei es...

(http://up.picr.de/17840125sk.png)

Ich schlage folgenden Patch für die fhem.pl vor:

Code Auswählen



Index: fhem.pl
===================================================================
--- fhem.pl	(Revision 5411)
+++ fhem.pl	(Arbeitskopie)
@@ -435,10 +435,14 @@
 
 if($attr{global}{configfile} eq 'configDB') {
   my $ret = cfgDB_ReadAll(undef);
+  $attr{global}{motd} .= "\n\nError on loading fhem. Check your configuration!\n".
+                         "Set global attr motd to none to confirm and delete this message."  if($ret);
   Log 1, "configDB: $ret" if($ret);
 
 } else {
   my $ret = CommandInclude(undef, $attr{global}{configfile});
+  $attr{global}{motd} .= "\n\nError on loading fhem. Check your configuration!\n".
+                         "Set global attr motd to none to confirm and delete this message."  if($ret);
   Log 1, "configfile: $ret" if($ret);
 
   if($attr{global}{statefile} && -r $attr{global}{statefile}) {