FileLog Häufigkeit der Einträge beeinflussen?

[Dracolein]

Hallo zusammen,

ich finde keine Lösung zu meiner Frage, wie ich die Häufigkeit der Einträge eines FileLog-Devices beeinflussen kann.
Sprich, das Gerät, z.B. ein Raumsensor, sendet im Minutentakt einen aktualisierten Wert, welchen das FileLog-Dev auch prima mitloggt. Aber es wäre völlig ausreichend, wenn dieser Wert z.B. lediglich alle 60 Minuten in das Logfile geschrieben würde.

Das Attribut "event-min-intervall" passt hier nicht so richtig, da ich erstens das Gerät und weniger das FileLog damit beeinflusse und zweitens - falls ich es nutze - meine Echtzeitanzeige auf der Tablet UI auch nur noch alle 60 Minuten aktualisiert würde...

Gibts da einen Trick?

[Waldmensch]

Im speziellen wüsste ich nichts, du könntest aber mit Event-on-change zumindest nur dann loggen, wenn der Wert sich ändert.


Gesendet von iPhone mit Tapatalk

[Dracolein]

Hm, was wäre mit einem Workaround ? Ich stecke in Linux / FHEM einfach nicht gut genug drin.

Ich stelle mir z.B. ein Dummy-Device vor, welches den Parameter - hier des eigentlichen Raumsensor-Device in einem frei konfigurierbaren Zyklus (= konkret alle 10 Minuten z.B.) abruft. Dieses Dummy-Device könnte ich dann alternativ per FileLog protokollieren und hätte "ab Werk" exakt alle 10 Minuten einen Protokolleintrag.

[Beta-User]

MMn. sollte man diese Art der "Verbesserung" der Datenbasis lassen. Das führt nur irgendwann zu Problemen, weil man das vergißt und irgendwann nicht mehr mit den Ausgangsdaten arbeitet.

Warum baust du keine Hysterese (threshold) in deine Events am Device ein und gut ist? Ich finde es ok, wenn dann viele Werte kommen, wenn sich auch (ernsthaft) was ändert. Kannst du immer noch mit min-interval ergänzen: https://wiki.fhem.de/wiki/Event-on-change-reading#Wechselwirkungen. So siehst du in Plots auch noch Zusammenhänge mit anderen Events (Fenster-offen), die sonst ggf. "verwaschen".

Tendenziell solltes du davon ausgehen, dass es für Standardprobleme auch bereits eine Lösung gibt und die Energie darauf verwenden, diese zu suchen, statt was neues eigenes zu bauen.

Just my2ct.

Beta-User

[Frank_Huber]

Du könntest auf dblog umstellen, da bist Du flexibler.

[herrmannj]

Ja wobei die Ausgangslage gut analysiert ist.

Geht leider nicht out of the Box und die Idee ist schon richtig. bisher hat keiner (ich schließe mich ein) die Zeit gefunden dass umzusetzen.

Was du machen kannst:
Erstelle einen Dummy.
Dort richtest du User Reading für die Werte ein die dich interessieren.
Dort die event-on... Und das loggen.

Dann hast du beides (das device mit hoher Auflösung und den Dummy zum loggen)

[Dracolein]

Tendenziell solltes du davon ausgehen, dass es für Standardprobleme auch bereits eine Lösung gibt und die Energie darauf verwenden, diese zu suchen, statt was neues eigenes zu bauen.

Das versuche ich. Meine simpelsten Problemchen sind sicherlich schon 100fach diskutiert und gelöst worden. Sehr viele Fragen konnte ich mir mit Hilfe der Suchfunktion schon selbst beantworten.
Allerdings ist dieses Forum so gigantisch groß und er Content letztlich sehr komplex, dass ich mit meinen beschränkten Fähigkeiten häufig die Zusammenhänge nicht mehr begreife. Das betrifft primär die Abwandlung von gefundenen Codeschnipseln z.B.   

MMn. sollte man diese Art der "Verbesserung" der Datenbasis lassen. Das führt nur irgendwann zu Problemen, weil man das vergißt und irgendwann nicht mehr mit den Ausgangsdaten arbeitet.

