[gelöst] Datenverlust: fhem.cfg wird bei "Cannot load module" überschrieben

rudolfkoenig · 31 Oktober 2017, 15:57:04

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.

Schlimbo · 31 Oktober 2017, 15:59:53

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.

viegener · 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. 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...

kaputt · 31 Oktober 2017, 18:00:52

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?

KölnSolar · 31 Oktober 2017, 18:55:04

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

). 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

betateilchen · 31 Oktober 2017, 19:00:54

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.

marvin78 · 31 Oktober 2017, 19:06:00

Hier laufen direkt mehrere "Wände" frei rum....

KölnSolar · 01 November 2017, 07:42:52

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

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

CoolTux · 01 November 2017, 07:58:00

Code Auswählen


~/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

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.

KölnSolar · 01 November 2017, 08:17:26

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.

Ellert · 01 November 2017, 12:22:37

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.

KölnSolar · 01 November 2017, 13:59:03

Die Wände scheinen ja doch gar nicht soooo dick zu sein

(Natürlich schade, dass es kein Popcorn gibt.

)

Danke schon einmal Euch beiden.
Markus

rudolfkoenig · 01 November 2017, 18:00:26

Habe die oben vorgeschlagenen Aenderungen eingebaut, getestet und eingecheckt.

dev0 · 03 November 2017, 12:05:23

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?

Thorsten Pferdekaemper · 03 November 2017, 17:21:54

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