Grüße,
gibt es eine Möglichkeit die "Last unsaved structural changes" zu erkennen/abzufragen? Ich meine nicht mit dem Auge - das kann ich ;)
Z.B. per DOIF, per irgendeinem Kommando, um es dann z.B. Nachricht als Auflistung zu versenden.
Besten Dank.
Es wird für die dort abgelegten Einträge selbst kein event erzeugt, auf das man per notify o.ä. reagieren könnte.
Die Dinge, die für das Auftauchen des roten Fragezeichens sorgen, erzeugen aber in der Regel selbst ein event, auf das man reagieren kann.
Aber wofür braucht man das wirklich?
Hallo,
wenn ich ein Attribut in einem Device ändere bekomme ich im Event-Monitor z.B. einen Eintrag:
2025-08-26 11:16:45 Global global ATTR FritzBox enableBoxReadings box_energyMode,box_led,box_pwr,box_notify
Damit müsste man doch weiter kommen.
Grüße Jörg
Zitat von: JoWiemann am 26 August 2025, 11:19:51wenn ich ein Attribut in einem Device ändere bekomme ich im Event-Monitor z.B. einen Eintrag:
Das ist doch genau das, was ich hier schon meinte:
Zitat von: betateilchen am 26 August 2025, 11:06:55Die Dinge, die für das Auftauchen des roten Fragezeichens sorgen, erzeugen aber in der Regel selbst ein event, auf das man reagieren kann.
Das passiert auch bei einem DEFINE oder einem DELETE oder anderen Aktionen.
Erzeugt nicht "global" Events wie MODIFIED|DEFINED|ATTR|RENAMED|Deleted etc. auf die per notify reagiert werden kann?
Ich logge damit Änderungen. Falls ich mal versehentlich was wegschmeiße kann ich nachschauen.
Filelog:
DEF ./log/configChangeHistory.log global:(MODIFIED|DEFINED|ATTR|RENAMED|DELETED).*
Gruß Ralf
Grüße,
Danke für die Antworten.
Ich habe folgendes probiert
defmod di_ConfigChanges DOIF ([global:".*"]) (\
set TelegramBot message @xxxxxxxxx <b>Änderung erkannt:</B>\n$EVENT\
)
attr di_ConfigChanges do alwaysHeute Nacht, gegen 02:00 Uhr wurde ich geweckt ;D
Da erstelle ich einige notifty (at), die dann etwas abarbeiten. Diese werden "DEFINED" und "DELETED"
Das bringt uns betateilchen, "Aber wofür braucht man das wirklich?"
Das eigentliche Problem tritt bei Zeitschaltuhren auf. UZSU
Ändert man eine Einstellung der UZSU werden zu speichernde Änderungen angelegt.
Meine ganz ursprüngliche Frage ist:
- Wie speichere ich nur diese?
- Und wenn das "nur" nicht geht, wie erkenne ich, ob ausschließlich Änderungen der USZU zu speichern sind? Um dann ein (save) auszuführen und ansonsten zu warnen.
Zitat von: GammaTwin am 27 August 2025, 10:01:08Meine ganz ursprüngliche Frage ist:
- Wie speichere ich nur diese?
- Und wenn das "nur" nicht geht,
Das "nur" geht nicht. Ein "save" speichert immer die komplette Konfiguration, die FHEM gerade benutzt.
Aber ich glaube immer noch nicht, dass Du Deine Aufgabe nicht anders lösen kannst. Wie sehen denn die Änderungen aus, die UZSU anlegt und die gespeichert werden müssen? WO treten diese Änderungen auf?
Zitat von: GammaTwin am 27 August 2025, 10:01:08Da erstelle ich einige notifty (at), die dann etwas abarbeiten. Diese werden "DEFINED" und "DELETED"
Hallo,
warum nutzt Du für diesen Anwendungszweck nicht den Paramater -silent, dann bekommst Du auch kein ?
Grüße Jörg
Vielleicht, weil es gar nicht um das rote Fragezeichen geht?
Sondern darum, zu wissen, ob die Änderungen eine oder mehrere Änderungen an Zeitschaltuhren beinhalten.
Mich interessiert immer noch, wie fie Änderungen entstehen und ob dabei events erzeugt werden.
Es gibt FHEM-intern ein array, das die letzten 10 structural changes enthält. Man könnte regelmäßig prüfen, ob das array Elemente enthält und ob diese sich auf Zeitschaltuhren beziehen.
Aber ich glaube nach wie vor, dass sich die Aufgabe viel einfacher lösen lässt.
Leider fehlen nach wie vor qualifizierte Informationen, um das wirklich zu beurteilen.
Ich hatte in der Vergangenheit mal ein notify gebastelt, das Events abfängt um diese dann in ein LOG zu schreiben.
defmod system notify global:(INITIALIZED|SHUTDOWN|UPDATE|DEFINED.*|DELETED.*|MODIFIED.*|RENAMED.*|CANNOT_FORK) {fhem("trigger $SELF change: ".("$EVENT"))}
vielleicht kannst Du ja damit was anfangen
Grüße,
ich glaube, ich kann nicht mit Eurer Antwortgeschwindigkeit nicht mithalten :) Daher schon mal großen Dank.
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) (https://wiki.fhem.de/wiki/SmartVISU/Universelle_ZeitSchaltUhr_(UZSU))
Wenn man die UZSU in der smartVISU einstellt, passiert folgendes:
- dem Device wird ein Reading uzsu hinzugefügt - dabei passieren noch keine Änderungen
- FHEM reagiert mittels notify auf dieses Reading
define UZSU notify .*:uzsu:.* { UZSU_execute($NAME, $EVTPART1) } - Dabei entstehen in FHEM verschiedene Devices und ReadingGroups
Diese muss dann logischerweise speichern, damit die Zeitschaltuhr einen Neustart von FHEM übersteht.
Wenn also jemand anderes als ich die Zeitschaltuhren ändert, muss ich das ja irgendwie handhaben. Daher meine Frage.
Zitat von: betateilchen am 27 August 2025, 16:39:49Leider fehlen nach wie vor qualifizierte Informationen, um das wirklich zu beurteilen.
Passt die Erklärung?
Zitat von: GammaTwin am 27 August 2025, 18:54:15Diese muss dann logischerweise speichern, damit die Zeitschaltuhr einen Neustart von FHEM übersteht.
Ganz pragmatisch:
warum setzt Du nicht am Ende ein "save" ein?
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?
Zitat von: betateilchen am 27 August 2025, 16:39:49Es gibt FHEM-intern ein array, das die letzten 10 structural changes enthält. Man könnte regelmäßig prüfen, ob das array Elemente enthält ...
Das finde ich interessant. Dann wüsste man, ob etwas zu Speichern anliegt oder nicht.
Zitat von: mi.ke am 27 August 2025, 19:06:06Zitat von: GammaTwin am 27 August 2025, 18:54:15Diese muss dann logischerweise speichern, damit die Zeitschaltuhr einen Neustart von FHEM übersteht.
Ganz pragmatisch:
warum setzt Du nicht am Ende ein "save" ein?
Weil ich dann ja alles andere auch speichern würde. Da habe ich kein gutes Gefühl.
Zitat von: mi.ke am 27 August 2025, 18:52:35Ich hatte in der Vergangenheit mal ein notify gebastelt, das Events abfängt um diese dann in ein LOG zu schreiben.
defmod system notify global:(INITIALIZED|SHUTDOWN|UPDATE|DEFINED.*|DELETED.*|MODIFIED.*|RENAMED.*|CANNOT_FORK) {fhem("trigger $SELF change: ".("$EVENT"))}vielleicht kannst Du ja damit was anfangen
Zitat von: RalfRog am 26 August 2025, 16:14:38Erzeugt nicht "global" Events wie MODIFIED|DEFINED|ATTR|RENAMED|Deleted etc. auf die per notify reagiert werden kann?
Ich logge damit Änderungen. Falls ich mal versehentlich was wegschmeiße kann ich nachschauen.
Filelog:
DEF ./log/configChangeHistory.log global:(MODIFIED|DEFINED|ATTR|RENAMED|DELETED).*
Die beiden Sachen schaue ich mir auf jeden Fall mal an. Sind alle Dinge, das ? erzeugen damit erfasst?
Du denkst nach wie vor viel zu kompliziert.
Zitat von: betateilchen am 27 August 2025, 20:03:53Es 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.
Zitat von: betateilchen am 27 August 2025, 20:06:25Du denkst nach wie vor viel zu kompliziert.
Lass hören :D
Zitat von: GammaTwin am 27 August 2025, 20:11:30Ich 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.
Zitat von: GammaTwin am 27 August 2025, 20:04:43Weil 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?
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:
Zitat von: Otto123 am 25 Juli 2023, 12:46:27[...] 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.
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?
Zitat von: GammaTwin am 27 August 2025, 18:54:15Vielleicht 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) (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.
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.
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.
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.
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:
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?