Hallo zusammen,
ich wollte gerade eine Developer-Version eines Moduls testen, in dieser Version war jedoch noch ein Fehler vorhanden, so dass das Modul nicht geladen werden konnte und nach einem FHEM Neustart folgende Fehlermeldung im Log stand:
2017.10.30 22:00:15.947 1: configfile: Cannot load module xyz
2017.10.30 22:00:24.323 2: Messages collected while initializing FHEM: configfile: Cannot load module xyz
Kann das Modul nicht geladen werden ist ja klar, dass alle Devices dieses Moduls nicht funktionieren, Sie werden in der Weboberfläche dann auch nicht angezeigt.
Musste jedoch feststellen, dass diese Devices samt ihrer kompletten Konfiguration automatisch aus meiner fhem.cfg gelöscht wurden. >:(
Am Zeitstempel der ConfigFile ist zu sehen, das sie nach dem Neustart verändert wurde:
FHEM:~$ stat fhem.cfg
Datei: ,,fhem.cfg"
Größe: 145048 Blöcke: 288 EA Block: 4096 reguläre Datei
Gerät: b302h/45826d Inode: 259371 Verknüpfungen: 1
Zugriff: (0644/-rw-r--r--) Uid: ( 999/ fhem) Gid: ( 20/ dialout)
Zugriff : 2017-10-30 21:38:41.000000000 +0100
Modifiziert: 2017-10-30 22:03:02.084543465 +0100
Geändert : 2017-10-30 22:03:02.084543465 +0100
Nachstellen kann man das verhalten ganz einfach:
-Zeitstempel der ConfigFile auslesen (stat /opt/fhem/fhem.cfg)
-ein genutztes Modul aus dem Modul-Verzeichnis löschen ( rm /opt/fhem/FHEM/XYZ.pm}
-FHEM Neustarten
-Zeitstempel der ConfigFile erneut auslesen (stat /opt/fhem/fhem.cfg)
Kann man dieses verhalten irgendwie deaktivieren?
Ich möchte nicht, dass ohne mein zutun irgendjemand in meiner Konfiguration herumpfuscht.
Grüße Schlimbo
Es ist schon prinzipbedingt, dass wenn ein Modul nicht geladen werden kann auch ein define für das Modul nicht durchläuft und dann natürlich der entsprechende deivce nicht angelegt wird. Wenn dann ein save ausgeführt wird ist der device natürlich auch aus der config verschwunden.
Was mich wundert ist, dass bei Dir während des Neustarts ein save ausgeführt wird. Du solltest mal schauen, was diesen save auslöst. Eigentlich ist das die Ursache des Problems bei Dir.
attr autosave deaktivieren oder Du hast ein notify etc.
Das nicht laden ist jedenfalls nicht die Ursache sondern das danach gespeichert wurde.
Mal ab von der Frage, ob ein potentiell durchgeführtes automatisiertes save Sinn macht (macht es nicht): Ein Wechsel zu configDB könnte -jedenfalls nach meiner Erfahrung - helfen, dann muß man auch nicht bei manuellem Speichern nachsehen, ob nicht irgendwas verloren gegangen ist.
Habe das bisher nirgends ausdrücklich bestätigt erhalten, aber das war das beobachtete Verhalten bei 1-Wire-Devices, wenn Störungen auf dem Bus waren.
Gruß, Beta-User
Zitat von: Schlimbo am 30 Oktober 2017, 23:43:25
Kann man dieses verhalten irgendwie deaktivieren?
Ich möchte nicht, dass ohne mein zutun irgendjemand in meiner Konfiguration herumpfuscht.
Grüße Schlimbo
War die eigentliche Frage welche noch nicht beantwortet wurde.
Extrem ärgerlich bei der Konfig meiner BOSE Lautsprecher das sind rund 130 Zeilen!
Zitat von: kaputt am 31 Oktober 2017, 10:25:37
War die eigentliche Frage welche noch nicht beantwortet wurde.
Extrem ärgerlich bei der Konfig meiner BOSE Lautsprecher das sind rund 130 Zeilen!
Das ist beantwortet.
FHEM speichert nicht automatisch!
Das ist per oben genanntem Attribut im global oder in einem notify/DOIF definiert ...
Gesendet von meinem S3_32 mit Tapatalk
Hi,
seid Ihr Euch da auch ganz, ganz sicher, dass FHEM niemals automatisch speichert? Auf meinem HM-Wired-Entwicklungssystem passiert mir das auch von Zeit zu Zeit, dass die fhem.cfg "kaputtgeht", wenn ich bestimmte Programmierfehler mache. Ich bin dem Effekt bisher nicht nachgegangen, da eine "Reparatur" in dem Fall fast automatisch geht.
Allerdings macht mich der Thread hier etwas stutzig. Vielleicht sollte man das doch ein wenig ernster nehmen.
Gruß,
Thorsten
Zitat von: Thorsten Pferdekaemper am 31 Oktober 2017, 11:00:04
seid Ihr Euch da auch ganz, ganz sicher, dass FHEM niemals automatisch speichert?
Schauen wir doch einfach mal in die FHEM-Moduldateien...
Überall da, wo CommandSave() ohne Prüfung auf das Attribut autosave ausgeführt wird, könnten Dinge passieren, die nicht beabsichtigt sind.
Aufrufe von "fhem("save ...")" habe ich jetzt noch nicht zusätzlich geprüft.
~/Development/svn/fhem/FHEM/10_EnOcean.pm:14189: CommandSave($ctrl, $param);
~/Development/svn/fhem/FHEM/10_EnOcean.pm:15205: CommandSave(undef, undef);
~/Development/svn/fhem/FHEM/10_EnOcean.pm:15208: CommandSave(undef, undef);
~/Development/svn/fhem/FHEM/10_OWServer.pm:441: CommandSave(undef,undef) if( $created && AttrVal($acdname, "autosave", 1 ) );
~/Development/svn/fhem/FHEM/26_tahoma.pm:1011: CommandSave(undef,undef) if( $autocreated && AttrVal( "autocreate", "autosave", 1 ) );
~/Development/svn/fhem/FHEM/30_HUEBridge.pm:349: CommandSave(undef,undef) if( AttrVal( "autocreate", "autosave", 1 ) );
~/Development/svn/fhem/FHEM/30_HUEBridge.pm:388: CommandSave(undef,undef) if( AttrVal( "autocreate", "autosave", 1 ) );
~/Development/svn/fhem/FHEM/30_HUEBridge.pm:557: CommandSave(undef,undef) if( AttrVal( "autocreate", "autosave", 1 ) );
~/Development/svn/fhem/FHEM/30_HUEBridge.pm:941: CommandSave(undef,undef) if( AttrVal( "autocreate", "autosave", 1 ) );
~/Development/svn/fhem/FHEM/30_LIGHTIFY.pm:262: CommandSave(undef,undef) if( AttrVal( "autocreate", "autosave", 1 ) );
~/Development/svn/fhem/FHEM/30_LIGHTIFY.pm:284: CommandSave(undef,undef) if( AttrVal( "autocreate", "autosave", 1 ) );
~/Development/svn/fhem/FHEM/30_LIGHTIFY.pm:789: CommandSave(undef,undef) if( AttrVal( "autocreate", "autosave", 1 ) );
~/Development/svn/fhem/FHEM/30_LIGHTIFY.pm:852: CommandSave(undef,undef) if( AttrVal( "autocreate", "autosave", 1 ) );
~/Development/svn/fhem/FHEM/31_HUEDevice.pm:716: CommandSave(undef,undef) if( AttrVal( "autocreate", "autosave", 1 ) );
~/Development/svn/fhem/FHEM/31_Nello.pm:141: CommandSave(undef, undef);
~/Development/svn/fhem/FHEM/31_Nello.pm:152: CommandSave(undef, undef);
~/Development/svn/fhem/FHEM/31_Nello.pm:355: CommandSave(undef, undef);
~/Development/svn/fhem/FHEM/32_withings.pm:748: CommandSave(undef,undef) if( $autocreated && AttrVal( "autocreate", "autosave", 1 ) );
~/Development/svn/fhem/FHEM/32_withings.pm:824: CommandSave(undef,undef) if( $autocreated && AttrVal( "autocreate", "autosave", 1 ) );
~/Development/svn/fhem/FHEM/34_ESPEasy.pm:943: CommandSave(undef,undef);
~/Development/svn/fhem/FHEM/34_ESPEasy.pm:1350: CommandSave(undef,undef);
~/Development/svn/fhem/FHEM/34_SWAP.pm:1020: CommandSave(undef,undef) if( $first && AttrVal( "autocreate", "autosave", 1 ) );
~/Development/svn/fhem/FHEM/36_LaCrosse.pm:356: CommandSave(undef,undef) if( AttrVal( "autocreate", "autosave", 1 ) );
~/Development/svn/fhem/FHEM/36_PCA301.pm:228: CommandSave(undef,undef) if( AttrVal( "autocreate", "autosave", 1 ) );
~/Development/svn/fhem/FHEM/37_harmony.pm:1441: CommandSave(undef,undef) if( $autocreated && AttrVal( "autocreate", "autosave", 1 ) );
~/Development/svn/fhem/FHEM/37_plex.pm:3577: CommandSave(undef,undef) if( AttrVal( "autocreate", "autosave", 1 ) );
~/Development/svn/fhem/FHEM/37_plex.pm:3622: CommandSave(undef,undef) if( AttrVal( "autocreate", "autosave", 1 ) );
~/Development/svn/fhem/FHEM/38_netatmo.pm:2554: CommandSave(undef,undef) if( $autocreated && AttrVal( "autocreate", "autosave", 1 ) );
~/Development/svn/fhem/FHEM/38_netatmo.pm:2661: CommandSave(undef,undef) if( $autocreated && AttrVal( "autocreate", "autosave", 1 ) );
~/Development/svn/fhem/FHEM/38_netatmo.pm:2727: CommandSave(undef,undef) if( $autocreated && AttrVal( "autocreate", "autosave", 1 ) );
~/Development/svn/fhem/FHEM/38_netatmo.pm:2783: CommandSave(undef,undef) if( $autocreated && AttrVal( "autocreate", "autosave", 1 ) );
~/Development/svn/fhem/FHEM/55_PIFACE.pm:368: CommandSave(undef, undef);
~/Development/svn/fhem/FHEM/55_PIFACE.pm:374: CommandSave(undef, undef);
~/Development/svn/fhem/FHEM/55_PIFACE.pm:386: CommandSave(undef, undef);
~/Development/svn/fhem/FHEM/73_NUKIBridge.pm:565: CommandSave(undef,undef) if( AttrVal( "autocreate", "autosave", 1 ) );
~/Development/svn/fhem/FHEM/88_HMCCU.pm:1506: CommandSave (undef, undef) if ($newcount > 0 && $savedef);
~/Development/svn/fhem/FHEM/88_HMCCU.pm:3880: CommandSave (undef, undef);
~/Development/svn/fhem/FHEM/98_autocreate.pm:381: CommandSave(undef, undef) if(!$ret && $nrcreated &&
~/Development/svn/fhem/FHEM/98_autocreate.pm:622: CommandSave(undef, undef)
~/Development/svn/fhem/FHEM/98_DOIFtools.pm:643: CommandSave(undef,undef);
~/Development/svn/fhem/FHEM/98_DOIFtools.pm:767: $ret .= CommandSave(undef,undef) if (AttrVal($pn,"DOIFtoolsExecuteSave",""));
~/Development/svn/fhem/FHEM/98_DOIFtools.pm:831: $ret .= CommandSave(undef,undef) if (AttrVal($pn,"DOIFtoolsExecuteSave",""));
~/Development/svn/fhem/FHEM/98_DOIFtools.pm:1074: CommandSave(undef,undef);
~/Development/svn/fhem/FHEM/98_DOIFtools.pm:1105: CommandSave(undef, undef);
~/Development/svn/fhem/FHEM/98_DOIFtools.pm:1112: CommandSave(undef, undef);
~/Development/svn/fhem/FHEM/98_DOIFtools.pm:1354: $ret = CommandSave(undef,undef) if (AttrVal($pn,"DOIFtoolsExecuteSave",""));
~/Development/svn/fhem/FHEM/98_DOIFtools.pm:1516: $ret .= CommandSave(undef,undef) if (AttrVal($pn,"DOIFtoolsExecuteSave",""));
deja-vu: https://forum.fhem.de/index.php/topic,39985.0.html
Zitatseid Ihr Euch da auch ganz, ganz sicher, dass FHEM niemals automatisch speichert?
a: fhem speichert unter den beschriebenen Bedingungen automatisch (by design)
b: kann niemand ausschließen das einzelne modulautoren weitere Funktionen dazu "interpretiert" haben.
ZitatExtrem ärgerlich bei der Konfig meiner BOSE Lautsprecher das sind rund 130 Zeilen!
Wer da keine Backup Strategie hat ist selber schuld.
Von den genannten habe ich mir mal kurz die angeschaut, die ich in Verwendung habe:
Zitat34_ESPEasy
98_autocreate.pm
(sind nur die beiden :o) und die sind, soweit ich das sehe kann sauber, das Attribut für autosave wird überprüft.
Zitat von: betateilchen am 31 Oktober 2017, 11:30:26
Schauen wir doch einfach mal in die FHEM-Moduldateien...
Ein simples grep ist wohl eher ungeeignet dazu...
Würde es Sinn machen, einen Befehl "CommandAutoSave" (oder ähnlich) zu haben, welches die Abfrage von dem autosave-Attribut kapselt? Dann müsste sich nicht jedes Modul selbst darum kümmern.
Warum soll ein Modul überhaupt ein "save" machen dürfen? Ich bin bisher davon ausgegangen, dass so etwas nicht "erlaubt" ist.
Was soll das überhaupt? Meiner Meinung nach hat KEIN Modul (nicht einmal autocreate) jemals an der fhem.cfg herumzufummeln.
Gruß,
Thorsten
Ich habe die Module mit CommandSave angeschaut, da mich die Verwendung in dieser Zahl ueberrascht hat:
- die meisten machen das, wenn sie selbst neue Geraete angelegt haben. Vermutlich war das einfacher, als sich mit dem autocreate Mechanismus auseinanderzusetzen, was ich wiederum schade finde.
- Es gibt auch Faelle, wenn CommandSave nach einem readingsUpdate aufgerufen wird, vermutlich war dem Autor die Funktion WriteStateFile unbekannt.
- manchmal wird vorher das Attribut "global autosave", manchmal "autocreate autosave" und manchmal "TYPE=autocreate autosave" abgefragt. Manchmal aber nicht.
- DOIFtools ist am eifrigsten: wenn definiert, dann wird CommandSave direkt nach dem FHEM-Start, nach global:INITIALIZED ( ??? ) ausgefuehrt.
Das dumme an dem CommandSave ist (vs. AnalyzeCommand(undef, "save") ), dass man es nicht mal mit einem cmdalias umbiegen kann. Angesichts der Meldungen hier und den uebertriebenen Einsatz von CommandSave in den verschiendenen Modulen habe ich vor
- eine automatische Sicherung ala "update" in CommandSave einzubauen, d.h. im restoreDir, zu restaurieren mit restore, wie gewohnt.
- in ComandSave die "global autosave" Option zu pruefen, falls $cl nicht definiert ist (d.h. wenn es nicht wg. Benutzerinteraktion aufgerufen wurde). Achtung: das verhindert ein speichern auch per notify, wenn das Attribut gesetzt ist.
Hat irgendwer Einwaende oder andere Vorschlaege?
Keine Einwände, aber ....... das ändert nichts daran das Konfigurationen gelöscht werden wenn Module nicht vorhanden sind.
In Verbindung mit "kein editieren der fhem.cfg" muss ich dann meine Definitionen per Webinterface/Telnet rein kloppen.
Könnte man/frau nicht vor dem löschen Fragen? "Kein Modul für Definition XY, löschen ja/nein/vielleicht?"
Zitatdas ändert nichts daran das Konfigurationen gelöscht werden wenn Module nicht vorhanden sind.
Na immerhin ist damit die Wahrscheinlichkeit, dass eine funktionierende Version noch eine Weile vorhanden ist, hoch.
ZitatKönnte man/frau nicht vor dem löschen Fragen? "Kein Modul für Definition XY, löschen ja/nein/vielleicht?"
Nein: es wird ja keine Definition geloescht, sondern beim Reinlesen von fhem.cfg (was nichts anderes ist, wie hintereinander "eingetippte" Befehle) eine Definition nicht akzeptiert, da der Programmteil zum pruefen und durchfuehren der Definition nicht funktioniert.
Dass danach save automatisch durchgefuehrt wird (was indirekt die Definition loescht, weil nur die im Speicher vorhandene Definitionen+Attribute rausschreibt), ist in dieser Situation ein Fehler.
Ergaenzung zum vorherigen Vorschlag: wenn beim Start Fehler entdeckt werden, dann wird autosave auf "false" gesetzt.
Hallo zusammen,
habe den Schuldigen gefunden: DOIFtools!
Nach löschen des Device könnte ich das verhalten nicht mehr nachstellen.
Zum Testen habe ich ein DOIFtools danach noch mal neu angelegt (mit Default Einstellungen -> habe keine Attribut gesetzt!) und könnte wieder beobachten wie meine fhem.cfg verschandelt wurde.
Wenn man einen Schritt weitergeht, wäre es natürlich toll die Konfigurationsdateien (cfg und save aber vielleicht auch uniqueId) zu versionieren und damit so etwas wie die letzten 5 (konfigurierbar) vorzuhalten. Ansonsten finde ich den Vorschlag von rudi gut.
Mir ist es beim Entwicklen auch schon so gegangen, dass ich zwar ein Backup habe, dass maximal 24h alt ist, aber 24h ist halt schon einiges an Verlust. Ich vermute das geht nicht nur beim Entwickeln so...
Zitat von: rudolfkoenig am 31 Oktober 2017, 15:57:04Ergaenzung zum vorherigen Vorschlag: wenn beim Start Fehler entdeckt werden, dann wird autosave auf "false" gesetzt.
Damit könnte man/frau leben.
Greift "autosave = false" dann global? Oder kann/könnte ein Modul dies um/übergehen?
Zum Glück habe ich keins der Module mit CommandSave im Einsatz.
Das wäre auch bei meiner Arbeitsweise fatal. (Die Arbeitsweise verrate ich nicht, um nicht gesteinigt zu werden ;D). Ich mache zumindest NIE ein save. Und ich würde da auch gerne weiter die Macht dazu behalten und nicht von FHEM bevormundet werden.
Zitatund den uebertriebenen Einsatz von CommandSave
Ich fände es daher sinnvoller die Modulautoren zu bitten davon Abstand zu nehmen und ihr Modul zu ändern. Das Mindeste wäre eine Info in der commandref, dass ein solcher unsäglicher Mechanismus im Modul enthalten ist.
Grüße Markus
Zitat von: KölnSolar am 31 Oktober 2017, 18:55:04
Ich fände es daher sinnvoller die Modulautoren zu bitten davon Abstand zu nehmen und ihr Modul zu ändern.
Da kannst Du Dich auch mit der Wand unterhalten, was den Vorteil hätte, dass Du keine blöden Kommentare als Antwort bekommst.
Zitat von: viegener am 31 Oktober 2017, 17:32:07
Wenn man einen Schritt weitergeht, wäre es natürlich toll die Konfigurationsdateien (cfg und save aber vielleicht auch uniqueId) zu versionieren und damit so etwas wie die letzten 5 (konfigurierbar) vorzuhalten.
Dann nimm doch configDB, da hast Du genau dieses Feature out-of-the-box.
Hier laufen direkt mehrere "Wände" frei rum.... ::)
Zitat von: betateilchen am 31 Oktober 2017, 19:00:54
Da kannst Du Dich auch mit der Wand unterhalten, was den Vorteil hätte, dass Du keine blöden Kommentare als Antwort bekommst.
Die Hoffnung stirbt zuletzt. ;) Es gibt ja auch andere Methoden nicht lernwillige Entwickler zu bewegen :-X
Der Thread zeigt ja auch, dass das bisher noch nicht Thema war. Es fielen ja einigen Urgesteinen die Schuppen von den Augen. Und vielleicht fallen jetzt erst dem ein oder anderen Entwickler die Konsequenzen seines Tuns auf und er löst die Problematik in seinen Modulen. Wenn man in die maintainers zu den aufgezählten Modulen guckt, dann könnte ein Entwickler die Liste schon um ca. die Hälfte reduzieren. ;)
Mir ist halt nur wichtig, dass ich nicht durch FHEM bevormundet werde. Meines Erachtens einer der zentralen Ansätze von FHEM. Und ich wüsste gerne vorher, ob ein Modul so einen Unsinn macht, damit ich leichten Herzens auf den Einsatz verzichte.
Und diesen Unsinn auch noch mit einer Lösung des Symptoms zu unterstützen, finde ich nicht so doll. Wenn die Nutzer solcher Module auf die Nase fallen, dann reguliert sich das vielleicht von selbst.
Und der große Popcorn-Wagen wird auch leer ;)
~/Development/svn/fhem/FHEM/73_NUKIBridge.pm:565: CommandSave(undef,undef) if( AttrVal( "autocreate", "autosave", 1 ) );
Damals wusste ich es nicht besser und war jung ;D Also hatte ich von Andre abgeschrieben. Bin aber eh aktuell dabei die Modulfamilie auf den Dispatcher um zu bauen.
Grüße
PS: Vielleicht sollte man explizit dem Entwickler von DOIFtools darauf hinweisen.
Zitat von: CoolTux am 01 November 2017, 07:58:00
PS: Vielleicht sollte man explizit dem Entwickler von DOIFtools darauf hinweisen.
Dann mache ich mal den ersten Post in einem mir fremden Subforum. ;)
Zitat von: KölnSolar am 01 November 2017, 08:17:26
Dann mache ich mal den ersten Post in einem mir fremden Subforum. ;)
Dank Deines Hinweises konnte ich DOIFtools ändern, jetzt wird nur noch vom User beabsichtigtes Sichern ausgeführt.
Die Änderungen gibt es morgen per Update oder sofort aus dem FHEM SVN.
Die Wände scheinen ja doch gar nicht soooo dick zu sein ;D (Natürlich schade, dass es kein Popcorn gibt. ;D)
Danke schon einmal Euch beiden.
Markus
Habe die oben vorgeschlagenen Aenderungen eingebaut, getestet und eingecheckt.
Zitat von: rudolfkoenig am 01 November 2017, 18:00:26
Habe die oben vorgeschlagenen Aenderungen eingebaut, getestet und eingecheckt.
Zitatin ComandSave die "global autosave" Option zu pruefen,
Daraus lese ich, dass ein Modul nicht mehr prüfen muss, ob "global autosave" gesetzt ist, sondern
soll bei strukturalen Änderungen 'AnalyzeCommand(undef, "save")' aufrufen. Sonst würde das globale Attribut 'autosave' mMn keinen Sinn ergeben. Einen Schritt weiter gedacht: Sollte dann nicht das FHEM Framework erkennen, dass eine Änderung vorgenommen wurde und die Konfig speichern, wenn "global autosave" aktiv ist?
Zitatwenn beim Start Fehler entdeckt werden, dann wird autosave auf "false" gesetzt.
Das gilt dann bis zum nächsten FHEM Neustart oder bis weitere Änderungen durchgeführt worden sind oder bis...?
Wird der Anwender informiert, wenn ein "save" unterbunden wurde?
Hi,
meiner Meinung nach soll FHEM von alleine niemals ein "autosave" machen. Das gilt für fhem.pl als auch für alle Module. Wenn ein Benutzer sich ein "at ... save" gebaut hat, dann ist das seine/ihre Entscheidung. Ansonsten würde ich sagen, dass es "verboten" sein sollte.
Man könnte sich überlegen, eine Kopie der fhem.cfg zu speichern, die die jüngsten 3 Zustände (oder so) enthält, falls man mal eine größere Umbauaktion macht, und zu speichern vergessen hat, aber das sollte nicht von alleine aktiv werden.
Wenn ein Modul irgendwas selbst ermittelt, was tatsächlich unbedenklich gespeichert werden kann und soll (also nicht bei autocreate), dann gibt es geeignere Speichermechanismen als die fhem.cfg.
Gruß,
Thorsten
Zitat von: Thorsten Pferdekaemper am 03 November 2017, 17:21:54
Man könnte sich überlegen, eine Kopie der fhem.cfg zu speichern,
das macht FHEM seit Mittwoch automatisch.
15377 by rudolfkoenig, 17:59 Hide 6 Items
fhem.pl: save writes a copy into restoreDirs (Forum #78769)
Zitat von: betateilchen am 03 November 2017, 18:40:07
das macht FHEM seit Mittwoch automatisch.
15377 by rudolfkoenig, 17:59 Hide 6 Items
fhem.pl: save writes a copy into restoreDirs (Forum #78769)
Bist Du Dir sicher, dass das das ist, was ich gemeint habe? Es klingt für mich eher so, dass ein "save" den alten Stand sichert. Was ich aber gemeint habe ist ein Sichern des neuen Stands. Also z.B. immer wenn sich etwas "fhem.cfg-relevantes" getan hat, dann eine Datei schreiben, aber eben nicht nach fhem.cfg. Um zu viel Datenmüll zu vermeiden kann man das ja auf eine Sicherung pro Minute/10 Minuten plus eine beim shutdown (oder wie auch immer) beschränken.
Gruß,
Thorsten
Zitat von: Thorsten Pferdekaemper am 03 November 2017, 21:02:57
Bist Du Dir sicher, dass das das ist, was ich gemeint habe?
Vermutlich nicht, aber es ist besser als gar nix.
Zitat von: Thorsten Pferdekaemper am 03 November 2017, 21:02:57
Also z.B. immer wenn sich etwas "fhem.cfg-relevantes" getan hat, dann eine Datei schreiben, aber eben nicht nach fhem.cfg.
...sondern in die configDB. Die ist genau dafür ausgelegt.
ZitatDaraus lese ich, dass ein Modul nicht mehr prüfen muss, ob "global autosave" gesetzt ist, sondern soll bei strukturalen Änderungen 'AnalyzeCommand(undef, "save")' aufrufen.
Pruefen muss es nicht, aber save ausloesen _muss_ es auch nicht.
Diese Diskussion hatten wir schon vor zwei Jahren (https://forum.fhem.de/index.php/topic,39985), damals ist das global autosave Attribut reingekommen.
Ich bin der Ansicht, dass FHEM Module kein autosave ausloesen sollten. Es gibt aber das Problem, dass manchmal Aenderungen in einem anderen System auch in FHEM Spuren hinterlassen, und wenn man die FHEM Konfiguration nicht speichert, dann hat man nach Neustart was Kaputtes. Ich meine in solchen Faellen ist ein save gerechtfertigt.
Die Idee von Thorsten ist interessant, allerdings ist es (noch?) nicht sehr anfaengerfreundlich: man hat zwei Optionen beim Start, und im Zweifel startet man mit dem falschen fhem.cfg.
Neuer Vorschlag: global autosave kann die Werte 0,1,2 aufnehmen. 0: nur Benutzergesteuert speichern, 1: wie jetzt, halbautomatisch, 2: zusaetzlich nach jeder Strukturaenderung, mit X Sekunden delay, damit das "batch"-setzen von 10 Attributen nicht 10 Speichervorgaenge ausloest. Die Voreinstellung bleibt bei 1.
Kann ich auch was von dem Zeugs haben, das Ihr raucht?
Wer, der nicht drei Jahre intensive FHEM Nutzung hinter sich hat, soll denn das noch verstehen und sinnvoll einsetzen? Es ist doch jetzt schon absehbar, dass in irgendwelchen Internet-Blogs dann die Empfehlung gegeben wird, auf ,,maximale Sicherung" umzustellen. Und was das dann wieder an Problemen und Fragen aufwirft, schlägt dann hier im Forum auf. Und wenn es ,,woanders" empfohlen wird, kriegst Du das hier nie wieder gradegezogen.
Ausserdem sollte es nicht Aufgabe der fhem.pl sein, jeden Schwachsinn denn irgendwelche Frickler "Entwickler" in ihren Modulen verbrochen haben, wieder ausbügeln zu wollen.
Da wäre ich lieber für eine bessere Qualitätssicherung von Modulen VOR dem Einchecken und der Veröffentlichung. Z.B. ein pre-commit-hook, der CommandSave() verbietet.
ZitatNeuer Vorschlag
Finde ich gut. Falls Option 1/2 beinhaltet, dass nach einem Fehler beim FHEM Start nicht mehr automatisch gespeichert wird, dann sollte mAn der Anwender darüber informiert werden.
Zitat von: rudolfkoenig am 03 November 2017, 21:40:48
Die Idee von Thorsten ist interessant, allerdings ist es (noch?) nicht sehr anfaengerfreundlich: man hat zwei Optionen beim Start, und im Zweifel startet man mit dem falschen fhem.cfg.
Neuer Vorschlag: global autosave kann die Werte 0,1,2 aufnehmen. 0: nur Benutzergesteuert speichern, 1: wie jetzt, halbautomatisch, 2: zusaetzlich nach jeder Strukturaenderung, mit X Sekunden delay, damit das "batch"-setzen von 10 Attributen nicht 10 Speichervorgaenge ausloest. Die Voreinstellung bleibt bei 1.
Naja, das ist aber genau umgekehrt als das, was ich gemeint hatte. Ich meinte, dass man nie die fhem.cfg automatisch speichert, sondern Änderungen "vorsorglich" in eine andere Datei (oder eine Reihe anderer Dateien) speichert. Wenn man dann mal vergisst "save config" zu drücken, dann kann man sich den neusten Stand (manuell) von dort holen.
Zitat von: betateilchen am 03 November 2017, 21:38:13
...sondern in die configDB. Die ist genau dafür ausgelegt.
Woher weiß die configDB dann welchen Stand der Konfiguration mein FHEM benutzen soll?
Gruß,
Thorsten
Zitat von: rudolfkoenig am 01 November 2017, 18:00:26
Habe die oben vorgeschlagenen Aenderungen eingebaut, getestet und eingecheckt.
Vielen Dank, gute Sache.. etwas finde ich nur unglücklich gelöst.
- Mache ich ein Update von FHEM wird ins "restoreDir" mit dem aktuellen Daten ein Backup angelegt. -> Soweit so gut.
- Speichere ich dann die Konfiguration nach ein paar Änderungen ab, landet diese im gleichen Backup Verzeichnis meines FHEM Backups.
In meinen Augen erhöht sich die Gefahr sich seine Backup Daten zu zerschießen. Ich würde es bevorzugen, wenn die Konfigurationsdaten in einen anderen Ordner im "restoreDir" gespeichert wird oder noch besser eine Anzahl von Backups dort bevorratet wird und man in FHEM einstellen kann, dass man die älteste nach z.B. 5 neuen Sicherungen löscht.
Grüße Tim