FileLog Häufigkeit der Einträge beeinflussen?

[Dracolein]

So schwer ist das doch nicht, wenn man den Schlüsselworten folgt .

Versuch's mal mit

Code Auswählen Erweitern

attr 1wire_Temp1 event-on-change-reading temperature:0.2
event-min-interval bekommst du selbst hin, oder?

So schwer ist das doch nicht

Für Euch Pro´s ist das killefitz, für mich Newbie ist das high-end. Aber primär deswegen, weil ich mit aller Macht versuchen will zu verstehen, was ich da mache. Copy & paste bringt mir nur kurzfristig Hilfe.
Vorab: danke für Deine Hilfe!
event-min-interval stellt keine Herausforderung dar, dessen Syntax und Funktion habe ich begriffen. Auch die Kombination beider Attribute ist eine rückwirkend logische Idee, die Du dargestellt hast.

Nochmal in Zusammenfassung für mich selbst:
mit event-on-change-reading temperature:0.2 prüft das System permanent, ob eine Abweichung von 0,2°C zum aktuellen Messwert vorliegt und schreibt erst bei Überschreiten selbiger den neuen Messwert in das Reading "temperature".
PollingIntervall 300 ergibt einen Mindest"abstand" von 5 Minuten zwischen zwei Sensorabfragen.
Gleichzeitig wird zusätzlich mittels "event-min-interval 3600" 1x stündlich ein Logeintrag unabhängig von obigem Attribut erzwungen.

D.h. mein Logfile wird mindestens 1 Eintrag pro Stunde, maximal 20 Einträge pro Stunde enthalten. Letzteres müsste voraussetzen, dass alle 5 Minuten der Messwert um mindestens 0,2°C im Vergleich zum vorherigen Wert abweicht.

Mit der Bitte um Bestätigung oder Korrektur 

Mein Bier ist leer, gibts dafür auch ein FHEM-Modul? ...

[Beta-User]

Fast: Die Hysterese ist die Abweichung zum vorherigen letzten Wert, der ein event ausgelöst hatte... Da können einige Aktualisierungen dazwischen sein .

(Sonst würde bei schleichenden Änderungen zu spät/nie ein Event ausgelöst.)

(Und deine Darstellung entspricht fast dem, was jemand anderes in den im Wiki verlinkten Beiträgen als Zusammenfassung geschrieben hatte).

Der Punkt ist der: Bei keinem von uns ist das vom Himmel gefallen. Was mich etwas gewundert hatte, war, dass du offenkundig den Wiki-Artikel und die cref zu event-on... nicht schlicht mal angesehen zu haben scheinst. Damit (will sagen: mit diesem Eindruck, kann durchaus sein, dass das anders war, nur habe jedenfalls ich nichts davon gemerkt) machst du dir auf Dauer die Helfer kaputt...
Jedenfalls bei mir ist es so, dass ich viel gelesen und ausprobiert habe und darüber nachgedacht. Ist nicht immer der schnellste Weg, aber heute merke ich oft, das das hilfreich war (wenn auch mit einigen Umwegen).

[Dracolein]

Was mich etwas gewundert hatte, war, dass du offenkundig den Wiki-Artikel und die cref zu event-on... nicht schlicht mal angesehen zu haben scheinst. Damit (will sagen: mit diesem Eindruck, kann durchaus sein, dass das anders war, nur habe jedenfalls ich nichts davon gemerkt) machst du dir auf Dauer die Helfer kaputt...

Dem möchte ich der Vollständigkeit halber klar widersprechen  da ich mehrere Versuche erfolglos getestet hatte. Es lag letztlich an meiner falschen Syntax. Ich hatte aus dem Wiki-Beispiel die eckigen Klammern übernommen UND bei der Temperatur anstelle eines Punktes ein Komma (0,2) verwendet.
Die Tipperei hier kostet mich mehr Zeit, als einzelne Versuche mit try&error, soviel zu meiner Verteidigung.   

Nochmals Danke und mit der Bitte um Nachsicht.

[Beta-User]

Kein Ding...

Was wichtiges gelernt: Eckige Klammern stehen für optionale Angaben, sind dann wegzulassen, wenn man die Option nutzt.
Und das mit dem Punkt wird dir auf andere Weise noch mehrfach über den Weg laufen .

[DS_Starter]

@dracolein ... !!! Achtung !!!

Diese, deine Aussage

Gleichzeitig wird zusätzlich mittels "event-min-interval 3600" 1x stündlich ein Logeintrag unabhängig von obigem Attribut erzwungen.

ist grundlegend falsch.

Das Attribut event-min-interval erzwingt nichts !!  sondern vielmehr ... ich zitiere:

Ein Event wird nur dann generiert, falls seit dem letzten Auftreten des gleichen Events mindestens minInterval Sekunden vergangen sind

Das heißt es können auch 3 Stunden vergangen sein.

