Daten nicht aus der fhem.cfg löschen

[aski71]

Moin,

Ich habe heute im 33_readingsGroup.pm rumgespielt, um zu sehen, ob ich mein Problem selber lösen kann, weil ich bisher keine Antwort hatte.
Leider habe ich einen Fehler gemacht, woraufhin aus der fhem.cfg alle meine readingsGroups getilgt wurden.
Ich hielte es für eine bessere Idee, nicht zuordenbare Einträge würden ignoriert und nicht sofort aus der cfg gelöscht, nur weil das Modul nicht startet. 
Nur gut, dass ich ein Backup hatte.

Gruß, Alex

[MadMax-FHEM]

Einfach NICHT speichern, sondern shutdown restart und es sollte wieder passen...

Evtl. vorher noch ein update (auf readingsgroup.pm) damit die Originaldatei wieder da ist...

Persistent in der cfg wird es nur bei "save config"..,
...ansonsten sind Änderungen erst mal nur "im RAM"...

EDIT: oder config-DB...

Gruß, Joachim

[igami]

Du könntest dir ein cmdalias erstellen das per chmod die Schreibrechte für fhem.cfg regelt.

[aski71]

Danke für die Antworten. Ich kann mich nicht erinnern, irgenwas gesichert zu haben.
Die readingsGroups waren nach shutdown restart einfach weg. 

[Otto123]

Ich kann mich nicht erinnern, irgenwas gesichert zu haben.

Im Umkehrschluss war das das Problem? 
Wenn man irgendetwas in der WebUI ändert wird dies erst in fhem.cfg eingetragen wenn man save macht.
Es sei denn Du hast irgendein autosave?
FHEM ist uralt oder aktuell?
Ich versuche mal den Zusammenhang zu erklären wie er mir bekannt ist, kein sein das ist nur Halbwissen!
Ich glaube irgendwann voriges Jahr wurde folgendes eingeführt:
Wenn FHEM beim Start Fehler feststellt, werden die in Frage kommenden defines aus der Konfiguration im Hauptspeicher genommen. Sonst könnte FHEM gar nicht starten
Autosave wird dann deaktiviert. (ich weiß nicht ob man dies trotzdem umgehen kann)
Jetzt darf man nicht mutwillig manuell save machen, dann ist die config überschrieben.

Gruß Otto

[aski71]

Im Umkehrschluss war das das Problem? 
Wenn man irgendetwas in der WebUI ändert wird dies erst in fhem.cfg eingetragen wenn man save macht.
Es sei denn Du hast irgendein autosave?
FHEM ist uralt oder aktuell?
Ich versuche mal den Zusammenhang zu erklären wie er mir bekannt ist, kein sein das ist nur Halbwissen!
Ich glaube irgendwann voriges Jahr wurde folgendes eingeführt:
Wenn FHEM beim Start Fehler feststellt, werden die in Frage kommenden defines aus der Konfiguration genommen. Sonst könnte FHEM gar nicht starten
Autosave wird dann deaktiviert. (ich weiß nicht ob man dies trotzdem umgehen kann)
Jetzt darf man nicht mutwillig manuell save machen, dann ist die config überschrieben.

Gruß Otto

Danke Dir, Otto. Das Prinzip ist mir durchaus bekannt. Drum war ich ja so perplex.
Ich bin mir nämlich ziemlich sicher, dass ich nur im Untergrund gearbeitet und neu gestartet habe. Und als es dann nicht funktioniert hat, habe ich das Originalmodul wieder aktiviert und wieder nur neu gestartet.

Nunja. Ein cronjob erzeugt jetzt jede Nacht eine fhem.cfg.yesterday. Das sollte die Sicherheit schon mal erhöhen... 

[betateilchen]

Ich hielte es für eine bessere Idee, nicht zuordenbare Einträge würden ignoriert und nicht sofort aus der cfg gelöscht, nur weil das Modul nicht startet.

Es wird überhaupt nichts aus der fhem.cfg gelöscht.

Es wird beim Sichern (save config) immer nur das in die fhem.cfg geschrieben, was zur Laufzeit von FHEM existiert. Wenn nun beim Starten ein device nicht angelegt werden kann, existiert es einfach nicht zum Zeitpunkt des "save". Insofern ist es in der neu erstellten fhem.cfg einfach nicht enthalten, weil nicht gesichert werden kann, was nicht vorhanden ist.

Alternative: stelle um auf configDB, dort werden die Konfigurationen versioniert und Du kannst einfach eine vorherige Konfiguration wieder aktivieren.