Readings / State über einen Absturz "retten"

[herrmannj]

Hallo zusammen,

ich brauche eine Möglichkeit um den state und die readings einiger device über einen unkontrollierten Neustart der FB zu retten.

Im Falle von "shutdown reboot" funktioniert das ganz prima, da gehen die Daten ja in den statefile. Im Falle eines unkontrollierten Neustarts (aka Absturz oder Stromausausfall ;-) ist das aber eher kontra-produktiv weil aus dem statefile alte Werte, (Zeitpunkt des letzten save oder shutdown) geladen werden.

Klar, könnte jetzt anfangen selber was zu basteln, aber eigentlich ist alles was ich brauche in den logs.

Hat vielleicht jemand einen Tip wie ich in perl routinen, möglichst unter Ausnutzung von bereits vorhandenen fhem Bordmitteln, aus dem aktuellen logfile den aktuellsten Wert eines bestimmten readings/state bekomme ? Vielleicht sogar ein codeschnipsel ? ;)

Nochmal anschaulich:

dummy Alarmanalgenstatus: hat den state "aktiv". Kommt jetzt ein Stromausfall oder (warum auch immer) ein FB reboot wird der dummy mit dem Wert geladen der im statefile ist: zB "disarm".

Angedachte Lösung: parallel eine Variable in der 99_myUtils.pm. Die ist nach einem Neustart erstmal leer. Wenn fhem startet wird der "falsche" state aus dem statefile geladen, aufgrund der Differenz zwischen state und der Variable sucht die perl routine im passenden log den letzten Wert und passt state so an.

Gesucht: einfache Lösung um in einem perlscript im log das jüngste reading zu finden.

btw. weiss jemand ob beim laden aus dem statefile ein stateFormat abgearbeitet wird ?

Danke und Grüße
Jörg
 

[Icebear]

Moin,

möglichkeit 1 (da keine Alarmanlage bei mir, also reicht das) per at sichern alle 10 minuten
define Sichern at +*00:05:00 save

Möglichkeit 2
Speicher doch einfach beim Scharf / Unscharf schalten mit Save..

Dann hast du auf jeden fall alles wichtige gesichert..

Grüsse aus Wesel
Icebear

[herrmannj]

Hallo Icebear,

vielen Dank, pragmatische Idee und schnell umzusetzen.

Die logs halten die Infos ja, quasi eventbasiert und ich versuche, so aus sportsgeist, die elegante Lösung zu gehen.

Vielleicht kommmen ja noch weitere Hinweise dazu rein :)

Danke und Grüße
Jörg

[Puschel74]

Hallo,

unkontrollierten Neustart der FB zu retten.

Da kann dir wohl oder übel nur eine USV helfen damit deine FB nicht unkontrolliert neu startet - so es ein Spannungsproblem ist.

Einen unkontrollierten Neustart wird dir auch ein noch so ein tolles Skript nicht abfangen können da die FB dann bereits in der Reboot-Phase ist.

Grüße

[Icebear]

Hi,

also bei der "eleganten" lösung hast du nur das problem das du evtl doch stark angewachsene LOGs parsen musst.

Der Weg bei den "wichtigen" aktionen den State zu saven ist imho sinnvoller zumal du den vorteil hast gleich alle anderen States mit zu haben ...

[Puschel74]

Hallo,

nein, sorry. Aber parsen muss man da nichts.

Wenn die FB unkontrolliert neu startet kann mann nur alle x Sekunden alles sichern und dennoch hat man das Problem das die letzten x-1 Sekunden fehlen können (wenn die FB neu startet kann man parsen was man will - da ist nichts da die FB in der Bootschleife ist).

Ich würd erstmal schauen warum die FB unkontrolliert neu startet und dieses Problem beseitigen - da kann aber nur der Fragesteller weiter helfen.

Grüße

[herrmannj]

Aloa,

...hat man das Problem das die letzten x-1 Sekunden fehlen...

Genau. Und das muss ja nicht sein :)

Ich würd erstmal schauen warum die FB unkontrolliert neu startet und dieses Problem beseitigen - da kann aber nur der Fragesteller weiter helfen.

Das ist zum Glück weder Dauerzustand, noch alltägliches Schicksal :). Die FB ist auch garnicht das Thema, es geht wirklich darum das ich einige Routinen habe die auf eine "Historie" angewiesen sind um zu funktionieren. Das Beispiel mit dem Status dummy ist nur ein greifbares Beispiel.

Dazu kommen bei mir diverse Sensoren die für ihre Werte eine Historie führen. Der Windmesser zum Beispiel mittelt mit gleitendem Durchschnitt und schreibt das auch brav ins log weg. Daneben "merkt" sich die Routine auch wie lange der Wind aus einer bestimmten Richtung kommt. Am Tagesende schaut dann ein weiteres script welche Himmelsrichtung die meisten Zähler hat und die "gewinnt" den Tag und landet in einem Tageslog.

Mir passiert es schon beim fhem-optimieren :) das die Büchse hängt, dann muss ich eben mal den Stecker ziehen. Das ist aber blöd, die Historie ist für den Tag dann futsch.

