[gelöst] - fhem.save. wann / wie oft wird diese geschrieben?

[Frank_Huber]

Mahlzeit,

kurze Frage zur fhem.save.
wann und wie oft wird diese denn geschrieben?
Ich habe den Verdacht dass meine nur bei einem restart geschrieben wird. Wenn FHEM aber durch einen Fehler crasht hat die save die readings des letzten reboots?

Ist das so richtig oder ein Fehler meiner Installationen?
lässt sich das speichern der fhem.save triggern? per at z.B. ?

Grüße
Frank

[Ellert]

Schau mal hier https://fhem.de/commandref_DE.html#save

[Frank_Huber]

Schau mal hier https://fhem.de/commandref_DE.html#save

Oh Mann, manchmal ist es so einfach. *facepalm*

ich habe nur https://fhem.de/commandref_DE.html#statefile gelesen.
den "save" bezog ich immer auf die cfg.

Danke Dir auf jeden Fall. werd ir jetzt nen zyklischen at anlegen zum speichern.

Grüße
Frank

[amenomade]

wann und wie oft

M.W. wird es nur manuell angestoßen... und speichert nur war CommandRef sagt.

Gruß

[Frank_Huber]

M.W. wird es nur manuell angestoßen... und speichert nur war CommandRef sagt.

Nach dem was ich jetzt rausgelesen habe (wenn ich es richtig verstanden habe) dann speichert FHEM das statefile nur beim stoppen.also beim Neustart.

Mein Hintergrund dazu:
Wenn FHEM einige Tage durchläuft und auch keine Änderungenerhält kann das statefile recht alt sein.
Wenn darin dann noch dummys stecken die täglich Verbrauchswerte errechnen wirds doof.
musste dann immer manuell im dblog Einträge korrigieren.
Hab jetzt per AT noch ein "save" eingefügt kurz nach der Tageswerteberechnung.
Damit sollten meine Daten wieder "safe" sein.

/Frank

[Beta-User]

Nur am Rande: Dir ist schon klar, dass auch ein automatisiertes "save" so seine Tücken hat, oder?

