Hallo Zusammen,
ich logge jetzt schon seit geraumer Zeit unseren WMBUS Wärmemengenzähler um den Verbrauch zu erfassen in eine Datenbank.
Das funktioniert soweit auch recht zuverlässig.
Leider ist bei diesen Zählern einprogrammiert das sie immer mal wieder anstelle des, mich interessierenden Zählerwertes, irgendeine ID als Wert schicken (dblog ist auf 1_value:.* beschränkt).
Sieht dann in etwa folgendermaßen aus:
2020-04-14 10:16:32 WMBUS Waermemengenzaehler 1_value: 327300
2020-04-14 10:23:48 WMBUS Waermemengenzaehler 1_value: 297594453498723407
2020-04-14 10:24:06 WMBUS Waermemengenzaehler 1_value: 327300
2020-04-14 10:25:45 WMBUS Waermemengenzaehler 1_value: 297594453498723407
2020-04-14 10:31:39 WMBUS Waermemengenzaehler 1_value: 327300
Ich würde nun gerne diesen sich andauernd wiederholenden Wert nicht in die DB speichern. Dabei bin ich auf DbLogValueFn (https://fhem.de/commandref_DE.html#DbLogValueFn) gestoßen.
Damit kann man wohl auch einen Wert ignorieren wenn man über eine Bedingung $IGNORE=1 setzt.
Das habe ich mit folgenden Variationen ausprobiert, aber leider ohne Erfolg:
attr dblog_WMZ_filtered DbLogValueFn {if ($VALUE eq '297594453498723407') {$IGNORE=1;;}}
attr dblog_WMZ_filtered DbLogValueFn {if ($VALUE eq "297594453498723407") {$IGNORE=1;;}}
attr dblog_WMZ_filtered DbLogValueFn {if ($VALUE = '297594453498723407') {$IGNORE=1;;}}
attr dblog_WMZ_filtered DbLogValueFn {if ($VALUE = "297594453498723407") {$IGNORE=1;;}}
attr dblog_WMZ_filtered DbLogValueFn {if ($VALUE == 297594453498723407) {$IGNORE=1;;}}
In der DB sieht der Eintrag folgendermaßen aus (siehe Anhang):
Was mache ich falsch?
lg Stefan
Hallo Stefan,
so wie es aussieht hast du dieses Attribut im DbLog Device gesetzt. Das wäre falsch. DbLogValueFn wird im Ursprungsdevice gesetzt, im DbLog steht dafür das Attr valueFn zur Verfügung.
LG,
Heiko
Hallo Heiko,
Danke das war es ;D, da wäre ich jetzt nicht so einfach drauf gekommen ???.
Ich hätte da aber noch eine Bonusfrage ;)
Wenn man das ganze auch noch mit event-on-change-reading verknüpfen möchte (um unnötige Logeinträge zu vermeiden) wie könnte man das Anstellen?
Momentan habe ich ein event-on-change-reading konfiguriert:
attr dblog_WMZ_filtered event-on-change-reading 1_value
Es werden jetzt zwar durch ValueFn die unerwünschten Einträge nicht ins DbLog geschrieben, aber intern ändert sich der Wert ja in den Readings im Device bei jedem neuen Datagramm.
2020-04-14 10:16:32 WMBUS Waermemengenzaehler 1_value: 327300
2020-04-14 10:23:48 WMBUS Waermemengenzaehler 1_value: 297594453498723407
2020-04-14 10:24:06 WMBUS Waermemengenzaehler 1_value: 327300
2020-04-14 10:25:45 WMBUS Waermemengenzaehler 1_value: 297594453498723407
2020-04-14 10:31:39 WMBUS Waermemengenzaehler 1_value: 327300
Nach diesem Block würden dann drei Einträge mit 327300 als Wert in der Datenbank stehen anstatt nur einem.
Kann man das irgendwie verhindern?
ZitatNach diesem Block würden dann drei Einträge mit 327300 als Wert in der Datenbank stehen anstatt nur einem.
Kann man das irgendwie verhindern?
Ja, kann man. Gibt wie so häufig verschiedene Wege, aber einer davon ist die Anwendung des Attr defaultMinInterval im DbLog -> https://fhem.de/commandref_DE.html#defaultMinInterval
Je nachdem ob du DbLogExclude / DbLogInclude verwendest haben die auch entsprechende Optionen.
Grüße,
Heiko
Zitat von: DS_Starter am 14 April 2020, 13:18:32
Ja, kann man. Gibt wie so häufig verschiedene Wege, aber einer davon ist die Anwendung des Attr defaultMinInterval im DbLog -> https://fhem.de/commandref_DE.html#defaultMinInterval
Ok, das ist hier leider nicht so optimal, da die Zeit zwischen den einzelnen Datagrammen variabel und nicht fest definiert ist :-\.
Das heißt, wahrscheinlich würde ich, wenn ich eine Zeitspanne festlege, Messwerte verlieren.
Gibt es auch noch andere Wege die zeitunabhängig sind?
Ich lasse für sowas monatlich reduceLogNbl (https://fhem.de/commandref_DE.html#DbLog) laufen, reduziere die Werte dadurch auf einen pro Stunde. Eventuell ist das auch eine Option für dich.
Was yersinia schreibt ist eine weitere Möglichkeit (benutze aber gleich reduceLog in einem DbRep-Device) oder aber delSeqDoublets in einem DbRep-Device (https://fhem.de/commandref_DE.html#DbRep). Das ist womöglich genau das richtige weil sehr flexibel einstellbar.
Noch etwas:
ZitatDas heißt, wahrscheinlich würde ich, wenn ich eine Zeitspanne festlege, Messwerte verlieren.
Du kannst es ohne "force" benutzen. Dadurch würdest du auch Messwerte loggen wenn sie sich innerhalb des Intervalls befinden
sofern sich der Wert geändert hat. Damit würdest du IMHO keine Werte verlieren.
@yersinia
Daran hatte ich auch schon gedacht, würde aber gerne eine feinere Granularität als einen Messwert/Stunde behalten.
@DS_Starter
Danke für den Hinweis mit delSeqDoublets ist zwar noch nicht die Goldrandlösung die ich mir vorgestellt habe, aber das erschlägt schon mal einige Anforderungen...
Hatte schon ein DbRep für das Device erstellt und deshalb gleich mal "set dblog_WMZ_filtered delSeqDoublets adviceRemain" ausprobiert, das hat schon mal die Logeinträge um 50% reduziert (mit Standard Parametern).
Aber so ganz verstehe ich die Logik dahinter noch nicht, es gibt trotzdem noch doppelte Einträge (innerhalb eines Stundenabschnitts), auch wenn ich den aggregation Zeitraum auf "week" stelle.
2020-03-23_09-32-11__Waermemengenzaehler__1_value 3079600 2020-04-14 15:49:34
2020-03-23_09-39-38__Waermemengenzaehler__1_value 3079600 2020-04-14 15:49:34
2020-03-23_09-47-05__Waermemengenzaehler__1_value 3079800 2020-04-14 15:49:34
2020-03-23_10-02-01__Waermemengenzaehler__1_value 3080000 2020-04-14 15:49:34
2020-03-23_10-09-29__Waermemengenzaehler__1_value 3080000 2020-04-14 15:49:34
2020-03-23_10-24-26__Waermemengenzaehler__1_value 3080400 2020-04-14 15:49:34
2020-03-23_10-46-52__Waermemengenzaehler__1_value 3080400 2020-04-14 15:49:34
2020-03-23_11-46-53__Waermemengenzaehler__1_value 3081700 2020-04-14 15:49:34
2020-03-23_12-01-56__Waermemengenzaehler__1_value 3082200 2020-04-14 15:49:34
2020-03-23_12-39-36__Waermemengenzaehler__1_value 3082200 2020-04-14 15:49:34
2020-03-23_12-54-41__Waermemengenzaehler__1_value 3082800 2020-04-14 15:49:34
2020-03-23_13-02-14__Waermemengenzaehler__1_value 3083000 2020-04-14 15:49:34
2020-03-23_13-17-21__Waermemengenzaehler__1_value 3083500 2020-04-14 15:49:34
2020-03-23_13-40-03__Waermemengenzaehler__1_value 3084200 2020-04-14 15:49:34
2020-03-23_17-59-36__Waermemengenzaehler__1_value 3084200 2020-04-14 15:49:34
2020-03-23_18-07-17__Waermemengenzaehler__1_value 3084400 2020-04-14 15:49:34
2020-03-23_18-15-00__Waermemengenzaehler__1_value 3084400 2020-04-14 15:49:34
2020-03-23_18-22-42__Waermemengenzaehler__1_value 3086400 2020-04-14 15:49:34
2020-03-23_18-30-24__Waermemengenzaehler__1_value 3086400 2020-04-14 15:49:34
2020-03-23_18-45-50__Waermemengenzaehler__1_value 3087000 2020-04-14 15:49:34
2020-03-23_19-24-28__Waermemengenzaehler__1_value 3087300 2020-04-14 15:49:34
2020-03-23_19-55-22__Waermemengenzaehler__1_value 3087900 2020-04-14 15:49:34
2020-03-23_20-03-05__Waermemengenzaehler__1_value 3089000 2020-04-14 15:49:34
oder hat das hiermit zu tun? https://fhem.de/commandref_DE.html#delSeqDoublets (https://fhem.de/commandref_DE.html#delSeqDoublets):
ZitatNicht gelöscht werden der erste und der letzte Datensatz einer Aggregationsperiode (z.B. hour, day, week usw.) sowie die Datensätze vor oder nach einem Wertewechsel (Datenbankfeld VALUE).
Zur Automatisierung würde der Befehl (delSeqDoublets) dann wohl am einfachsten einmal am Tag von einem AT aufgerufen werden?
Zitat
oder hat das hiermit zu tun? https://fhem.de/commandref_DE.html#delSeqDoublets:
Nicht gelöscht werden der erste und der letzte Datensatz einer Aggregationsperiode (z.B. hour, day, week usw.) sowie die Datensätze vor oder nach einem Wertewechsel (Datenbankfeld VALUE).
Zur Automatisierung würde der Befehl (delSeqDoublets) dann wohl am einfachsten einmal am Tag von einem AT aufgerufen werden?
Beides ist genau richtig. :)
Tipp: erstelle dir für deine Aufgaben jeweils ein eigenes DbRep-Device. Nicht etwa Attribute umkonfigurieren oder sowas. Manche kamen auf diese Idee und fanden die Usability dann nicht so prickelnd. ;)