Diätplan für Logdatei auf Basis event-on-change-reading gesucht

[WiKa]

Hallo zusammen,

seit einiger Zeit versuche ich die Logeinträge meiner Sensoren auf ein sinnvolles Maß zu reduzieren, und nur bei Änderungen einen Logeintrag vorzunehmen.

Bei meinen Temperatursensoren (T und TH-Sensoren) klappt das auch hervorragend.

Einer der Sensoren (TH03_OUT) liefert folgende readings:
battery ok   
humidity 75   
state T: 10.1 H: 75 BAT: ok   
temperature 10.1   

mit folgendem Eintrag in der cfg werden nur Änderungen der Werte T und H (wahrsch. auch BAT) im Log vermerkt:

Code Auswählen Erweitern


attr TH03_OUT event-on-change-reading state
#Log
define FileLog_TH03_OUT FileLog /var/media/ftp/Prolific-UsbFlashDisk-01/log/TH03_OUT-%Y.log TH03_OUT:T:.*
#Logeintrag
TH03_OUT T: 10.2 H: 75 D: 6.0 BAT: ok


Soweit alles klar. Prima Log und prima Plot.

Jetzt zu meinem Problemsensor (Energiemonitor CM160).

Dieser liefert folgende readings:
battery   ok   
energy_current 267.79 W   
energy_total 362.6226 kWh
state ECUR: 267.79 ESUM: 362.6226 BAT: ok

mit folgendem Eintrag in der cfg werden nur Änderungen der Werte ECUR und ESUM (wahrsch. auch BAT) im Log vermerkt:

Code Auswählen Erweitern


attr CM160_4ec2 event-on-change-reading state
#Log
define FileLog_CM160_4ec2 FileLog /var/media/ftp/Prolific-UsbFlashDisk-01/log/CM160_4ec2-%Y.log CM160_4ec2:ECUR:.*
#Logeintrag
CM160_4ec2 ECUR: 367.004 ESUM: 362.4041 BAT: ok


Auch hier prima Log und prima Plot.

Und jetzt der Haken:
ESUM (Gesamtverbrauch) ändert sich natürlich mit jeder Meldung des Sensors, ergo leidet das Log an zunehmendem Übergewicht.

Bisher versucht:
e-o-c-r statt auf state auf energy_current angewandt - Nur noch Änderungen werden im Event monitor angezeigt, aber meine Logdatei bekommt eine Nulldiät und mein Plot bleibt leer.
Im Event monitor wird danach auch nur noch CM160_4ec2 energy_current: 367.004 W angezeigt (und - nach Änderung der Log-Parameter - im Log eingetragen).
Logischerweise hat mein Plot da kein Futter mehr.
Ich kann natürlich ebenfalls den Plot ändern und habe dann die Werte, die ich mir bisher auch darstellen lasse.

Mit dieser Lösung müsste ich aber auf die Werte ESUM und BAT im Log verzichten.

Meine laienhafte Vorstellung:
Mit e-o-c-r nur den Wert ECUR aus state auswerten, jedoch den vollständigen Inhalt von state an das Log übermitteln.

Ich hoffe, jemand von euch kann mir bei der Lösung des Problems helfen.

VG
WiKa

[Willi]

Und jetzt der Haken:
ESUM (Gesamtverbrauch) ändert sich natürlich mit jeder Meldung des Sensors, ergo leidet das Log an zunehmendem Übergewicht.

Bisher versucht:
e-o-c-r statt auf state auf energy_current angewandt - Nur noch Änderungen werden im Event monitor angezeigt, aber meine Logdatei bekommt eine Nulldiät und mein Plot bleibt leer.

Mit

define FileLog_CM160_4ec2 FileLog /var/media/ftp/Prolific-UsbFlashDisk-01/log/CM160_4ec2-%Y.log CM160_4ec2:ECUR:.*

loggst Du nur den State.

Ich würde event-on-change-reading auf energy_current und battery anwenden und den Filelog so abändern, dass diese auch geloggt werden, aber state nicht. In etwa so:

define FileLog_CM160_4ec2 FileLog /var/media/ftp/Prolific-UsbFlashDisk-01/log/CM160_4ec2-%Y.log CM160_4ec2:[energy_current|battery].*

Die Plots kannst Du ja auch mit energy_current machen.

Mein Modul TRX_WEATHER nutzt die normale Funktionalität von event-on-change-reading, welchen in fhem.pl implementiert ist. Ich frage mich allerdings, ob das wirklich etwas bringt. Hast Du wirklich Zeitpunkte, bei denen sich energy_current nicht ändert?

event-on-change-reading (nicht von mir) vergleicht einfach, ob sich der String geändert hat. Ein selektiver Vergleich ist da m.E. nicht möglich.

MfG Willi

[WiKa]

Mit
define FileLog_CM160_4ec2 FileLog /var/media/ftp/Prolific-UsbFlashDisk-01/log/CM160_4ec2-%Y.log CM160_4ec2:ECUR:.*
loggst Du nur den State.

-> Soweit klar, und auch gewünscht (da alle Informationen des Sensors in einer Zeile vorhanden sind).
Je nach Nachkommastellen ist eine Zeile im Log ca. 51 Zeichen lang.

Ich würde event-on-change-reading auf energy_current und battery anwenden und den Filelog so abändern, dass diese auch geloggt werden, aber state nicht. In etwa so:
define FileLog_CM160_4ec2 FileLog /var/media/ftp/Prolific-UsbFlashDisk-01/log/CM160_4ec2-%Y.log CM160_4ec2:[energy_current|battery].*

