Autor Thema: Logfile-Größe bei Sensoren reduzieren  (Gelesen 19027 mal)

Offline Willi

  • Sr. Member
  • ****
  • Beiträge: 593
Logfile-Größe bei Sensoren reduzieren
« am: 27 August 2013, 14:19:01 »
Hallo,

den ein oder anderen hat es schon genervt, dass die Oregon-Sensoren sehr gesprächig sind und damit das Filelog sehr groß wird.

Das führt leider auch dazu, dass die Anzeige der Gplots langsam wird.
Die Verwendung von event-on-change-reading ist leider keine Lösung, da man dann an Tagesgrenzen unschöne Plots hat.

Ich bin erst vor kurzem auf das Attribut event-min-interval aufmerksam geworden, dass dieses Problem löst.

Hierzu kann man event-min-interval verwenden, um festzulegen, dass Events nur alle x Minuten generiert werden. event-on-change-reading kann man verwenden, dass Änderungen trotzdem sofort bemerkt werden.

Ich habe das Vorgehen unter
http://www.fhemwiki.de/wiki/RFXtrx#FAQ:_Wie_bringe_ich_FHEM_dazu_nicht_alle_paar_Sekunden_den_Zustand_der_Sensoren_zu_loggen.3F
beschrieben

Grüße

Willi
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433
Gefällt mir Gefällt mir x 2 Liste anzeigen

Offline John

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1424
Antw:Logfile-Größe bei Sensoren reduzieren
« Antwort #1 am: 12 Oktober 2013, 12:06:38 »
Hallo Willi,
besten Dank für die Hinweise, das Thema beschäftigt mich derzeit auch.

Für folgendes Problem habe ich noch keine Lösung:

Wenn ein bestimmtes Reading A sich ändert, sollen zeitgleich auch andere Readings B mitgeschickt werden, die im Kontext mit A stehen.
Die anderen Readings ändern sich allerdings sehr häufig, so dass hier ein event-on-change-reading keinen Sinn macht,
event-min-interval liefert die Readings B nicht synchronisiert mit A.

Gibt es hierzu eine Lösung ?

John
CubieTruck CULV3 MAX HM  Logo  ESP8266 MQTT PID20 HourCounter MaxScanner KostalPiko

Offline Willi

  • Sr. Member
  • ****
  • Beiträge: 593
Antw:Logfile-Größe bei Sensoren reduzieren
« Antwort #2 am: 13 Oktober 2013, 14:16:02 »
Zitat
Wenn ein bestimmtes Reading A sich ändert, sollen zeitgleich auch andere Readings B mitgeschickt werden, die im Kontext mit A stehen.

Das verstehe ich so nicht. Kannst Du mal ein Beispiel geben?

Grüße

Willi
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

Offline John

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1424
Antw:Logfile-Größe bei Sensoren reduzieren
« Antwort #3 am: 13 Oktober 2013, 21:34:24 »
Ok, ein Beispiel

ich beschäftige mich mit dem PID-Modul.

Minütliche Berechnung führt zu minütlicher Bewertung von p,i,d Anteil.
Da im  Gleitkomma-Format, ändert sich zumindest i-Anteil praktisch permanent und auch andere davon abhängige Readings.
Event-On-Change hilft hier also nicht und auch event-min-interval ist keine Lösung, da ich die Daten
genau an einem wichtigen Ereignis in der Log-Datei sehen möchte.

Dann wenn der Stellausgang aktualisiert wird. Dann sollen all diese Wert in der Log-Datei erscheinen und nur dann.

Allgemein: mehrere  Readings sollen in Abhängigkeit von einem bestimmten Ereignis in der Log-Datei erscheinen.

John
CubieTruck CULV3 MAX HM  Logo  ESP8266 MQTT PID20 HourCounter MaxScanner KostalPiko

Offline Willi

  • Sr. Member
  • ****
  • Beiträge: 593
Antw:Logfile-Größe bei Sensoren reduzieren
« Antwort #4 am: 10 November 2013, 18:26:31 »
Sorry. Hatte Deine Antwort beim neuen Board übersehen.

Ich kümmere mich nur um die TRX-Module und nutze nur event-on-change und event-min-interval.
 
Wenn Du eine generelle Änderung an der Logik der Events haben möchtest, poste Deine Anfrage am besten in einem entsprechenden device übergreifenden Forum. Bin mir nicht sicher, aber FHEM/sonstges könnte passen.

Grüße

Willi
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

Offline Ralph

  • Full Member
  • ***
  • Beiträge: 431
  • ... mit RegExp auf Kriegsfuß
    • Ende des Internet
