ENOcean Automatisches anlegen von Tastern erzeugt zu viele unkontrolierte Logs

[LHBL2003]

Guten Morgen,

ich habe in den letzen tage für zwei Stockwerke meine Eltako Module im BUS eingerichtet. FHEM ist auch so nett und findet die Taster-Eingabemodul FTS14EM automatisch, was ich sehr zu schätzen weis.

Allerdings sorgt das automatische anlegen auch dafür, das FHEM grotten langsam wird. (Webseitenaufrufzeiten von mehreren Sekunden.)
Der Grund war mir sofort klar, nachdem ich die Massen an Logfiles gesehen habe, welche größenordnungen zwischen 10 und 50 MB aufweißten.

Also mal ebend über das ganze System 3 Befehle abgesetzt und schwups läuft das System wieder wie geschmiert.

Code: [Auswählen]

attr .* event-on-change-reading .* (Nur Werteänderungen Protokollieren)

Code: [Auswählen]

attr .* event-min-interval .*:43200 (Alle 12 Stunden den aktuellen Wert Protolollieren, damit mindestens ein Eintrag im aktuellen log vorhanden ist.)

Code: [Auswählen]

attr .* nrarchive 3 (Maximal 3 Logs, behalten je nach Definition des Logfile Namens, 3 Jahre, Monate oder drei Tage, wobei in der Regel 3 Tage föllig ausreichend sind, außer für Statistiken. Zudem sind Tages Logs zu beforzugen um die Dateigröße gering zu halten)

Ich weiß nicht wer die Grundmodule für ENOcean entwickelt. Wobei dies eigentlich auch ein Stabilitäts Thema für das gesammte FHEM System ist.
Daher fasse ich meine Frage mal allgemein und beziehe mich aber auf den Bereich ENOcean sowie das gesammte FHEM Grundsystem.

Besteht nicht die Möglichkeit diese drei Attribute zwangsweise für jegliche FHEM Module vorzudefinieren als Eigenschutz für das FHEM System?
Denn meine Erfahrung in den letzten jahren hat folgendes gezeigt. FHEM ist nur langsam, wenn man Module / Devices anlegt, welche Logs enthalten die wiederum unkonfiguriert herrumirren. Denn in einigen Dokus steht zwar drinn, dass man solch Werte setzen sollte, aber warum wird dies nicht als Standard vom System vorgegeben?

Zudem sorgt z.B. "nrarchive 3" dafür, dass das FHEM System niemals voll läuft. Es ist ja keine Pharma Anlage die Daten von den letzten 10 Jahren archivieren muss.

...
ich wollte gerade im Config File "fhem.cfg" nachschauen wie der Logfile namesaufbau aussieht:

Code: [Auswählen]

attr global logfile ./log/fhem-%Y-%m-%d.logum darauf hinzuweisen, dass somit in der regel für jeden tag ein eigenes logfile vorhanden ist und somit die größe der logs und die zugrifszeiten nicht explodieren.

Dabei ist mir aufgefallen, das hier auch ein eintrag für

Code: [Auswählen]

attr global nrarchive 3 enthalten ist.

Wäre es nicht sinvoll bei der Basis Installation von FHEM auch festzulegen?

Code: [Auswählen]

attr global event-on-change-reading .*
attr global event-min-interval .*:43200
Ich müsste jetzt erst mal ein Backup machen, bevor ich ausprobiere ob das möglich ist. Nicht das ich mein System damit Crash.

Gruß und vielen Dank für eure Rückmeldungen.

[LHBL2003]

Hi,

Heute war übrigens wieder einer dieser Tage wo ich 22 neue Logfiles mit 30MB bekommen habe. (von 0 Uhr bis 7:30)
Da ich gestern neue Module eingebaut hatte und diese fleißig wie erwünst in Fhem auftauchten, aber ein schlechtes Logging verhalten haben. Wie oben beschrieben.

[LHBL2003]

Also ich habe es mal versucht die beiden Einträge in die fhem.cfg hinzuzufügen.

Code: [Auswählen]

#Hinzugefügt, um zu verhindern, dass neu angelegte elemente alle paar sekunden Loggen ohne Statusänderung
attr global event-on-change-reading .*
attr global event-min-interval .*:43200

Dabei bekomme ich aber folgende Fehlermeldung:

ERROR:
global: unknown attribute event-on-change-reading. Type 'attr global ?' for a detailed list. global: unknown attribute event-min-interval. Type 'attr global ?' for a detailed list.


Scheinbar bezieht sich das global thema auf das FHEM log und nicht auf die Device Logs.
Also muss ich doch händisch immer dafür sorgen das alles stimmt oder ein Timer anlegen der einmal am Tag dafür sorgt, das dies überall hinterlegt ist.
Denn man denkt ja nicht immer daran dies zu hinterlegen.
Bei 22 Logfiles sorgt es nähmlich schon dafür das teilweise die FHEM Seite kaum aufrufbar ist.

[MadMax-FHEM]

Es gibt (wie der Fehler sagt) kein Attribut event-on-change-reading beim Device global.

Die vom TE genannten "Befehle": auf ALLES event-on-change etc. "blind" anzuwenden halte ich für naja, "Unfug"...

Man kann die Attribute schon einsetzen aber dann gezielt wo nötig/sinnvoll...

Du kannst für autocreate auch das Anlegen von Logfiles "unterbinden"...
EDIT: https://fhem.de/commandref_DE.html#autocreate

Du kannst nicht benötigte/erwünschte FileLog-Devices disablen oder löschen...

Gruß, Joachim

[Wzut]

Code: [Auswählen]

defmod n_eocr_global notify global:DEFINED.* attr $EVTPART1 event-on-change-reading .*

[MadMax-FHEM]

Code: [Auswählen]

defmod n_eocr_global notify global:DEFINED.* attr $EVTPART1 event-on-change-reading .*

Jep, setzt jedes neu angelegte Device "unter Quarantäne" bzgl. "zu viele Events"...

Aber dann evtl. gezieltes Nachbearbeiten nicht vergessen, sonst wundert man sich am Ende, wenn Logs "albern" aussehen oder so manch ein erwarteter "Automatismus" nicht anläuft, weil der entsprechende (öfter benötigte) Trigger fehlt

Gruß, Joachim

[LHBL2003]

Hi, also das logging für Auto create zu deaktivieren ist schon mal ein guter Plan.

Was macht dieser genau?
defmod n_eocr_global notify global:DEFINED.* attr $EVTPART1 event-on-change-reading .*

da sind einige Dinge enthalten die sehe ich zum ersten Mal.

Gruß Denis

PS: Ich bin dennoch der Meinung das Logs nicht ungehindert dauerhaft alles wiederholt loggen sollten. Das ist sicherlich eine in 99% unnötige Belastung für das System. Das ist ja bei Thermostate und Co. nicht anders.
Wenn man alle Stunde oder alle 10 min. Ein Referenz Wert aufnimmt für die vielleicht mal genutzte Kurvendarstellung dann sollte das doch in der Regel ausreichen. Und in Sonderfällen kann der Bediener es verfeinern. Aber im Standard jedes Signal zu loggen ohne Werteänderung alle Sekunde ist doch ebenso „Unfug“ oder sehe ich das falsch? Mir fehlt halt der Sinn dahinter warum der Standard so Extrems loggen soll.

Gruß Denis

Lasse mich natürlich eines besseren belehren.
Schon mal danke für den auto crate logg disable Tipp
Und dem Defmod Punkt den ich mir noch genauer anschauen muss. (Am Wochenende)