statefile-Backup unter anderem Namen speichern

Begonnen von bismosa, 30 Oktober 2021, 10:03:50

Vorheriges Thema - Nächstes Thema

betateilchen

Zitat von: bismosa am 31 Oktober 2021, 08:01:50
Eine offizielle (bzw. automatische) Möglichkeit schaffen, das Statefile regelmäßig zu speichern.

Das wäre auch mein Wunsch: Wir sollte das in einer für alle User einfach nutzbaren Form implementieren. Dazu gibt es im Moment glücklicherweise keinen Zeitdruck.

Und in dem Zusammenhang bedarf es dann auch einer Möglichkeit, ein anderes als das "zur aktuellen Konfiguration gehörende Statefile" wieder mit FHEM Bordmitteln einzulesen und zu verwenden. Wobei man hier im Vorfeld darüber nachdenken muss, wie man grundsätzlich damit umgeht, dass es dann Fälle geben kann, in denen device-states fehlen, weil es das device zum Zeitpunkt der statefile generierung noch nicht gab. Auch der umgekehrte Fall kann vorkommen: das statefile enthält Werte für devices, die inzwischen nicht mehr exisitieren.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

#16
Zitat von: bismosa am 31 Oktober 2021, 08:01:50
Ich habe häufiger im Forum von Problemen diesbezüglich gelesen. (Hier wird dann auch häufiger der Tipp mit dem writestatefile() weitergegeben.)
Ich bin bestimmt nicht der einzige?

Nein, der Wunsch sowas tun zu wollen, ist durchaus nachvollziehbar. Selbst von mir kam im Forum schon ab und zu mal der Ratschlag, in bestimmten Problemsituationen VORÜBERGEHEND das statefile zwischendurch zu sichern. Dann gab es aber immer noch zu jedem Zeitpunkt nur ein einziges statefile.

Grundsätzlich finde ich die Vorgehensweise mancher User, das statefile im Regelbetrieb im Minutentakt zu schreiben, aber wenig sinnvoll.

Das Thema ist komplex  :)


--
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

bismosa

Hallo,

Zitat von: betateilchen am 31 Oktober 2021, 10:21:16
Dazu gibt es im Moment glücklicherweise keinen Zeitdruck.
Stimmt!

Zitat von: betateilchen am 31 Oktober 2021, 10:21:16
..."zur aktuellen Konfiguration gehörende Statefile"...
Nur als kleine Anmerkung: Bei einem Shutdown restart wird derzeit das Statefile gespeichert. Wurde vorher nicht in FHEM gespeichert, sind die beiden Dateien bisher auch nicht synchron.

Zitat von: betateilchen am 31 Oktober 2021, 10:24:36
Grundsätzlich finde ich die Vorgehensweise mancher User, das statefile im Regelbetrieb im Minutentakt zu schreiben, aber wenig sinnvoll.
Minutentakt? Die arme Speicherkarte im Raspberry. Ich mache es jetzt seit langer Zeit im Stundentakt. Dann verliere ich ggf. Werte von einer Stunde. Das lässt sich in meinem System verkraften. Der eine Tag jetzt war schon blöder. Aber auch machbar.

Zitat von: betateilchen am 31 Oktober 2021, 10:24:36
Das Thema ist komplex  :)
Oh, ja. Das musste ich jetzt auch feststellen.  :)

Danke und Gruß
Bismosa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

betateilchen

#18
Zitat von: bismosa am 31 Oktober 2021, 10:29:13
Nur als kleine Anmerkung: Bei einem Shutdown restart wird derzeit das Statefile gespeichert. Wurde vorher nicht in FHEM gespeichert, sind die beiden Dateien bisher auch nicht synchron.

Stimmt. In diesem Fall ist aber das statefile zumindest nicht älter als die gespeicherte Konfiguration, und diesen Fall betrachte ich eher unkritisch.
Theoretisch könnte ein Anwender aber ein 2 Tage altes (oder noch älter) statefile einlesen, und da stellt sich mir die Frage, ob das dann wirklich noch sinnvoll ist.

In einem ersten Schritt werde ich dafür sorgen, dass configDB beim Speichern einer Konfiguration auch das zu diesem Zeitpunkt gültige statefile mit versioniert speichert. Die Möglichkeit, eine vorherige Version der FHEM-Konfiguration wiederherzustellen, existiert ja dort jetzt schon (für mich damals einer der Hauptgründe, configDB überhaupt zu bauen). Diese Wiederherstellung wird dann auch das zugehörige statefile wiederherstellen.

Über den Umgang mit "zwischendurch" erzeugten statefiles muss ich noch etwas länger sinnieren, wahrscheinlich, wenn ich mal wieder im Zug sitze und ein paar Stunden Zeit zum Nachdenken habe.


--
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

bismosa

Zitat von: betateilchen am 31 Oktober 2021, 10:40:46
Stimmt. In diesem Fall ist aber das statefile zumindest nicht älter als die gespeicherte Konfiguration, und diesen Fall betrachte ich eher unkritisch.
Genau da drauf bin ich aber hereingefallen. Ich hatte um herauszufinden, welches Modul bei mir 100% CPU-Last erzeugt fast alle Devices gelöscht.
Da ich mir sicher war, das alles nach einem "shutdown restart" wieder vorhanden sein müsste. Die Readings fehlten nun.

2 Tage ist bestimmt etwas alt und nicht wirklich erforderlich. Ein paar Stunden wäre in meinem Fall praktisch gewesen. Ich habe es erst nach einem weiteren Reboot festgestellt und damit war mein Backup auch bereits überschrieben.

Vielleicht auch ein Sonderfall bei mir. Wer viel Probiert und auch kein Profi beim Programmieren ist, kann das System halt auch mal zum Absturz bringen. Das ist ja nicht der Fall bei einem "Normaluser"  ;)
Ich muss mir halt angewöhnen alles abzusichern, bevor ich bastel. Dann kann auch nichts passieren.

Gruß
Bismosa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...