Der Patch macht den zuvor geloggten Wert und Zeitstempel (aus dem Helper-Object) zur Verwendung in der DbLogValueFn verfügbar. Hierdurch können in dieser Funktion diverse weitere Filterfunktionen realisiert werden.
Außerdem besteht die Möglichkeit mir $RESETLAST=1 den vorherigen Wert im Helper-Object zu belassen (bzw den alten Wert wieder zu setzen) und somit den neuen Wert komplett zu ignorieren.
Index: FHEM/93_DbLog.pm
===================================================================
--- FHEM/93_DbLog.pm (Revision 22002)
+++ FHEM/93_DbLog.pm (Arbeitskopie)
@@ -1463,24 +1463,33 @@
$DoIt = DbLog_checkDefMinInt($name,$dev_name,$now,$reading,$value);
if ($DoIt) {
+ my $lv = $defs{$dev_name}{Helper}{DBLOG}{$reading}{$hash->{NAME}}{VALUE};
+ my $lt = $defs{$dev_name}{Helper}{DBLOG}{$reading}{$hash->{NAME}}{TIME};
$defs{$dev_name}{Helper}{DBLOG}{$reading}{$hash->{NAME}}{TIME} = $now;
$defs{$dev_name}{Helper}{DBLOG}{$reading}{$hash->{NAME}}{VALUE} = $value;
# Device spezifische DbLogValueFn-Funktion anwenden
if($DbLogValueFn ne '') {
- my $TIMESTAMP = $timestamp;
- my $DEVICE = $dev_name;
- my $EVENT = $event;
- my $READING = $reading;
- my $VALUE = $value;
- my $UNIT = $unit;
- my $IGNORE = 0;
- my $CN = " ";
+ my $TIMESTAMP = $timestamp;
+ my $LASTTIMESTAMP = $lt;
+ my $DEVICE = $dev_name;
+ my $EVENT = $event;
+ my $READING = $reading;
+ my $VALUE = $value;
+ my $LASTVALUE = $lv;
+ my $UNIT = $unit;
+ my $IGNORE = 0;
+ my $RESETLAST = 0;
+ my $CN = " ";
eval $DbLogValueFn;
Log3 $name, 2, "DbLog $name -> error device \"$dev_name\" specific DbLogValueFn: ".$@ if($@);
if($IGNORE) {
+ if($RESETLAST) {
+ $defs{$dev_name}{Helper}{DBLOG}{$reading}{$hash->{NAME}}{TIME} = $lt;
+ $defs{$dev_name}{Helper}{DBLOG}{$reading}{$hash->{NAME}}{VALUE} = $lv;
+ }
# aktueller Event wird nicht geloggt wenn $IGNORE=1 gesetzt in $DbLogValueFn
Log3 $hash->{NAME}, 4, "DbLog $name -> Event ignored by device \"$dev_name\" specific DbLogValueFn - TS: $timestamp, Device: $dev_name, Type: $dev_type, Event: $event, Reading: $reading, Value: $value, Unit: $unit"
if($vb4show && !$hash->{HELPER}{".RUNNING_PID"});
Danke für den Patch.
Finde ich auf den ersten Blick eine sinnvolle Erweiterung.
Allerdings würde ich auf das $RESETLAST verzichten wollen und stattdessen im Fall von $IGNORE = 1 generell wie von dir vorgeschlagen
$defs{$dev_name}{Helper}{DBLOG}{$reading}{$hash->{NAME}}{TIME} = $lt;
$defs{$dev_name}{Helper}{DBLOG}{$reading}{$hash->{NAME}}{VALUE} = $lv;
anzuwenden. Das wäre in diesem Fall sogar per default zu tun wenn ich es mir richtig überlege da der DS ja nicht geloggt wird.
Ich vermute du hast den Patch bei dir schon einige Zeit laufen. Was denkst du ?
Das geht ja flott hier ;)
Du meinst also so?
Index: FHEM/93_DbLog.pm
===================================================================
--- FHEM/93_DbLog.pm (Revision 22004)
+++ FHEM/93_DbLog.pm (Arbeitskopie)
@@ -1463,24 +1463,30 @@
$DoIt = DbLog_checkDefMinInt($name,$dev_name,$now,$reading,$value);
if ($DoIt) {
+ my $lv = $defs{$dev_name}{Helper}{DBLOG}{$reading}{$hash->{NAME}}{VALUE};
+ my $lt = $defs{$dev_name}{Helper}{DBLOG}{$reading}{$hash->{NAME}}{TIME};
$defs{$dev_name}{Helper}{DBLOG}{$reading}{$hash->{NAME}}{TIME} = $now;
$defs{$dev_name}{Helper}{DBLOG}{$reading}{$hash->{NAME}}{VALUE} = $value;
# Device spezifische DbLogValueFn-Funktion anwenden
if($DbLogValueFn ne '') {
- my $TIMESTAMP = $timestamp;
- my $DEVICE = $dev_name;
- my $EVENT = $event;
- my $READING = $reading;
- my $VALUE = $value;
- my $UNIT = $unit;
- my $IGNORE = 0;
- my $CN = " ";
+ my $TIMESTAMP = $timestamp;
+ my $LASTTIMESTAMP = $lt;
+ my $DEVICE = $dev_name;
+ my $EVENT = $event;
+ my $READING = $reading;
+ my $VALUE = $value;
+ my $LASTVALUE = $lv;
+ my $UNIT = $unit;
+ my $IGNORE = 0;
+ my $CN = " ";
eval $DbLogValueFn;
Log3 $name, 2, "DbLog $name -> error device \"$dev_name\" specific DbLogValueFn: ".$@ if($@);
if($IGNORE) {
+ $defs{$dev_name}{Helper}{DBLOG}{$reading}{$hash->{NAME}}{TIME} = $lt;
+ $defs{$dev_name}{Helper}{DBLOG}{$reading}{$hash->{NAME}}{VALUE} = $lv;
# aktueller Event wird nicht geloggt wenn $IGNORE=1 gesetzt in $DbLogValueFn
Log3 $hash->{NAME}, 4, "DbLog $name -> Event ignored by device \"$dev_name\" specific DbLogValueFn - TS: $timestamp, Device: $dev_name, Type: $dev_type, Event: $event, Reading: $reading, Value: $value, Unit: $unit"
if($vb4show && !$hash->{HELPER}{".RUNNING_PID"});
Ja, eigentlich hast du Recht. Und wenn ich mir so meine config anschaue habe ich überall wo ich $IGNORE=1 setze auch $RESETLAST=1 gesetzt. Mir würde jetzt spontan auch kein Fall einfallen in dem es sinnvoll wäre das nicht zu tun ;D
Ja genau, so meinte ich es. :)
In welchen Fällen nutzt du deine Erweiterung. Oder anders gefragt, welche use cases hattest du die diese Erweiterung nötig machten ?
Und in der $value_fn, also die nächste Funktion etwas tiefer, müßte diese Erweiterung dann ebenfalls mit hinein.
Ich habe zum Beispiel einige Temperatursensoren welche ich in kurzen Intervallen auslesen lasse.
Die Daten möchte ich auch gerne in so kurzen Abständen auf dem Dashboard aktualisiert haben, sonst könnte ich ja einfach den Intervall hochsetzen.
In der DB soll aber nicht jede noch so kleine Änderung gespeichert werden, sondern nur wenn sich der Wert im Vergleich zum vorherigen um X (z.B. 0,5°C) geändert hat.
Hierfür nutze ich dann als DbLogValueFn zB:
{ $IGNORE = 1 if(abs($VALUE-$LASTVALUE) < 0.5); }
Ich hab mir das ganze mal zusätzlich noch ins Logfile schreiben lassen (hier allerdings mit einer Mindestabweichung von 0.2).... Wie man sieht werden einige Werte dann einfach ignoriert - was ja die Datenmenge deutlich reduziert:
2020.05.23 08:37:51 0: NewValue: 45.25 - LastValue: 45.56 - IGNORE: 0
2020.05.23 08:37:59 0: NewValue: 45.13 - LastValue: 45.25 - IGNORE: 1
2020.05.23 08:38:07 0: NewValue: 45.06 - LastValue: 45.25 - IGNORE: 0
2020.05.23 08:38:15 0: NewValue: 44.94 - LastValue: 45.06 - IGNORE: 1
2020.05.23 08:38:23 0: NewValue: 44.81 - LastValue: 45.06 - IGNORE: 0
2020.05.23 08:38:31 0: NewValue: 44.75 - LastValue: 44.81 - IGNORE: 1
2020.05.23 08:38:39 0: NewValue: 44.63 - LastValue: 44.81 - IGNORE: 1
2020.05.23 08:38:47 0: NewValue: 44.56 - LastValue: 44.81 - IGNORE: 0
2020.05.23 08:38:55 0: NewValue: 44.44 - LastValue: 44.56 - IGNORE: 1
2020.05.23 08:39:05 0: NewValue: 44.38 - LastValue: 44.56 - IGNORE: 1
2020.05.23 08:39:11 0: NewValue: 44.31 - LastValue: 44.56 - IGNORE: 0
2020.05.23 08:39:19 0: NewValue: 44.25 - LastValue: 44.31 - IGNORE: 1
2020.05.23 08:39:27 0: NewValue: 44.19 - LastValue: 44.31 - IGNORE: 1
2020.05.23 08:39:35 0: NewValue: 44.13 - LastValue: 44.31 - IGNORE: 1
2020.05.23 08:39:43 0: NewValue: 44.06 - LastValue: 44.31 - IGNORE: 0
2020.05.23 08:39:51 0: NewValue: 44.00 - LastValue: 44.06 - IGNORE: 1
2020.05.23 08:39:59 0: NewValue: 43.94 - LastValue: 44.06 - IGNORE: 1
2020.05.23 08:40:07 0: NewValue: 43.88 - LastValue: 44.06 - IGNORE: 1
2020.05.23 08:40:15 0: NewValue: 43.81 - LastValue: 44.06 - IGNORE: 0
2020.05.23 08:40:23 0: NewValue: 43.75 - LastValue: 43.81 - IGNORE: 1
2020.05.23 08:40:31 0: NewValue: 43.75 - LastValue: 43.81 - IGNORE: 1
2020.05.23 08:40:39 0: NewValue: 43.69 - LastValue: 43.81 - IGNORE: 1
2020.05.23 08:40:47 0: NewValue: 43.63 - LastValue: 43.81 - IGNORE: 1
2020.05.23 08:40:55 0: NewValue: 43.63 - LastValue: 43.81 - IGNORE: 1
2020.05.23 08:41:03 0: NewValue: 43.56 - LastValue: 43.81 - IGNORE: 0
Klar könnte man das ganze bestimmt auch irgendwie anders lösen, aber so fand ich es eigentlich am einfachsten ;)
Die $value_fn wird ja auch noch in DbLog_AddLog und DbLog_addCacheLine aufgerufen. Hier sollte das dann wohl auch rein, ne? :)
Ich finde der Patch ist sehr hilfreich für solche Fälle.
ZitatDie $value_fn wird ja auch noch in DbLog_AddLog und DbLog_addCacheLine aufgerufen. Hier sollte das dann wohl auch rein, ne?
Ja, natürlich. Ich habe die Änderung überall entsprechend angepasst übernommen und angetestet. Man kann es nicht an jeder Stelle 1:1 übernehmen.
Die commandRef ist auch angepasst, gehört auch dazu. ;)
Die neue Version befindet sich vorab zum Test in meinem contrib.
Zum Download in der FHEMWEB Kommandozeile inklusive der Ausführungszeichen angeben:
"wget -qO ./FHEM/93_DbLog.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbLog.pm"
Danach FHEM restarten.
Grüße,
Heiko
Habe die neue Version 4.10.0 eingecheckt und ist morgen früh im Regelupdate enthalten.
Möglicherweise nicht der richtige Thread, aber nachdem in der DbLog forum 111423 mit dem improvement genannt wurde ..
configCheck bringt bei sqlite beim check der Tabellen history und current sehr eigentümliche Meldungen:
Column width set in DB history: 'DEVICE' = CREATE TABLE "history" ( TIMESTAMP TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, 64 TYPE varchar(64) , EVENT varchar(512) , READING varchar(64) , VALUE varchar(128) , UNIT varchar(32)), 'TYPE' = CREATE TABLE "history" ( TIMESTAMP TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, DEVICE varchar(64) , 64 EVENT varchar(512) , READING varchar(64) , VALUE varchar(128) , UNIT varchar(32)), 'EVENT' = CREATE TABLE "history" ( TIMESTAMP TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, DEVICE varchar(64) , TYPE varchar(64) , 512 READING varchar(64) , VALUE varchar(128) , UNIT varchar(32)), 'READING' = CREATE TABLE "history" ( TIMESTAMP TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, DEVICE varchar(64) , TYPE varchar(64) , EVENT varchar(512) , 64 VALUE varchar(128) , UNIT varchar(32)), 'VALUE' = CREATE TABLE "history" ( TIMESTAMP TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, DEVICE varchar(64) , TYPE varchar(64) , EVENT varchar(512) , READING varchar(64) , 128 UNIT varchar(32)), 'UNIT' = CREATE TABLE "history" ( TIMESTAMP TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, DEVICE varchar(64) , TYPE varchar(64) , EVENT varchar(512) , READING varchar(64) , VALUE varchar(128) , 32
Column width used by myDbLog: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: WARNING - The relation between column width in table history and the field width used by device myDbLog should be equal but it differs.The field width used by myDbLog can be adjusted by setting attributes 'colEvent', 'colReading', 'colValue'. (pls. refer to commandref)Because you use SQLite this is only a warning. Normally the database can handle these differences.
Die bim entsprechenden Teil befüllte Variable $rec ist nirgends zu sehen.. ich habe nicht weiter analysiert, da hakt jedenfalls etwas.
Und da ich schon mal dabei bin:
#globales Abfangen von
# - temperature
# - humidity
if ($reading =~ m(^temperature)) { $unit = "°C"; } # wenn reading mit temperature beginnt
elsif($reading =~ m(^humidity)) { $unit = "%"; }
lies mich den Luftdruck vermissen .. wie wäre es mit ?
#globales Abfangen von
# - temperature
# - humidity
# - airpressure
if ($reading =~ m(^temperature)) { $unit = "°C"; } # wenn reading mit temperature beginnt
elsif($reading =~ m(^humidity)) { $unit = "%"; } # wenn reading mit humidity beginnt
elsif($reading =~ m(^airpressure)) { $unit = "hPa"; } # wenn reading mit airpressure beginnt
elsif($reading =~ m(^pressure)) { $unit = "Pa"; } # wenn reading mit pressure beginnt
Grüße
Hendrik
Hallo Hendrik,
deine Meldungen beim configCheck kann ich bei mir nicht nachvollziehen.
Bei mir kommt eine saubere Auflistung (auch SQLite):
Result of table 'history' check
Column width set in DB history: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Version aktuell ?
Die Erweiterung für den Luftdruck übernehme ich.
Eine Bitte dazu. Ich weiß nicht woher die Notwendigkeit dieser Erweiterung kommt, wenn sie aus einem Modul esultiert, dann bitte den Modulautor darauf hinweisen, dass er wenn möglich in seinem Modul das DbLog_split wie im Wiki (https://wiki.fhem.de/wiki/DevelopmentModuleIntro#X_DbLog_split) beschrieben dort einbaut. Das ist einfach sauberer und der Modulautor hat alles in seiner Hand.
Grüße,Heiko
Hallo Heiko,
Danke erstmal! Das Modul wäre ECMD.
Nach einem Tag Denken frage ich mich allerdings gleich mehrere Dinge:
Ist es überhaupt eine gute Idee aus frei vergebbaren Namen die physische Größe und, quasi obendrein, die Einheit abzuleiten? Nicht ohne Grund gibt es selbst bei so gewöhnlichen Dingen wie der Länge auch im ISO System verschiedene Einheiten wie Angström, Meter , Astronomische Einheit und Lichtjahre.
Ist es sinnvoll imperial units auszuklammern? Ja, auch die NASA arbeitet metrisch, aber hier sind wir doch wesentlich näher am täglichen Leben.
Gibt es eleganter Lösungen, die solche Festlegungen erlauben? Und ist dblog eigentlich der geeignete Ort für diese Manipulationen?
Du fragtest nach Version aktuell. Update fhem ist keine 24 Stunden her.. was wäre meinerseits nötig hier zu einer Beurteilung zu kommen, warum die Meldungen bei mir so heraus kommen?
Grüße, Hendrik
Hallo Hendrik,
ZitatIst es überhaupt eine gute Idee aus frei vergebbaren Namen die physische Größe und, quasi obendrein, die Einheit abzuleiten?
Nein, das Splitting in DbLog ist nur eine Krücke und man hat versucht wenigstens ein paar der am häufigsten auftretenden Kombinationen abzufangen.
ZitatUnd ist dblog eigentlich der geeignete Ort für diese Manipulationen?
Nein, aus oben genannten Grund. Ich habe es auch noch nicht übernommen weil mir eine bessere Idee gekommen ist, siehe unten.
ZitatGibt es eleganter Lösungen, die solche Festlegungen erlauben?
Ja, die gibt es.
Ich hatte ja schon auf die DbLog_split Funktion hingewiesen.
Die Modulautoren sollten wissen mit welchen Einheiten die Werte in ihren Modulen erzeugt werden (vllt. nicht in jedem Fall) und können in der DbLog_splitFn dann genau zuordnen bzw. auflösen.
Leider wird die Funktion immer wieder vergessen oder weggelassen.
Als User kann man dafür das Attribut valueFn nutzen. Damit kann man quasi die Einheitenfestlegung selbst gestalten.
Zum Beispiel so:
attr <name> valueFn {
if ($READING=~ m(^airpressure)) {
$UNIT = "hPa";
}
if ($READING=~ m(^pressure)) {
$UNIT = "Pa";
}
}
Damit kann man sich viel selbst erstellen. Gibt auch noch das Attribut DbLogValueFn welches man in den Ursprungsdevices setzt und nicht im DbLog.
Bezüglich der Meldungen habe ich eine Veränderung in configCheck vorgenommen. Ich denke das ist ein Regx Problem, wobei ich nicht erkennen konnte warum bei dir diese Meldungen kommen und bei mir nicht.
Du kannst die neue Version vorab testen.
Zum Download in der FHEMWEB Kommandozeile inklusive der Ausführungszeichen angeben und dann restarten:
"wget -qO ./FHEM/93_DbLog.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbLog.pm"
LG,
Heiko
Hallo Heiko,
hab den patch gerade getestet, für history paßt es jetzt, current ist geblieben. Danke einstweilen!
Noch 2 Fragen sind noch aufgetaucht: current ist immer leer, wenn ichs richtig gelesen habe, sollten doch da die letzten readings enthalten sein. Habe ich da etwas übersehen, dass ich hätte machen sollen? Und läßt sich das fhem-jjjj-mm.log auch in die db integrieren?
Das valuefn ist sehr interessant, das nehme ich in meine Definitionen mit auf. Bin immer wieder überrascht, was alles geht.
Grüße, Hendrik
Hallo Hendrik,
Mist, die current habe ich ganz vergessen zu korrgieren ... mach ich noch.
Zitatcurrent ist immer leer, wenn ichs richtig gelesen habe, sollten doch da die letzten readings enthalten sein.
Ja, aber per default wird nur history beschrieben -> attr DbLogType setzen.
ZitatUnd läßt sich das fhem-jjjj-mm.log auch in die db integrieren?
Klares jein. ;)
Das geht auf Umwegen. Man muss aus den Zeilen im fhem-Log Events machen, die dann geloggt werden können.
Das geht mit einem notify und gesetztem readLog attribut.
Grüße,
Heiko
Danke :) :)
Gern !
Wenn ich das richtig sehe, wird dadurch die fhem-jjjj-mm.log nicht obsolet, sondern es kommen Kopien der (ausgewählten) Einträge in die DB. Ich hatte eigentlich nach einer Lösung gesucht die Datei(en) zu obsolidieren und config, events und log in DBs zu haben, erstere Beiden sind ja schon dort.
Nur zur Vollständigkeit: valueFn und DbLogType getestet und Ergebnis wie erwartet, Danke ! DbLogValueFn teste ich die nächsten Tage.
Grüße, Hendrik
ZitatIch hatte eigentlich nach einer Lösung gesucht die Datei(en) zu obsolidieren und config, events und log in DBs zu haben,
Achso , da hatte ich dich falsch verstanden. Nein, eine solche Lösung ist mir nicht bekannt. Wäre wohl etwas für die Wunschliste als Feature FHEM-logs nicht in ein File sondern in eine DB schreiben zu können.
Grüße,
Heiko