Hallo Rudi,
ich muss nochmal auf unsere Diskussion zurückkommen, da der letzte Thread schon geschlossen ist, kann ich da nix mehr schreiben.
ZitatSonst werden die gesammelten Fehlermeldungen nicht - wie vorgesehen - angezeigt.
Ansonsten habe ich den Positiv- wie den Negativfall sowohl mit fhem.cfg als auch mit configDB erfolgreich getestet.
Zitat von: Rudi@betateilchen: Bug ist das sicher keins, hoechstens unpraktisch. Ich weise bereits in der Meldung darauf hin, dass die Details in der Log zu finden sind, wenn ich die Fehler auch ausgebe, dann kann ich den Hinweis sparen. Ich finde es so "ordentlicher", aber das ist sicher Ansichtssache.
Ich wußte, dass in dieser Argumentation ein Denkfehler steckt, aber ich konnte nicht sofort beschreiben, welcher das ist. Heute kann ich das genau beschreiben :)
Der ausschlaggebende Punkt für den vorgeschlagenen Patch war eine defekte 92_FileLog.pm die dazu führte, dass sämtliche Filelog-Definitionen verschwanden, wenn der Anwender versehentlich ein "save config" durchführt, bevor er den Fehler bemerkt.
Deine Argumentation mit "Details sind im Log zu finden" ist grundsätzlich richtig, mit Ausnahme genau dieses Fehlerfalls. Denn dann wird in fhem gar keine Option mehr angeboten, sich das Logfile anzeigen zu lassen, weil auch das Standardlog auf 92_FileLog.pm basiert.
Und genau deswegen würde es durchaus Sinn machen, die eigentliche Fehlermeldung ebenfalls in motd auszuzgeben und nicht nur den Hinweis, dass es irgendwelche Fehler gab.
Du hast Recht, ich habe es eingebaut und eingecheckt.
Beim Testen ist mir aufgefallen, dass das Aufzaehlen aller bekannter Module in der Fehlermeldung (falls man sich beim Modulnamen vertippt hat) eher nervt als hilft, deswegen habe ich die Aufzaehlung entfernt.
Hallo Rudi,
auf vielfachen Wunsch eines einzelnen Forummitglieds (http://forum.fhem.de/index.php/topic,22409.msg158733.html#msg158733) schlage ich noch folgende zwei Patches vor:
Index: commandref_frame.html
===================================================================
--- commandref_frame.html (Revision 5520)
+++ commandref_frame.html (Arbeitskopie)
@@ -1231,7 +1231,8 @@
Message Of The Day. Displayed on the homescreen of the FHEMWEB package,
or directly after the telnet logon, before displaying the fhem> prompt.
SecurityCheck is setting motd if it is not defined upon startup, to
- avoid this set the motd value to none
+ avoid this set the motd value to none.
+ motd is used to show collected error messages upon fhem start, too.
</li><br>
<a name="mseclog"></a>
Index: commandref_frame_DE.html
===================================================================
--- commandref_frame_DE.html (Revision 5520)
+++ commandref_frame_DE.html (Arbeitskopie)
@@ -1295,7 +1295,8 @@
Nachricht des Tages. Wird im Begrüßungsbildschirm von FHEM angezeigt,
oder direkt beim Start einer "telnet" Sitzung, bevor der fhem> Prompt
erscheint. Der SecurityCheck setzt motd wenn es bisher nicht gesetzt ist. Um
- das zu verhindern, können sie den Wert von motd auf "none" setzen
+ das zu verhindern, können sie den Wert von motd auf "none" setzen.
+ motd wird auch verwendet, um Fehlermeldungen während des fhem-Starts zu sammeln und anzuzeigen.
</li><br>
<a name="mseclog"></a>
Noch ein Vorschlag, um die Wogen in der an anderer Stelle aufgekommen Diskussion zu beruhigen...
Es gibt offenbar Leute, die das motd - aus welchen Gründen auch immer generell nicht haben wollen. Man könnte durch zwei klitzekleine Änderungen dafür sorgen, dass die Fehlermeldung nur ausgegeben wird, falls das Attribut "motd" überhaupt existiert.
Zitat
if($cfgRet) {
$attr{global}{motd} = "$cfgErrMsg\n$cfgRet" if($attr{global}{motd});
Log 1, $cfgRet;
} elsif($attr{global}{motd} && $attr{global}{motd} =~ m/^$cfgErrMsg/) {
$attr{global}{motd} = "none";
}
Mit dem kompletten Löschen des Attributes würde dann die Verantwortung für die Fehlererkennung und -behandlung wieder komplett auf Userseite liegen - aber er muss das eben selbst so wollen.
Wir werden es sicher noch schaffen, alle Seiten zu beruhigen :P
motd habe ich eingefuehrt, um den Benutzer auf die fehlenden Passworter hinzuweisen, und mich von Vorwuerfen der Art "FHEM ist ein riesen Sicherheitsloch" zu entlasten. Falls der Benutzer das ignorieren will, dann muss er selbst auf "none" setzten, das will ich niemals automatisch vom System setzen.
Mit der aktuellen Loesung bin ich zwar auch nicht zufrieden (nach einem gesetzten "none" und "kaputtgespeicherten" fhem.cfg tauchen die Passwort-Warnungen wieder auf), aber das ist mir deutlich lieber, als die Warnung automatisch zu unterdruecken. Auf Existenz der Variable zu pruefen ist auch nicht perfekt, weil sie in der Anfangskonfiguration gar nicht auftaucht.
Ich habe den leisen Verdacht, dass um alle zufriedenzustellen wir hier um zwei Attribute nicht herumkommen, auch wenn mir das eher unlieb ist.
Doku-Aenderung habe ich eingecheckt.
Zitat von: rudolfkoenig am 15 April 2014, 11:58:41
Ich habe den leisen Verdacht, dass um alle zufriedenzustellen wir hier um zwei Attribute nicht herumkommen, auch wenn mir das eher unlieb ist.
Den Verdacht habe ich auch, und ich finde das auch nicht wirklich schön.
Aber ich hab im Moment auch keine große Lust mehr, mich dafür von allen Seiten hauen zu lassen, weil ich einen Vorschlag gemacht hatte, der in Problemfällen helfen sollte, und nun zwei oder drei Leute nicht fähig sind, ihr System so zu konfigurieren, dass keine Fehler auftreten und diese Änderung jetzt als großes Übel vorschieben. Meiner Meinung nach ist eine Mehrzahl von Anwendern mit der jetzigen Lösung sehr glücklich.
Zitat von: betateilchen am 15 April 2014, 12:24:19
Den Verdacht habe ich auch, und ich finde das auch nicht wirklich schön.
Aber ich hab im Moment auch keine große Lust mehr, mich dafür von allen Seiten hauen zu lassen, weil ich einen Vorschlag gemacht hatte, der in Problemfällen helfen sollte, und nun zwei oder drei Leute nicht fähig sind, ihr System so zu konfigurieren, dass keine Fehler auftreten und diese Änderung jetzt als großes Übel vorschieben. Meiner Meinung nach ist eine Mehrzahl von Anwendern mit der jetzigen Lösung sehr glücklich.
Deine Meinung in Ehren, aber allein die Tatsache, dass nicht noch mehr "draufhauen" und sich gleichfalls nicht mehr Leute verbal auf Deine Seite schlagen beweist nicht, dass diese "User Bevormundung" eine gute Idee war.
Um weitere Diskussionen zu dem Thema und erheblichen Anpassungsaufwand zu vermeiden - traut Euch einfach, diese Funktion wieder
komplett zu
entfernen. Bei mir läuft FHEM zwar noch nicht so lange (2011), aber diese Funktion stellt mMn. gegenüber all den super programmierten Modulen keinerlei Gewinn dar. FHEM ist prima modular aufgebaut, jeder kann entscheiden was er davon nutzt und was nicht - so sollte es auch bleiben! Systeme, die den User bevormunden und einschränken gibt es mehr aus genug.
@det.: kannst Du bitte mit einem Beispiel erklaeren, warum Du das als Bevormundung empfindest?
Im Normalfall sollten solche Fehler nicht auftauchen (bei mir ist das seit Jahren nicht passiert), und wenn es bei jemanden doch passiert, dann sollte man es fixen, jedenfalls ist das mein Standpunkt.
Was manche Leute so als Bevormundung empfinden. Ich sehe diese Funktion, auch für einen erfahrenen Anwender, als hilfreich an. Ich sehe auch das Problem nicht wirklich. Die Fehler fixen und die Seite ist wieder blank.
Zitat von: rudolfkoenig am 15 April 2014, 14:30:10
@det.: kannst Du bitte mit einem Beispiel erklaeren, warum Du das als Bevormundung empfindest?
Im Normalfall sollten solche Fehler nicht auftauchen (bei mir ist das seit Jahren nicht passiert), und wenn es bei jemanden doch passiert, dann sollte man es fixen, jedenfalls ist das mein Standpunkt.
Hallo Rudolf,
schau mal bitte hier und in den folgenden Posts: http://forum.fhem.de/index.php/topic,10033.msg156713.html#msg156713
Das SONOS Modul von Reinerlein läuft super und macht genau was es soll - bis betateilchen diese unabstellbare Meldung programmieren musste. Die Zeile im LOG hat da früher nicht gestört und FHEM auch in keinerlei Weise beeinträchtigt. Wenn ich aber nach jedem update + shutdown restart erst motd "Error messages while initializing FHEM:configfile: 00statefile: Reading Sonos_Wohnzimmer->LastActionResult must not be used out of statefile.Reading Sonos_Wohnzimmer->presence must not be used out of statefile." in "none" ändern muß, empfinde ich das schon als Bevormundung - sorry -. Vorschlag, wer unbedingt eine "Fehler- finde - und - melde - Routine" haben will, dann sollte das in einem Modul erfolgen, welches man laden kann oder eben auch nicht. Das in FHEMWEB reinzupacken ist nicht modular und gehört da mMn. nicht hin.
ZitatReading Sonos_Wohnzimmer->LastActionResult must not be used out of statefile.
Reading Sonos_Wohnzimmer->presence must not be used out of statefile
"must not" klingt fuer mich nach Fehler, was entweder der Benutzer nicht ignorieren, oder der Modulentwickler fixen sollte. Und wenn es irrelevant ist, dann kann es vom Modul per Log3 protokolliert werden, und sollte nicht beim Aufruf der Funktion (SetStateFn?) zurueckgeliefert werden. Aber in diesem Fall sollte es deutlicher als "info und kein Fehler" markiert werden.
-> das ist fuer mich noch kein Argument fuer Bevormundung.
P.S.: wo findet man dieses Modul? Ich habe ein paar Seiten des verlinkten Threads durchgeschaut, ohne Erfolg.
Zitat von: det. am 15 April 2014, 14:52:20bis betateilchen diese unabstellbare Meldung programmieren musste.
Ich habe die Meldung nicht programmiert - und müssen schon gar nicht.
Zitat von: det. am 15 April 2014, 14:52:20
Das SONOS Modul von Reinerlein läuft super und macht genau was es soll
Nein, das tut es nicht, zumindest nicht entwicklungstechnisch. Sonst würde diese Fehlermeldung nicht in motd wandern. Diese Meldung wird schlichtweg FALSCH ausgegeben.
Zitat von: rudolfkoenig am 15 April 2014, 15:11:14
"must not" klingt fuer mich nach Fehler, was entweder der Benutzer nicht ignorieren, oder der Modulentwickler fixen sollte.
Das ist doch genau meine Rede - es ist im SONOS Modul falsch umgesetzt.
Zitat von: rudolfkoenig am 15 April 2014, 15:11:14
P.S.: wo findet man dieses Modul?
Das bekommst Du - wenn ich es richtig verstanden habe - nur über den thirdparty-Updateprozess.
update thirdparty http://fhem.lmsoft.de/sonos sonos
Zitat von: rudolfkoenig am 15 April 2014, 15:11:14
"
-> das ist fuer mich noch kein Argument fuer Bevormundung.
P.S.: wo findet man dieses Modul? Ich habe ein paar Seiten des verlinkten Threads durchgeschaut, ohne Erfolg.
hier: http://www.fhemwiki.de/wiki/Sonos_Anwendungsbeispiel
-> das ich das nach jedem update händisch löschen muß, ist schon eine Bevormundung! So was in der Geschäftssoftware unserer Firma und ich würde vergessen die monatlichen Wartungskostenrechnungen zu unterzeichnen - dauerhaft - und nach Alternativen schauen.
Ich kann erhrlich nicht verstehen, das es so schwer fällt, eine unglückliche Entscheidung wieder zu revidieren.
Zitat von: det. am 15 April 2014, 15:34:50
Ich kann erhrlich nicht verstehen, das es so schwer fällt, eine unglückliche Entscheidung wieder zu revidieren.
Nein. Du verstehst nicht, das fhem.pl nicht das Problem ist, sondern das fehlerhafte SONOS Modul.
Ich kann jedenfalls keine "unglückliche Entscheidung" erkennen. Die getroffene Entscheidung deckt die Unzulänglichkeit des SONOS Moduls auf, mehr nicht.
Es zeugt schon von unglaublicher Ignoranz, den Fehler in einem Modul auf eine Lösung zu schieben, die genau auf diesen Fehler aufmerksam macht.
Wenn ich es richtig verstehe, das Modul (00_SONOS.pm) will manche Readings aus fhem.state nicht uebernehmen, da diese immer neu initialisiert werden muessen. Eine Loesung waere diese Werte nicht als Reading sondern als Internal anzulegen, dann werden diese Werte nicht gespeichert.
Wir koennen auch darueber reden, dem StateFn eine Fehlermeldungsfreie-Vetomoeglichkeit einzuraeumen, wenn der Timestamp bei diesen Werten essentiell ist. Dem Benutzer Fehlermeldungen (selbst nur im Log) anzuzeigen, wo kein Fehler vorliegt, ist keine Loesung, sonst nimmt Fehlermeldungen niemand mehr ernst.
Wenn jemand solche Fehlermeldungen wirklich ignorieren will, der kann es mit
define ignoreMotd notify global:INITIALIZED attr global motd none
weiterhin tun.
Zitat von: rudolfkoenig am 15 April 2014, 15:55:46
Wenn jemand solche Fehlermeldungen wirklich ignorieren will, der kann es mit
define ignoreMotd notify global:INITIALIZED attr global motd none
weiterhin tun.
Danke!!! - mein Problem mit der Meldung ist damit gelöst - genau so was hatte ich gesucht - hail to the King!
Puh schwere Geburt, dennoch ein schöner Kompromiss! Glückwunsch ich liebe dieses Forum!
Ich denke bei dieser Diskussion aktuell an die Außenwirkung, ich habe auch meine eigene Meinung zum Sachverhat und möchte auch kein Salz in die eine der andere Wunde streuen, weshalb ich mich enthalte, und bin nach mehr als 2 Jahren FHEM konsterniert (nachdenklich) über diese Diskussion.
dann hättest Du Deinen Beitrag auch einfach weglassen können, wenn Du eh nix zu sagen hast 8)
Naja, ehrlich gesagt bin ich immer für das auflösen der Kausalität! Dennoch glaube ich, dass Betateilchen (und viele andere natürlich auch) hier eine Menge Zeit investieren und im wesentlichen nur das beste für FHEM erreichen wollen. Alle kann man auf diesem Weg nicht "immer" glücklich machen. Wichtig ist das Ergebnis und das ist, zumindest für meinen Eindruck, erzielt worden.
Zitat von: betateilchen am 15 April 2014, 21:45:06
dann hättest Du Deinen Beitrag auch einfach weglassen können, wenn Du eh nix zu sagen hast 8)
genau das meine ich