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?
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
Global symbol "$re" requires explicit package name at ./FHEM/92_FileLog.pm line 60.
Was mach ich nun? Soll ich trotzdem weiter installieren?
Eigentlich wollte ich durch die Neuinstallation alle Fehler finden und beseitigen.
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.
... 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.
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
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.
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 :)
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"
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.
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.
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.
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 8)
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.
so sei es...
(http://up.picr.de/17840125sk.png)
Ich schlage folgenden Patch für die fhem.pl vor:
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}) {
Das sieht gut aus.
Ich wollte gar nicht so eine grosse Diskussion auslösen.
Aber mal zum Verständnis:
Ich habe nicht bei einer Fehlerhaften Konfiguration save config geklickt.
Ich habe fhem neu aufgesetzt, alle Updates gemacht, meinen HMLAN eingebunden und fhem auf Root gesetzt. Da war aber die Anzeige und das File noch da.
Nun musste ich save config machen und die komplette Fritzbox neu starten, nicht nur fhem, da sonst die Root umstellung nicht greift.
Erst dann war der Fehler zu bemerken.
Zitat von: Invers am 02 April 2014, 13:05:05
Ich habe fhem neu aufgesetzt,
ok...
Zitat von: Invers am 02 April 2014, 13:05:05
alle Updates gemacht,
auch ok - aber genau das war heute die Ursache für Dein Problem: Die 92_FileLog.pm die Du heute morgen per Update bekommen hast war fehlerhaft.
Zitat von: Invers am 02 April 2014, 13:05:05
Da war aber die Anzeige und das File noch da.
auch logisch, denn ein Update wirkt sich auf bereits geladene Module erstmal gar nicht aus.
Zitat von: Invers am 02 April 2014, 13:05:05
Nun musste ich save config machen
auch noch ok.
Aber jetzt kommts...
Zitat von: Invers am 02 April 2014, 13:05:05
und die komplette Fritzbox neu starten, nicht nur fhem, ...
Erst dann war der Fehler zu bemerken.
Exakt. Weil beim Neustart dann zum ersten Mal die per Update erhaltene neue Modulversion verwendet wurde,
mit der aber das definierte Logfile nicht angelegt werden konnte. Deshalb war dann im Frontend nichts mehr zu sehen.
Solange Du in einem solchen Fall
nicht nochmal auf save config klickst, passiert gar nichts Schlimmes.
Die gespeicherte Konfiguration(-sdatei) wird durch den Fehler nicht automatisch verändert.
Beim nächsten fhem-Start würde also wieder versucht, die gespeicherte FileLog-Definition auszuführen.
Genau.
Wollte nur demonstrieren, dss ich halt nicht leichtfertig gehandelt hatte.
Ausserdem wäre die Datei kein Verlust, da zu diesem Zeitpunkt ja fast noch leer. :-)
kannst Du mal bitte in Deinem ersten Beitrag den Titel korrigieren? Das f in Eintrafung macht mich irre :P
Aber gerne doch. Hab auch gleich das doppelte "fehlt" entfernt. War vielleicht ein wenig aufgeregt. :-)