"Last unsaved structural changes" erkennen

[betateilchen]

Du denkst nach wie vor viel zu kompliziert.

[GammaTwin]

Es ist ein Irrtum, anzunehmen, dass das Hinzufügen eines readings noch keine Änderung sei. Allerdings sind neue readings kein structural change.
Aber zumindest das statefile sollte dann gesichert werden, denn dort stehen die readings drin, die nach einem Neustart wieder eingelesen werden.
Außerdem hast Du doch schon ein notify, das auf die Änderung reagiert. Dort kannst Du doch Aktionen ausführen, soviele Du möchtest.

Was brauchst Du denn noch mehr?

Ich möchte eine Fallunterscheidung.

• Speichern der Änderungen, wenn vorher keine Änderungen aufgelaufen sind
• Nicht Speichern, wenn bereits Änderungen vorliegen.

Meine Idee: Ich müsste also wissen, dass "Structural changes" vorliegen.

Du denkst nach wie vor viel zu kompliziert.

Lass hören

[betateilchen]

Ich möchte eine Fallunterscheidung.

• Speichern der Änderungen, wenn vorher keine Änderungen aufgelaufen sind
• Nicht Speichern, wenn bereits Änderungen vorliegen.

Das macht keinen Sinn. Aber vermutlich musst/willst Du das selbst rausfinden.

[passibe]

Weil ich dann ja alles andere auch speichern würde

Was ist denn "alles andere"? Ich habe auch an ein-zwei Stellen ein "save" im Code. Aber außer manuellen Änderungen, die ich sowieso manuell speichere, gibt es bei mir nichts "anderes", was dadurch mitgespeichert werden könnte.

Wie ist das bei dir?

[GammaTwin]

Ist vielleicht eine Philosophiefrage. Mal drei Fälle in denen es mich stören würde. Immer mit der Idee, irgendjemand im Haushalt ändert zu einem beliebigen Zeitpunkt eine  Zeitschaltuhr:

• Ich bastele an etwas, bin unzufrieden und möchte durch einen "shutdown restart" den vorherigen Zustand wieder herstellen.
• Ich aktiviere autocreate in einem MQTT-Device, um zu sehen ob es nach einem Update neue Topics gibt. Dabei wird die readingslist ergänzt - ein structural change
• Ich bastele am KNX Bus. Jede testweise benutzte Gruppenadresse legt einen Device an

Admin Otto123 schreibt:

[...] Die Erklärung, warum ein "blindes" - vom Programm ausgeführtes - save keine gute Lösung ist, [...]

Aber es gibt bestimmt sinnvolle Situationen für ein (save). Aber ich denke, in einer Funktion, die jeder Anwender im Haushalt nutzen kann, ist es kein passender Ort.

[tobi01001]

Moin,

Aus meiner Sicht muss es für Endanwender möglich sein fhem zu benutzen, ohne structual changes zu verursachen und auch so, dass es einem Neustart überlebt.
Ich hab auch vereinzelt Stellen, wo mal ein at definiert wird. die sind aber so unkritisch, das da selbst bei einem crash oder Neustart nichts verloren ginge.
Bei deinen Zeitschaltuhren würden aber die "Änderungen" bis zum Schaltpunkt (und bei Wiederholungen darüber hinaus bis zum "save") in der Schwebe hängen.

Ich hab jetzt mal kurz im Link zum WiKi geschaut und in 99_fronthemUtils.pm geschaut - also evtl. nicht konkret in deinem Anwendungsfall der aber ähnlich gelagert scheint?

Vielleicht erkläre ich nochmal, welche UZSU ich verwendet und die daraus entstehenden Änderungen.
Die UZSU ist der smartVISU und fronthem: https://wiki.fhem.de/wiki/SmartVISU/Universelle_ZeitSchaltUhr_(UZSU)

Also, wenn es um die WeekDayTimer geht, werden die so wie ich das sehe "nur" erstellt und dann per Attribute disable entweder aktiviert oder deaktiviert.

Code Auswählen Erweitern


fhem('defmod wdt_uzsu_'.$device.' WeekdayTimer '.$device.' en '.$weekdays_part);
 if ($uzsu->{active}){
 fhem('attr wdt_uzsu_'.$device.' disable 0');
} else {
 fhem('attr wdt_uzsu_'.$device.' disable 1');
}
 fhem('attr wdt_uzsu_'.$device.' room UZSU');
 #fhem('save');   # use only if you want to save WDT settings immediately.
 
}

Dann kann man das "Problem" auch an der Ursache lösen indem man die enable und disable setter von WeekDayTimer nutzt anstatt der Attribute. Diese sollten ohne "structual change" funktionieren.

Wie gesagt, nur aus dem verlinkten Wiki und daher evtl. nicht ganz aktuell aber vll ein Lösungsansatz.

[GammaTwin]

Auch ein sehr guter Ansatzpunkt. Es wäre natürlich das beste, structural changes zu vermeiden, besonders wenn es nur diese eine Stelle gibt. Werde ich mir auch anschauen.

[GammaTwin]

Ich denke, es ist Zeit für eine Zusammenfassung.

Erkenntnisse:

• Aufgelaufene Structural Changes lassen sich nicht in FHEM ohne weiteres nutzen/auflisten. Es gibt mehrere Lösungen die Änderungen zu protokollieren. Dies betrifft meine Einstiegsfrage - Danke dafür
• 99_fronthemUtils.pm anschauen, könnte gut sein, dass structural changes vermeidbar sind
• Paramater -silent bei notify anschauen

Philosophien, da gibt es wahrscheinlich kein richtig/falsch:

• (save) werden im Code genutzt oder als "blinde" saves gemieden

Die Knobelaufgabe an mich:

• Ich denke zu kompliziert bzw. machen meine komplizierten Gedanken - Zitat:"[...] keinen Sinn. Aber vermutlich musst/willst Du das selbst rausfinden." Ich bin von mir selbst überrascht, wie lange mich diese Aussage beschäftigt. Den Fehler habe aber bisher nicht entdeckt.

Ich werde etwas Zeit brauchen. Wenn ich etwas Zufriedenstellendes produziert habe, werde ich dies nochmal rückmelden.

[swsmily]

Ich hab mir den Thread jetzt zwei mal durchgelesen und verstehe nicht ganz, warum eine Änderung der UZSU (nutze ich selbst nicht) structural changes verursachen.
Werden die Werte nicht nur in Readings geschrieben? So verstehe ich jedenfalls den verlinkten Wiki-Artikel. Das sollten dann ja keine structural changes sein.

Damit Readings oder at-Devices nicht durch einen Crash/Reboot verloren gehen, kann man das Statefile ja extra speichern lassen.
Beispiel mit einem DOIF bei mir:

Code Auswählen Erweitern

define Speichern_aktueller_Status DOIF ([+00:15:00]) ({ WriteStatefile() })Dies habe ich bei mir vor einigen Jahren mal eingetragen, weil ich damals auch das Problem regelmäßiger Reboots des Raspi hatte und damit temporäre at-Devices verschwunden waren. Damit hatte ich dann das Problem nicht mehr. Bis heute ist das DOIF integriert ohne Probleme.
Vielleicht hilft das schon weiter?