Das hatte ich anderweitig, ich glaube sogar auch von Dir, bereits gelesen. Deswegen möchte ich eigentlich vermeiden mit event-min-intervall im "echten" Sensor-Device etwas zu modifizieren, was ich in einem anderen FileLog-Device bräuchte. Daher dieser Thread 

Warum baust du keine Hysterese (threshold) in deine Events am Device ein und gut ist? Ich finde es ok, wenn dann viele Werte kommen...

Der Hintergrund meiner Versuche ist es, die Schreibzugriffe auf die SD-Karte nach Möglichkeit zu reduzieren. Hier im Beispiel beim Raumtemperaturfühler benötige ich keine Protokollierung im 60-Sekunden Takt, da dies Protokoll lediglich Basis für ein Chart in Touch UI ist. Theoretisch würde es ausreichen alle 15 Minuten einen Eintrag dafür zu generieren.
Nur soll weiterhin der aktuelle Istwert des 1Wire Sensors minütlich aktualisiert ebenfalls in Touch UI dargestellt bleiben unabhängig vom Chart.



edit:
Hupsala, die weiteren Postings habe ich erst jetzt gesehen.
Okay, Dummy erstellen, user reading einrcihten und event-on konfigurieren.

Habe heute abend damit erstmal Grundlagen zu recherchieren
schaun wir mal, wo ich rauskommen werde.

[Waldmensch]

Das filelog auf die System SD Karte zu schreiben ist sehr gefährlich. Du solltest dafür einen separaten USB Stick oder ein nfs share auf einem NAS nutzen. Ich habe schon ohne filelog 2 SD Karten ,,verheizt" seitdem nutze Ich dblog auf einer externen mariadb und erstelle jede Nacht ein Backup des kompletten opt Verzeichnisses auf ein externes Share.


Gesendet von iPhone mit Tapatalk

[Beta-User]

Mein Kommentar war auch nicht negativ gemeint (sonst hätte ich den Link zu weiterführenden Infos weggelassen und nur rtfm gemurmelt...), das Problem (von der theoretischen Seite her) kann ich durchaus nachvollziehen (einschl. der Furcht vor SD-Karten-Schredderei, die mich selbst auch letztlich zu anderer Hardware getrieben hat...).

@Waldmensch:
Da hat Wernieman in dem anderen Thread aber auch was dazu geschrieben von wegen: Wenn sich der Stick weghängt, geht auch nichts mehr... Und ein NAS hat auch nicht jeder.
(Ich kann das alles nur bedingt verifizieren, aber im Ergebnis scheint es mir so zu sein, dass die Empfehlung für Leute, die "nur wegen ein bißchen Hausautomatisierung" nicht gleich eine komplette IT-Infrastruktur aufbauen wollen, wohl sein sollte: nimm was anderes wie einen Pi (irgendwas, das ein vernünftiges wear-leveling für seine Haupt-Datenträger kann)... oder mach jedenfalls häufig ein Backup und übe, das bei Bedarf dann auch schnell zu nutzen!)

@herrmannj:
Vielleicht sollte man Rudi vorschlagen, (inhaltlich) genau diese "event-on.."-Attribute auch bei FileLog-Geräten setzen zu können?

Ich bin allerdings insgesamt noch nicht überzeugt, ob das Grundproblem wirklich außerhalb der Theorie ernsthaft besteht. Entweder eine Änderung ist relevant, dann macht es mMn. tendenziell auch Sinn sie zu protokollieren (wenn überhaupt, aber das ist eine andere Frage), oder eben nicht. Damit ist die Anzeige - wo auch immer - immer noch genau genug, und ob ein Problem vorliegt (Sensor ausgefallen?) sollte man ggf. am timestamp erkennen können (ungeprüft, aber soweit ich das im Kopf habe).

Deswegen möchte ich eigentlich vermeiden mit event-min-intervall im "echten" Sensor-Device etwas zu modifizieren, was ich in einem anderen FileLog-Device bräuchte.

Sorry, aber das verstehe ich nicht. Du loggst doch hoffentlich nicht Daten doppelt? (Man kann mit SVG dann durchaus Daten aus mehreren LogFiles mischen und in einem Graphen darstellen!)