done

Und hier liegt offensichtlich die Beschränkung von e-o-c-r:
e-o-c-r gibt nur den geänderten Parameter zurück.

Ändert sich in meinem konreten Fall "energy_current", steht für die weitere Auswertung (z.B. im devicelog) nur dieser Wert zur Verfügung. Battery wird also nicht berücksichtigt und nicht im devicelog eingetragen.
Ich vermute, dass bei einer Änderung von "battery" auch nur dieser Wert für die weitere Auswertung zurückgeliefert würde.

e-o-u-r führt zu keiner Änderung der Anzahl Einträge im Event monitor (und damit im devicelog).

Code Auswählen Erweitern


CM160_4ec2 energy_current: 409.148 W
CM160_4ec2 battery: ok
CM160_4ec2 energy_current: 409.148 W
CM160_4ec2 battery: ok


Damit kann man bestenfalls die weitergegebenen readings an FHEM "filtern".
Wird z.B. energy_total nicht mit angegeben, steht der Wert in FHEM nicht zur Verfügung.

Die Plots kannst Du ja auch mit energy_current machen.

Hatte ich Anfangs auch so gemacht, als jeder Eintrag im Log nach autocreate noch so aussah:

Code Auswählen Erweitern


TRX_WEATHER CM160_4ec2 energy_current: 352.956 W
TRX_WEATHER CM160_4ec2 energy_total: 369.322 kWh
TRX_WEATHER CM160_4ec2 battery: ok
TRX_WEATHER CM160_4ec2 ECUR: 352.956 ESUM: 369.322 BAT: ok


Dann war ich recht stolz auf mich, daß ich mir 3 Zeilen im devicelog sparen konnte, und mit den Werten aus "state" einen
Plot realisiert habe.
 

Mein Modul TRX_WEATHER nutzt die normale Funktionalität von event-on-change-reading, welchen in fhem.pl implementiert ist.

Das war mir klar, ich hatte dich auch nicht explizit wg. des Problemes angesprochen.
Wie einige andere Postings hier im Forum/der alten Group in Google zeigen, bin ich nich alleine mit meinem Verständnisproblem bzgl. der Funktionen von e-o-u-r/e-o-c-r.
Die commandref zu beiden Funktionen ist m.M. unzureichend und widersprüchlich.

Hast Du wirklich Zeitpunkte, bei denen sich energy_current nicht ändert?

Jepp, von gelegentlichen "Falschmeldungen" des CM160 abgesehen, öndert sich insbesondere bei Abwesenheit energy_current nur dann, wen Kühlschrank oder Gastherme "Energiehunger" haben.

event-on-change-reading (nicht von mir) vergleicht einfach, ob sich der String geändert hat. Ein selektiver Vergleich ist da m.E. nicht möglich.

Hättest Du mir das nicht schonender beibringen können? -
Winterdepression, Nachweihnachtsrekonvaleszenz und Trauer ob des endenden Jahres 2012.  :-)

Lieben Dank, daß Du diech meines Problems angenommen hast,
letztlich kann hier aber nur Rudolf König als Entwickler von e-o-c-r/e-o-u-r Licht ins Dunkle bringen.

VG
WiKA

[Willi]

Hättest Du mir das nicht schonender beibringen können? -
Winterdepression, Nachweihnachtsrekonvaleszenz und Trauer ob des endenden Jahres 2012.  :-)

Lieben Dank, daß Du diech meines Problems angenommen hast,
letztlich kann hier aber nur Rudolf König als Entwickler von e-o-c-r/e-o-u-r Licht ins Dunkle bringen.

Sorry, ich wollte Dich nicht depremieren.....

Diese Usergroup ist doch wirklich toll. Ich lerne immer wieder neue Wörter: "Nachweihnachtsrekonvaleszenz".....

Entwickler von e-o-c-r/e-o-u-r ist übrigens Boris, wenn ich mich nicht irre.

[WiKa]

Hallo Willi,

Entwickler von e-o-c-r/e-o-u-r ist übrigens Boris, wenn ich mich nicht irre.

dann geht der schwarze Peter jetzt an Boris :-)
Da der andere Baustellen hat, kann eine Lösung allerdings dauern (sofern er hier überhaupt mitliest).

Sorry, ich wollte Dich nicht depremieren.....

De nada (ich hoffe, ist richtig geschrieben).

Ich lerne immer wieder neue Wörter: "Nachweihnachtsrekonvaleszenz".....

Ist mir gerade so eingefallen, vorbehaltlich eventueller bestehender Rechte Dritter, meinerseits zur freien Verwendung freigegeben (GPL).

Back2topic,

Bis Boris sich zum Thema äußert bleibe ich bei beim bisherigen Verfahren - Log von state.

Ein Log von state verursacht (Datum/Zet) 21 Zeichen + 51 Zeichen für status.
Ein Log von energy_current und battery verursacht 21 + 37 Zeichen für energy_current und zusätzlich 21 + 22 Zeichen für battery.
Das Verhältnis ist also 51:59 - somit müssten 8 Meldungen verhindert werden, um auf der Habenseite zu sein.
Umgerechnet auf Fußballfelder würde das bedeuten:
....

Dank für deine kompetente Hilfe,
WiKa