Insbesondere kann es vorkommen, dass Du unbabsichtigt Devices löschst, wenn die Module nicht sauber geladen werden konnten usw., auch 1-wire am USB ist/war da empfindlich. Da Du das "wenigstens" bei Tagesende zu machen scheinst, ist es nicht ganz so dramatisch (at's werden nachgeholt...), aber trotztdem:

Besser den Fehler finden, warum FHEM alle paar Tage abschmiert. Und configBD nutzen, dann kannst Du uU. auch ältere Device-Versionen wieder reanimieren.

Nix für ungut,

Beta-User

[Frank_Huber]

Nur am Rande: Dir ist schon klar, dass auch ein automatisiertes "save" so seine Tücken hat, oder?
Insbesondere kann es vorkommen, dass Du unbabsichtigt Devices löschst, wenn die Module nicht sauber geladen werden konnten usw., auch 1-wire am USB ist/war da empfindlich. Da Du das "wenigstens" bei Tagesende zu machen scheinst, ist es nicht ganz so dramatisch (at's werden nachgeholt...), aber trotztdem:
Besser den Fehler finden, warum FHEM alle paar Tage abschmiert. Und configBD nutzen, dann kannst Du uU. auch ältere Device-Versionen wieder reanimieren.

Danke für deine Meinung.
Der Grund für die Abstürze ist schon gefunden und behoben. Es war ein Fehler im 59_Luftdaten.pm Modul.
Ich ändere an der cfg im Regelfall nichts. und nach einem Reboot kontrolliere ich immer ob alles passt. gerade wegen der evtl wechselnden USB Reihenfolge.
von daher ist (für mich) der automatische save ein Plus an Sicherheit.

[Beta-User]

Ich ändere an der cfg im Regelfall nichts.

Das war genau mein Punkt: Es geht gar nicht darum, dass DU SELBST etwas änderst, sondern, dass Teile der cfg automatisch verworfen werden und FHEM mit dem "at" dann automatisch eine verkleinerte cfg abspeicherst. Beispiel: https://forum.fhem.de/index.php/topic,71399.msg629024.html#msg629024

und nach einem Reboot kontrolliere ich immer ob alles passt. gerade wegen der evtl wechselnden USB Reihenfolge.

Das Problem habe ich nicht, da meine USB-Devices alle eindeutig "by-id" identifiziert werden. Da macht dann nicht einmal ein Umzug vom PI auf eine TV-Box irgendwelche Mucken .

Nix für ungut, Beta-User

[Frank_Huber]

dafür gibts zur Not das tägiche Backup auf den fileserver.

mit "by-ID" hab ich auch schonmal experimentiert, aber ein Modul mochte das nicht.
Glaube das war der OBIS IR Lesekopf.
Da will ich aber nochmal ran bei Gelegenheit.
Die meisten FHEM Instanzen haben eh nur einen USB Belegt mit dem 1wire Busmaster.
nur im KG gibt es einen zweiten mit dem IR Kopf.

Generell gebe ich Dir mit dem speichern auch Recht.
Wenn es einen Weg geben würde das statefile einzeln zu speichern würde ich das auch anderst machen.

EDIT: Habs jetzt in "save fhem.bkup" geändert. das speichert die statefile und die cfg in das bkup.
Danke für die Diskussion Beta-User!

[LuckyDay]

Code Auswählen Erweitern

{WriteStatefile()}

mit der Befehl kannst auch nur das Statfile erneuern,

kannst ja probieren , wenn du es in die cmd Fenster eingibst

[Beta-User]

Code Auswählen Erweitern

{WriteStatefile()}

...manchmal sind die Dinge so einfach...
Wer perl kann, ist offenbar klar im Vorteil .

EDIT: Habs jetzt in "save fhem.bkup" geändert. das speichert die statefile und die cfg in das bkup.
Danke für die Diskussion Beta-User!

Danke auch, damit habe ich eben auch wieder was gelernt: Man scheint nicht erst das global-Attribut für die cfg ändern zu müssen, um die aktuelle cfg (in meinem Fall als Textfile) rausspeichern zu können...

mit "by-ID" hab ich auch schonmal experimentiert, aber ein Modul mochte das nicht.
Glaube das war der OBIS IR Lesekopf.

An sich sollte das egal sein, ob man auf dem einen oder anderen Weg bei derselben Datei  (aus Linux-Sicht) landet, die "by-xx"-Variante ist ja eingentlich nur ein Link. Könnte allenfalls etwas mit einem dazwischengehängten Prozess zu tun haben?!? Ist aber pure Glaskugel .

[Frank_Huber]

Code Auswählen Erweitern

{WriteStatefile()}
mit der Befehl kannst auch nur das Statfile erneuern,

danke! as ist genau was ich brauche um mich sicher zu fühlen. 

[Frank_Huber]

"by-id"
An sich sollte das egal sein, ob man auf dem einen oder anderen Weg bei derselben Datei  (aus Linux-Sicht) landet, die "by-xx"-Variante ist ja eingentlich nur ein Link. Könnte allenfalls etwas mit einem dazwischengehängten Prozess zu tun haben?!? Ist aber pure Glaskugel .

hing evtl auch mit der Länge zusammen. /dev/ttyUSB1 ist ja doch deutlichkürzer als der string von by-id.
Muss ich aber wie gesagt nochmal irgendwann in Ruhe dran.

[amenomade]

By-id ändert sich aber nicht. ttyUSb<n> kann sich ändern, wenn Du die USB Anschlüsse umstöpselst, oder neubootest.

Gruß

[Frank_Huber]

Ja, das weiß ich.
Ich meine als ich das getestet hab ging das OBIS nach dem modify, aber nach nem Neustart nicht mehr. Trotz korrektem by-id Pfad. Deswegen bin ich zurück auf den TtyUSBx

Gesendet von meinem S3_32 mit Tapatalk