Hallo,
ich habe mein FHEM neu installieren müssen, da mein Raspi, bzw seine SD abgeraucht ist.
Glücklicherweise hatte ich eine vollständige Kopie des Verzeichnisses.
Allerdings stellte ich fest, dass die Zustände der einzelnen Devices (Dummies und Öffnungssensoren, etc.) nicht gespeichert waren oder ich sie nicht gesichert habe, da
alle auf ??? standen?!
Daher meine Frage, wohin speichert FHEM diese Zustände, oder habe ich etwas falsch gemacht?
Welche Rechte muss die entsprechende Datei haben.
Greets
Bye Flanders
Morgen,
die readings werden in der fhem.save gespeichert.
Grüße Markus
Aus der commandref
https://fhem.de/commandref_DE.html#statefile (https://fhem.de/commandref_DE.html#statefile)
statefile
Dieses Attribut legt den Namen der Datei fest, in die Statusinformationen aller Geräte gespeichert werden bevor der Server heruntergefahren wird. Falls diese Datei nicht angegeben wird, so werden keinerlei Informationen gesichert.
Hm, danke.
Ist gesetzt, Datei ist vorhanden. Komisch.
Kann ich das automatische Speichern irgendwie aktivieren (im Interval speichern?).
1) Er scheint die Datei komplett ignoriert zu haben (deswegen wohl die ??? bei den States)
2) Manchmal fahre ich den Raspi mit reboot neu hoch, das bekommt fhem ggf. nicht mit....
Greets
Flanders
Also für automatisches Speichern habe ich
define at_SafeState at +*01:00:00 {WriteStatefile()}
gefunden. Bleibt nur die Frage, warum das beim Transferieren nicht geklappt hat...
Es macht nicht viel Sinn, das Statefile manuell zu sichern.
ich geh mal Popcorn holen.
Zitatich geh mal Popcorn holen.
Da es ja grade ziemlich herbstelt, bitte einmal Schoko-Zimt-Popcorn 8)
Zitat von: betateilchen am 01 Oktober 2019, 20:43:15
Es macht nicht viel Sinn, das Statefile manuell zu sichern.
So eine pauschale Aussage macht noch weniger bis gar keinen Sinn. ;-)
Wenn ein System öfters mal abstürz kann es Sinn machen, zumindest so lange bis die Ursache behoben ist.
Vor einiger Zeit hatte ich regelmäßig Abstürze beim senden von Plots per Telegram. Jedesmal waren dann meine Verbrauchsberechnungen verhagelt weil ein altes Statefile geladen wurde.
Also habe ich auch erstmal das statefile speichern mit eingebaut, immer nachdem die Verbrauchswerte berechnet wurden.
Und schon konnte mir ein Absturz nix mehr verhageln.
Die Ursache der Abstürze hatten sich nie geklärt. treten aber schon ewig (gefühlt über ein Jahr) nicht mehr auf.
Das statefile sichern hab ich aber noch drin. Warum sollte ich es rausnehmen? stört ja nicht. :-)
@betateilchen:
Mich würde das auch interessieren, warum das manuelle Sichern des Statefiles keine gute Idee sein sollte.
Könntest du das bitte erklären?
Ein automatisches "save" per AT halte ich auch für höchst bedenklich, aber ein aktuelles Statefile zu haben, schadet doch nicht.
Ich habe bei mir dazu dieses AT:
define SaveStateFile at +*00:15:00 {WriteStatefile}
das nur das statefile alle 15 Minuten sichert.
Ist das keine gute Idee?
LG,
Stephan.
Das "save" speichert die Konfiguration und das statefile, kohärent miteinander.
WriteStatefile() ist nicht dafür gedacht, vom Benutzer direkt aufgerufen zu werden. Wenn man es trotzdem macht, kann es zu Probleme führen, u.a.
- beim Start von Fhem, wenn Konfig und statefile tatsächlich nicht kohärent sind.
- bei Statistiken und Aggregationen (Zähler)
- bei "volatile" Defs wie einmalige AT
- bei switchInThePast Sachen wie im WeekDayTimer und obsoleten HeatingControl
Und ich könnte mir noch andere Fälle vorstellen (z.B. verpasste ATs, Kohärenz zwischen statefile und interne Timers, usw).
Meiner Meinung nach ist es von geringem Interesse. Wenn mein Fhem aus irgendwelchem Grund abstürzt, sind so wie so Sachen durcheinander. Ich starte lieber wieder vom letzten "save" (config + statefile konsistent)
Und wenn ich mein Fhem umziehe, stoppe ich Fhem ordentlich, damit WriteStatefile() während des Shutdowns korrekt eingesetzt wird. Dann kann ich problemlos auf der andere Seite wieder starten.
Hab wieder gefunden, was betateilchen mal geschrieben hatte:
Zitat von: betateilchenWenn Du diese - nicht im "offiziellen" Funktionsumfang dokumentierte - Funktion in eigener Verantwortung einsetzt, musst Du einfach damit rechnen, dass eine solche Funktion IHRE originäre Aufgabe erfüllt und nicht zwangsläufig DEINE Wünsche befriedigt.
I.a.W.: Auf eigene Gefahr ;)
Vielen Dank für die ausführliche Erklärung!
Hab mein AT gleich gelöscht. :)
Es müsste der große Meister etwas dazu sagen. Ich sehe das zumindest etwas anders.
Ich habe bei mir keine Definitionen im System, die automatisch die Konfiguration ändern würden. Das heißt, wenn das rote Fragezeichen aufleuchtet, dann nur dann, wenn ich etwas bewusst in einer Definition manuell geändert habe. Danach klicke ich auf save um die Änderungen zu übernehmen.
Wenn ein System abstürzt, dann fehlen alle Readingveränderungen seit dem letzten Save, das kann schon sehr ärgerlich sein, wenn das System längere Zeit gelaufen ist.
Mit einem WriteStatefile() werden lediglich Readingsveränderungen (es sind allesamt setstate-Befehle) gespeichert.
Wenn also die Konfiguration nicht geändert wurde, dann sehe ich keinen Grund für größere Inkonsistenzen, als die, die nach dem Absturz ohnehin ohne WriteStatefile() entstanden wären.
Es ist immer besser im Fall eines Falles einen möglichst aktuellen Zustand zu haben, als einen alten.
Unabhängig davon kann jeder ein regelmäßiges Backup seines gesamten System machen, um jegliche Inkonsistenzen zu vermeiden. Da man aber ein Backup kaum stündlich ausführen wird, wird man nach dem Einspielen eher konsistente veraltete Informationen vorfinden ;)
Zitat von: rudolfkoenig am 21 Oktober 2014, 14:11:09
1. betateilchen hat mit seinem Kommentar recht.
...
;)
Aber gut... jeder macht, was er will.
Ich habe sogar einige gesehen, die selbst in statefile eigene Sachen (ausserhalb eines Moduls) schreiben...
Übrigens, der Vollständigkeit halber: bei ConfigDB sind die states dann nicht in einer Datei, sondern in der DB (aber WriteStatefile() funktioniert natürlich auch)
EDIT: und Frage an dich, Damian: wie reagiert ein DOIF mit wait timers oder cmdpause o.ä. und/oder cmdstate Abhängigkeiten in Bedingungen, wenn man ein verältetes statefile "restauriert"?
Zitat von: amenomade am 04 Oktober 2019, 23:09:22
EDIT: und Frage an dich, Damian: wie reagiert ein DOIF mit wait timers oder cmdpause o.ä. und/oder cmdstate Abhängigkeiten in Bedingungen, wenn man ein verältetes statefile "restauriert"?
Das Modul nimmt die Readings, wie es sie nach dem Neustart vorfindet. Die Wahrscheinlichkeit von einem falschen Zustand auszugehen ist höher, je länger WriteStatefile() nicht ausgeführt wurde (DB setze ich nicht ein).
wait_timer werden nach einem Neustart nicht neu aufgesetzt - auch nicht wenn man das System sauber herunter fährt. Sie sind mit einem Sleep vergleichbar. Konkrete Timerdefinitionen werden nach dem Neustart aufgrund der Konfiguration neu gesetzt und die ist unabhängig von State-File.
Danke für die Antwort. Also... das save/restore des statefiles wäre in dem Fall doch eine Verbesserung.
das statefile ist tatsächlich ein riesen Problem
Ich habe mein statefile nach-->
attr global statefile /tmp/fhem.save
gelegt, bei einem shutdown restart , ist mein System aktuell 2 sekunden blind, also übernehme ich
bei stromausfall, ist das tmp verzeichnis leer, also kein statefile , da wird auf neue state gewartet, bzw neu gesetzt oder bei HM neu gefragt "statusrequest"
als bsp mein Holiday Kalender sagt, wann Winter Sommer usw, und schaltet mal die Hz auf Auto, und wenn unnötig wird es nachträglich überschrieben, Außentemp 25Grad -->HZ aus
meine 5 cent