Antw:Logfile-Größe bei Sensoren reduzieren
« Antwort #5 am: 01 Dezember 2013, 13:09:40 »
Habe hierin
http://forum.fhem.de/index.php/topic,16988.msg110999.html#msg110999
mal eine Lösung für Fensterkontakte beschrieben.

Vielleicht könnt Ihr das modifizieren.
FHEM auf RaspberryPi3 + USB-CUL mit 4 FHT, 3 RM100, 2 HMS100, 5 CUL_WS, 5 CUL_FHTTK, 8 FS20 und 5 FS20V Spannungsüberwachungen

Offline joshi04

  • Full Member
  • ***
  • Beiträge: 291
Antw:Logfile-Größe bei Sensoren reduzieren
« Antwort #6 am: 03 Mai 2014, 18:02:34 »
Hallo Zusammen,

dieses Thema ist zwar auch schon etwas älter, aber vielleicht hilft es jemandem.

Bei Sensoren, die viele unterschiedliche Werte in jeweils eine neue Zeile schreiben, wollte ich erreichen, dass
- sich der Log verkürzt.
- nur ein neuer Eintrag eingetragen wird, wenn sich etwas geändert hat.
- ich das minimale Intervall festlegen kann.
- eine Zeile jeweils alle mir relevanten Werte enthält, was die Übersichtlichkeit im Log erhöht.
Das ganze sollte das Ziel haben, dass sich die Auswertung und Anzeige deutlich verkürzt.

Entsprechend hier meine Beispielkonfiguration für meinen Ofen in der Küche:
Zunächst die Definition:
define KU_Ofen TRX_WEATHER REVOLT_2c1f 1 1 0
attr KU_Ofen IODev Remote_RFXTRXUSB

Dann ein Dummy-Device, dass später die Werte aufnehmen wird und nur dann einen Eintrag generiert, wenn sich etwas ändert:
define KU_Ofen_Readings dummy
attr KU_Ofen_Readings event-on-change-reading state

Das Log-File:
define FileLog_KU_Ofen FileLog ./log/KU_Ofen-%Y.log KU_Ofen_Readings
attr FileLog_KU_Ofen logtype text

Das entsprechende Diagramm mit passendem Label:
define SVG_KU_Ofen SVG FileLog_KU_Ofen:Revolt:CURRENT
attr SVG_KU_Ofen alias Stromverbrauch Küche Ofen
attr SVG_KU_Ofen label "min $data{min1}W / max $data{max1}W / $data{currval1}W"

Und natürlich das wichtigste, das setzten des Readings mit einem Intervall von minimal 10 sec:
define KU_Ofen_Set at +*00:00:10 { my $KU_Ofen_I= ReadingsVal("KU_Ofen","energy_current",0) ;; my $KU_Ofen_pf= ReadingsVal("KU_Ofen","energy_pf",0) ;; my $KU_Ofen_P= ReadingsVal("KU_Ofen","energy_power",0) ;; my $KU_Ofen_cons= ReadingsVal("KU_Ofen","energy_total",0) ;; my $KU_Ofen_fr= ReadingsVal("KU_Ofen","frequency",0) ;; my $KU_Ofen_state= ReadingsVal("KU_Ofen","state",0) ;; my $KU_Ofen_V= ReadingsVal("KU_Ofen","voltage",0) ;; fhem("set KU_Ofen_Readings P: $KU_Ofen_P cT: $KU_Ofen_cons I: $KU_Ofen_I V: $KU_Ofen_V fr: $KU_Ofen_fr pf: $KU_Ofen_pf state: $KU_Ofen_state");;}


Heraus kommen dann Readings, die in etwas so aussehen:
KU_Ofen_Readings P: 0.8 W cT: 1.1700 kWh I: 0 A V: 236 V fr: 50 Hz pf: 1 state: EPOW: 0.8 ESUM: 1.1700
Ich muss leider gestehen, dass dieses nicht mir eingefallen ist, leider finde ich die Quelle nicht mehr. Der Auto möge es mir bitte verzeihen.
Netter wäre es sicherlich noch, wenn man das in eine entsprechende Funktion verpackt, dazu bin ich allerdings noch nicht gekommen.
Einbauen ließen sich sicherlich auch noch Rundungen o.ä., um die Daten zu glätten und noch weiter zu verschlanken.

Schöne Grüße,
John
NUC: 2xJeeLink, PCA301/TX35DTH; HueBridge, LivingColors; vair-monitor (CO2); HMLan, Winmatic, HM-CC-RT-DN, HM-TC-IT-WM-W-EU, HM-ES-TX-WM, HM-WDS10-TH-O, HM-ES-PMSw1-Pl, HM-SEC-SC-2, HM-SEC-SCo; AVM DECT 200; panStamp; smartVISU