Bis dahin ist es natürlich mehr oder weniger nur Kosmetik - aber da ich fhem immer mehr integriere finde ich schon das die Lösung auch robust genug sein muss einen um einen, wie auch immer gearteten, Neustart mit intaktter Logik zu überstehen.

Eine Möglichkeit wäre es jetzt einen eigenen statefile auf der Platte zu halten. Das finde ich aber aus zwei Gründen nicht optimal, zum ersten weil fhem die Logik ja bereits hat (man muss das Rad ja nicht dauernd neu erfinden, davon wirds auch nicht besser) und weil zyklische save overhead produzieren und im Zweifel eben doch die letzte Änderung verpassen.

Den gesamten statefile wegen einem event zu schreiben ist auch ineffizient, genau das macht ja ohnehin schon das log und zwar spezifisch.

Deshalb der Weg zum log. Log manuell parsen ist drin, aber fhem.pl und fileplot haben da ja schon was eingebaut.

Vielleicht kann mir ja jemand einen Stubser geben welche Routinen sich dafür "recyceln" lassen - ohne das Rad neu zu erfinden ;)

viele Grüße und schonmal vielen Dank
joerg

[Puschel74]

Hallo,

kurz und knapp

sein muss einen um einen, wie auch immer gearteten, Neustart mit intaktter Logik zu überstehen

es wird (vielleicht doch irgendwann mal) nie eine Logik geben die einen wie auch immer gearteten Neustart vorhersehen kann.

Wie soll diese Logik aussehen die einen Reboot (egal auf welcher Plattform FHEM läuft) vorhersehen kann?
Und das wird diese Logik wohl oder übel können müssen um den Status zeitnah in, egal welches, File schreiben zu können.

Selbst wenn du dir sekündlich den Status deiner Aktoren in ein Logfile schreiben lässt - was du ja machen kannst.
Wenn, WAF vorausgesetzt, dein Schatz eine Taste drückt - und das Licht angeh(t)en soll weil sonst Mecker angesagt ist, während der FHEM_Server unerwartet eine reboot durchführt
wirst du den letzten Status dieser Lampe niemals sichern können (es sei den du hast einen zweiten FHEM-Server nebenher am laufen der die Stati aller Device mitlauscht und ggf. einspringt).

Grüße

[herrmannj]

Hallo Puschel74,

ganz genau so ist, so sehe ich das auch!

100% geht nicht, die wichtigen Sachen in die logs, der rest ist egal.

Nur wie aus einer *.pm wieder auf die logs zugreifen ?

viele Grüße
Jörg

[Puschel74]

Hallo,

das was im Logfile noch landet - landen kann - wird doch auch ins save.log geschrieben, oder täusch ich mich da?
Daraus sollten ja die letzten verfügbaren Stati wieder hergestellt werden (können).
Nachdem FHEM gebootet ist per Value bzw. per ReadingsVal wieder auslesbar.

Wie geasgt - die letzten verfügbaren Stati bevor der Server abgeschmiert ist.

Wenn sich die Stati dazwischen geändert haben weil die Fernbedienungug den Aktor direkt schaltet bekomt das FHEM nicht mit.
Ergo gibt es auch keinen "aktuellen" Status in FHEM sondern, im Falle des abschmieren des Servers, nur den letzten bekannten Status.

Grüße

[herrmannj]

wird doch auch ins save.log geschrieben, oder täusch ich mich da

Das save.log kenne ich nicht, nur den statefile. Den meinst Du vermutlich. Der wird aber leider nicht automatisch aktualisiert.

Nachdem FHEM gebootet ist per Value bzw. per ReadingsVal wieder auslesbar.

Die Werte die Du dort bekommst sind unter Umständen einige Wochen alt. Da liegt ja das Problem.

Das einzige was ich kenne was automatisch wegschreibt sind die logs.

vg
joerg

[Puschel74]

Hallo,

stimmt - war auch ein Fehler von mir.

Das File heisst fhem.save das ich meinte.

Grüße

Edith:

Die Werte die Du dort bekommst sind unter Umständen einige Wochen alt. Da liegt ja das Problem.

Einige Wochen alt? Nein - das hatte ich noch nie.
Mein FHEM läuft 24/7 - da sind keine Stati "einige Wochen alt".

[rudolfkoenig]

Ein paar Hinweise:
- WriteStateFile schreibt (nur) die Datei, was man mit "attr global statefile" gesetzt hat.
- diese Datei besteht, genauso wie das fhem.cfg aus "normalen" FHEM Befehlen, dia man per "include" wieder einlesen kann.
- FileLog hat bis vor kurzem nach jedem Protokollieren einer Zeile die Daten per fsync auf die Platte geschrieben. Da das mir beim zunehmenden Verwendung von SSDs zu teuer vorkam, habe ich die Zeilen auskommentiert: d.h. bei einem HW/OS (nicht FHEM!) Absturz ist es jetzt wahrscheinlicher, dass Inhalte eines Logs teilweise verloren gehen

[Icebear]

Moinsen..

kann ich das Statefile mit einem Komando schreiben ohne das auch alle Configs gesichert werden und wenn ja wird dann auch ein Sync ausgeführt ?

Das könnte ja dann evtl die lösung sein ?!

Grüsse aus Wesel
Icebear

[rudolfkoenig]

{ WriteStateFile() }