Wenn es so gemeint war, dass du die Echtdatenänderung brauchst, um darauf zu reagieren (mit was anderem als FileLog), ist es m.E. eher eine Frage der Festlegung der Hysterese. Meistens ist sowieso schon der Meßwert/bzw. der Sensor nicht kalibriert (aber genau genug), so dass auch entsprechende Grenzwertfestlegungen (z.B. für ein THRESHOLD-Device) eben "relativ" sind.

[Dracolein]

Das filelog auf die System SD Karte zu schreiben ist sehr gefährlich. Du solltest dafür einen separaten USB Stick oder ein nfs share auf einem NAS nutzen. Ich habe schon ohne filelog 2 SD Karten ,,verheizt" seitdem nutze Ich dblog auf einer externen mariadb und erstelle jede Nacht ein Backup des kompletten opt Verzeichnisses auf ein externes Share.


Gesendet von iPhone mit Tapatalk

Deswegen diskutieren wir gerade parallel hier:
https://forum.fhem.de/index.php/topic,106343.0.html




edit:

Sorry, aber das verstehe ich nicht. Du loggst doch hoffentlich nicht Daten doppelt? (Man kann mit SVG dann durchaus Daten aus mehreren LogFiles mischen und in einem Graphen darstellen!)

Also um es plastisch zu machen - mit der Bitte um Verständnis für mein Anfängerlevel:

Ich habe per GPIO4 einen 1Wire Temperatursensor angeschlossen und in FHEM eingebunden, welcher mir derzeit mittels Attribut "pollinginterval" alle 60 Sekunden einen Wert ausgibt. Selbigen Wert habe ich in meiner Touch UI als "aktuelle Raumtemperatur" dargestellt.
Nun war mein Wunsch, diese Temperatur grafisch über den Tag darzustellen in einem Chart, was prinzipiell auch schon gut funktioniert.
Allerdings halt mit der Thematik, dass es mir alle 60 Sekunden einen Wert ins Log schreibt.
Ein SVG-Chart habe ich dafür nie definiert in FHEM. Ich nutze ein FileLog und das FTUI-Modul "Chart" zur grafischen Darstellung.

Mein "Problem" besteht lediglich darin, weiterhin aktuelle Raumtemperaturen angezeigt zu bekommen, die nicht 10 oder 15 Minuten alt sind und gleichzeitig die FileLog-Einträge auf das nötigste zu reduzieren.

[Beta-User]

Ebend: Die Frage ist, was die aktuelle Raumtemperatur ist .

Setzt du eine Hysterese von 0.2°C auf den Wert, ist er mMn. immer noch "aktuell", solange er sich innerhalb der Bandbreite bewegtt. Also sagen wir as Beispiel: Messung beginnt bei 22.0°C. Dann wird ggf. erst ein Event erzeugt, wenn 22.21°C sind (oder 21.7999°C). Mir reicht es zu wissen, dass es "um die 22°C" hat; wie lange das schon der Fall ist, ist mir eigentlich nicht so wichtig, solange es sich nicht wesentlich ändert, das ist mir "aktuell" genug... Dazu alle Stunde ein "Zwangsupdate", damit es keine Abrisse in plots gibt und leichter geprüft werden kann, dass der Sensor nicht "weg" ist.

Die DS18B20 haben übrigens auch eine Toleranz von 0.5°C (?), und sind zwar "genau", aber eben mit dieser "Normalverschiebung", die sich aus der Grundtoleranz ergibt (ich messe - über einen MySensors-Arduino - in der Regel sowieso nur 1/4 Grad genau, dann geht das auch wesentlich schneller). (Und GPIO-Nutzug am PI ist auch so ein Thema, das ich persönlich als nogo ansehe (schon klar, dass man auch darüber lange diskutieren kann)...)

[Icinger]

Im speziellen wüsste ich nichts, du könntest aber mit Event-on-change zumindest nur dann loggen, wenn der Wert sich ändert.

Ist doch eigentlich ganz easy mit Bordmittelbn zu bewerkstelligen:
Ein statistics-Device, attr singularreadings setzen und einfach dann den

Code Auswählen Erweitern

statTemperatureHourLast
loggen

lg, Stefan

[herrmannj]