Wenn du etwas erzwingen willst, nutze addLog entweder direkt eingebaut in DbLog oder als separaten Befehl wie z.B. im Wiki beschrieben: https://wiki.fhem.de/wiki/Plot-Abriss_vermeiden

Ich möchte nur vermeiden, dass sich gleich zu Anfang etwas im Kopf falsch festsetzt 

Grüße,
Heiko

[Beta-User]

Danke für die Klarstellung. Hier ist das kein größeres Problem (jedenfalls, solange der Sensor was liefert), da dieser alle 5 Min abgefragt wird. Spätestens nach 20 Min. landet also was im Log.

[Dracolein]

Danke für den Hinweis, ich frage zum Thema addlog nochmal zum Verständnis nach:

Internals:
   CFGFN     
   COMMAND    {addLog("1wire_Temp1","temperature")}
   DEF        +*01:00 {addLog("1wire_Temp1","temperature")}
   FUUID      5df8bfe2-f33f-4dec-2b35-9214e90eb1be18d2
   NAME       add_Logentry1
   NR         358
   NTM        13:47:20
   PERIODIC   yes
   RELATIVE   yes
   REP        -1
   STATE      Next: 13:47:20
   TIMESPEC   01:00
   TRIGGERTIME 1576586840.50867
   TRIGGERTIME_FMT 2019-12-17 13:47:20
   TYPE       at
   READINGS:
     2019-12-17 12:47:20   state           Next: 13:47:20
Attributes:
   room       Logfiles

Habe das obige mit

Code Auswählen Erweitern

define add_Logentry1 at +*01:00 {addLog("1wire_Temp1","temperature")}
angelegt.  Im Reading sehe ich brav den nächsten geplanten Event in knapp einer Stunde.  Im Code habe ich dem addLog-Befehl mitgeteilt, welches Device mit welchem Reading es in ein Log eintragen soll. Sprich, Zeit und Inhalt sind definiert. Aber woher weiß "addLog" in welches Logfile der Eintrag geschrieben werden soll ? (Das FileLog-Device "Log_RaumtempEG" existiert bereits). Der Zusammenhang ist mir unklar, ich hätte nun erwartet, dass in obiger Konfiguration dazu Bezug genommen werden muss.

[Frank_Huber]

Danke für den Hinweis, ich frage zum Thema addlog nochmal zum Verständnis nach:

addlog ist ein set Befehl für ein dblog device.

falls alsi deine Log-Datenbank z.B. "logDB" benannt ist machst Du so einen Logeintrag:

Code Auswählen Erweitern

(set logDB addLog 1wire_Temp1:temperature)

falls Du über DbLogExclude das reading "temperature" ausgenommen hast muss noch ein " !useExcludes" an den Befehl dran.

[Dracolein]

Aha, das war mir so nicht klar. Danke.

[Beta-User]

@Frank_Huber: Er bezieht sich mit einiger Wahrscheinlichkeit auf https://wiki.fhem.de/wiki/Plot-Abriss_vermeiden#Implementierung...

Das at löst einen trigger-Befehl aus. Schau bitte in der commandref mal nach "trigger". (Auch FileLog ist nur ein Eventhandler...)

(Nur für Plots gab's übrigens auch noch logproxy: https://wiki.fhem.de/wiki/LogProxy#M.C3.B6gliche_.3Coptions.3E, und für statistische Zwecke braucht man uU. tatsächlich aufbereitete Werte, die liefert aber z.b. das Modul statistics => Ich komme zurück auf das, was ich zuvor schon zu "aufbereiteten" Werten geschrieben hatte: man braucht sowas in der Regel eher nicht bzw. sollte sich genau überlegen, warum man etwas braucht...)

[Frank_Huber]

@Frank_Huber: Er bezieht sich mit einiger Wahrscheinlichkeit auf https://wiki.fhem.de/wiki/Plot-Abriss_vermeiden#Implementierung...

Danke! Das ist mir neu.
d.h. damit kann man nach Anlegen der Sub in der myUtils in jedes Log-Device (auch FileLog) einen Eintrag erzwingen.

[Beta-User]

Ja.

Nur (wie gesagt): Mit LogProxy kann man (im Prinzip) dasselbe erreichen, ohne die Nebenwirkung, dass auch alle anderen Eventhandler ein (unnötiges) Event bekommen...
LogProxy funktioniert auch mit beiden Logging-Varianten (FileLog und DBLog).
(Wenn man nicht SVG iVm. DBLog nutzt, hat man vermutlich noch mehr Optionen, aber z.B. mit Grafana, das scheinbar sehr gut ist, kenne ich mich nicht aus).

[Dracolein]

Um es abzukürzen, wenn ich das hier ( https://forum.fhem.de/index.php/topic,106343.msg1002644.html#msg1002644 ) gelöst habe, erübrigt sich die gesamte Mühe dieses Threads.

Aber dafür muss ich heute abend erst ein Backup laufen lassen, bevor ich herumprobiere.