"Last unsaved structural changes" erkennen

[GammaTwin]

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.

[betateilchen]

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?

[JoWiemann]

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

[betateilchen]

wenn 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:

Die 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.

[RalfRog]

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.

Code Auswählen Erweitern

Filelog:
DEF ./log/configChangeHistory.log global:(MODIFIED|DEFINED|ATTR|RENAMED|DELETED).*

Gruß Ralf

[GammaTwin]

Grüße,

Danke für die Antworten.

Ich habe folgendes probiert

Code Auswählen Erweitern

defmod di_ConfigChanges DOIF ([global:".*"]) (\
 set TelegramBot message @xxxxxxxxx <b>Änderung erkannt:</B>\n$EVENT\
)
attr di_ConfigChanges do always
Heute Nacht, gegen 02:00 Uhr wurde ich geweckt
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.

[betateilchen]

Meine 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?

[JoWiemann]

Da 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

[betateilchen]

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.

[betateilchen]

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.

[mi.ke]

Ich hatte in der Vergangenheit mal ein notify gebastelt, das Events abfängt um diese dann in ein LOG zu schreiben.

Code Auswählen Erweitern

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

[GammaTwin]

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)

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
  Code Auswählen Erweitern
  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.

Leider fehlen nach wie vor qualifizierte Informationen, um das wirklich zu beurteilen.

Passt die Erklärung?

[mi.ke]

Diese muss dann logischerweise speichern, damit die Zeitschaltuhr einen Neustart von FHEM übersteht.

Ganz pragmatisch:
warum setzt Du nicht am Ende ein "save" ein?

[betateilchen]

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?

[GammaTwin]

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 ...

Das finde ich interessant. Dann wüsste man, ob etwas zu Speichern anliegt oder nicht.

Diese 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.

Ich hatte in der Vergangenheit mal ein notify gebastelt, das Events abfängt um diese dann in ein LOG zu schreiben.

Code Auswählen Erweitern

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

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.

Code Auswählen Erweitern

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?