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 (//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
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
ZitatWenn 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
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
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
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.
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