@herrmannj:
Vielleicht sollte man Rudi vorschlagen, (inhaltlich) genau diese "event-on.."-Attribute auch bei FileLog-Geräten setzen zu können?

Ja, wobei es auch fair wäre gleich den passenden Patch zu liefern... Zeitfrage halt ..

[Dracolein]

Ist doch eigentlich ganz easy mit Bordmittelbn zu bewerkstelligen:
Ein statistics-Device, attr singularreadings setzen und einfach dann den

Code Auswählen Erweitern

statTemperatureHourLast
loggen

lg, Stefan

Hi Stefan,
ich habe mir den Wiki Eintrag zum statistics Device durchgelesen und etwas herumprobiert, aber ich verstehe nicht ganz, was ich tue.

Code Auswählen Erweitern

define StatistikDevice statistics 1wire_Temp1
bringt mir ein statistics-Device und zusätzlich in meinem Raumsensor-Device, namentlich 1wire_Temp1, 3 neue Readings, dessen Bezeichnung (stat[...|day / ... month / year... oder so) mir komisch erscheinen. Zuletzt fehlt mir das Verständnis, wie ich einem erstellten Reading sage, was es denn überhaupt darstellen soll.
Nachdem ich das StatistikDevice zunächst wieder gelöscht hatte, waren die neu erstellen Readings im 1wire_Temp1 geblieben; ich löschte sie manuell erstmal wieder.

Ebend: Die Frage ist, was die aktuelle Raumtemperatur ist .

Setzt du eine Hysterese von 0.2°C auf den Wert, ist er mMn. immer noch "aktuell", solange er sich innerhalb der Bandbreite bewegtt. Also sagen wir as Beispiel: Messung beginnt bei 22.0°C. Dann wird ggf. erst ein Event erzeugt, wenn 22.21°C sind (oder 21.7999°C). Mir reicht es zu wissen, dass es "um die 22°C" hat; wie lange das schon der Fall ist, ist mir eigentlich nicht so wichtig, solange es sich nicht wesentlich ändert, das ist mir "aktuell" genug... Dazu alle Stunde ein "Zwangsupdate", damit es keine Abrisse in plots gibt und leichter geprüft werden kann, dass der Sensor nicht "weg" ist.

Inhaltlich bin ich bei Dir, das würde völlig ausreichen. Selbst 0,5°C als Hysterese wären ausreichend, stimmt. Auch für diese Lösung fehlt mir das Verständnis für die technische Umsetzung in FHEM.  Braucht es dazu das THRESHOLD-Modul oder lässt es sich mithilfe eines Attributs im Device lösen?

list 1wire_Temp1:

Code Auswählen Erweitern


Internals:
   DEF        28-0114504011aa
   FUUID      5ddff6c1-f33f-4dec-8c3d-60f53c43981b8e6e
   NAME       1wire_Temp1
   NR         27
   NTFY_ORDER 50-1wire_Temp1
   STATE      T: 24.25
   TYPE       GPIO4
   OLDREADINGS:
   READINGS:
     2019-12-16 07:19:39   failures        0
     2019-12-16 18:58:01   state           T: 24.25
     2019-12-16 18:58:01   temperature     24.25
   fhem:
     interfaces temperature
   helper:
     _98_statistics StatistikDevice
Attributes:
   DbLogExclude .*
   alias      RaumtempEG
   pollingInterval 300
   room       Homekit,Sensoren


Und ja, 24°C sind gerade richtig, ich habe den Kamin an  . Der läuft "zu Glück" auch ohne Pearl- und FHEM-Kenntnisse 

[Beta-User]

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?

@hermannj:
Bin selbst auf DBLog, von daher ist das mit LogFile nicht meine Baustelle, zumal Rudi gerne nachhakt, welches Problem denn mit einem patch gelöst werden soll. Hier m.E. mal wieder: keines...

Und das mit statistics kommt "in den Hinterkopf", das würde auch bei DBLog helfen.
(Irgendwie habe ich es immer geschafft, mich um das Ding rumzudrücken; vermutlich fehlt mir eine Art Musterlösung für ein paar Standardfälle (ich habe aber auch noch nicht intensiv danach gesucht).