Hallo,
ich habe mal ein query gebastelt dass die DbLog Datenbank etwas aufräumt und alles auf definierte zeitintervalle runterbricht. das ganze funktioniert jedoch nur für numerische werte.
code auf github (https://github.com/mdorenka/fhem_dbcleansing/blob/master/cleanse.sql)
eignet sich als cronjob oder ähnliches. wenn das jemand in ein hübsches modul packen möchte wäre ich sehr dankbar dafür!
für was ist das gut?
es werden alle einträge zusammengefasst, d.h. die zu verarbeitende datenmenge wird kleiner, die kurve etwas "glatter" im plot.
nachteil: es geht präzision verloren, aber wen interessiert die genaue temperatur vor 4 stunden auf 0,1 grad genau im 20 sekunden interval? ;)
viel spass damit :)
Moin!
Wie stellst Du Dir so ein Modul vor?
Soll es definieren, für welche TYPEs in welchen Abständen periodisch ausgeführt wird? Eine Möglichkeit für 'tue es jetzt' bieten?
Gruß,
Alexander
Edit:
Habe den Quatsch mit '(bei Dir fest 'SQLAGGREGATE')' entfernt (habe mich verguckt und falsch verstanden).
Zitat von: hexenmeister am 13 Dezember 2013, 10:41:01
Soll es definieren, für welche TYPEs in welchen Abständen periodisch ausgeführt wird? Eine Möglichkeit für 'tue es jetzt' bieten?
zum beispiel :)
momentan wird es ja einfach für ALLE devices und readings ausgeführt (für meine zwekce funktioniert das hervorragend) und wird per cron jede stunde ausgeführt.
es wäre schön das direkt in dblog einzubauen. in einem extra modul funktioniert es mit sqlite nicht weil sqlite nur eine schreibende verbindung verträgt.
ein pro device konfigurierbares alles älter als ... löschen wäre auch noch eine erweiterung.
gruss
andre
die frage ist ob das query so überhaupt auf sqlite funktioniert.
ja das dblog modul ist leider auch sehr spezifisch gehalten und nicht sehr generisch, weiterhin erzeugt es auch inkonsistenzen (stichwort primary key)
ich denke das sollte dringend mal überarbeitet werden!
Ich finde die Idee sehr interessant. Ich habe einen weiteren Vorschlag: Ist es mit vertretbarem Aufwand möglich für einzelne Readings Logeinträge zu entfernen wenn sie sich nicht geändert haben? Hier ein Auszug aus dem Log von einem meiner Heizkörperthermostate:
+---------------------+-----------------------+------+--------------------------+--------------------+-------------------------+-------+
| TIMESTAMP | DEVICE | TYPE | EVENT | READING | VALUE | UNIT |
+---------------------+-----------------------+------+--------------------------+--------------------+-------------------------+-------+
| 2014-01-03 15:50:26 | thermostat_wohnzimmer | MAX | desiredTemperature: 20.0 | desiredTemperature | 20.0 | °C |
| 2014-01-03 15:50:26 | thermostat_wohnzimmer | MAX | temperature: 19.6 | temperature | 19.6 | °C |
| 2014-01-03 15:50:26 | thermostat_wohnzimmer | MAX | valveposition: 37 | valveposition | 37 | % |
| 2014-01-03 15:49:23 | thermostat_wohnzimmer | MAX | desiredTemperature: 20.0 | desiredTemperature | 20.0 | °C |
| 2014-01-03 15:49:23 | thermostat_wohnzimmer | MAX | temperature: 19.6 | temperature | 19.6 | °C |
| 2014-01-03 15:49:23 | thermostat_wohnzimmer | MAX | valveposition: 37 | valveposition | 37 | % |
| 2014-01-03 15:48:22 | thermostat_wohnzimmer | MAX | desiredTemperature: 20.0 | desiredTemperature | 20.0 | °C |
| 2014-01-03 15:48:22 | thermostat_wohnzimmer | MAX | temperature: 19.6 | temperature | 19.6 | °C |
| 2014-01-03 15:48:22 | thermostat_wohnzimmer | MAX | valveposition: 37 | valveposition | 37 | % |
| 2014-01-03 15:47:20 | thermostat_wohnzimmer | MAX | desiredTemperature: 20.0 | desiredTemperature | 20.0 | °C |
| 2014-01-03 15:47:20 | thermostat_wohnzimmer | MAX | temperature: 19.6 | temperature | 19.6 | °C |
| 2014-01-03 15:47:20 | thermostat_wohnzimmer | MAX | valveposition: 37 | valveposition | 37 | % |
| 2014-01-03 15:46:19 | thermostat_wohnzimmer | MAX | desiredTemperature: 20.0 | desiredTemperature | 20.0 | °C |
| 2014-01-03 15:46:19 | thermostat_wohnzimmer | MAX | temperature: 19.6 | temperature | 19.6 | °C |
| 2014-01-03 15:46:19 | thermostat_wohnzimmer | MAX | valveposition: 37 | valveposition | 37 | % |
| 2014-01-03 15:45:18 | thermostat_wohnzimmer | MAX | desiredTemperature: 20.0 | desiredTemperature | 20.0 | °C |
| 2014-01-03 15:45:18 | thermostat_wohnzimmer | MAX | temperature: 19.6 | temperature | 19.6 | °C |
| 2014-01-03 15:45:18 | thermostat_wohnzimmer | MAX | valveposition: 37 | valveposition | 37 | % |
| 2014-01-03 15:44:13 | thermostat_wohnzimmer | MAX | desiredTemperature: 20.0 | desiredTemperature | 20.0 | °C |
| 2014-01-03 15:44:13 | thermostat_wohnzimmer | MAX | temperature: 19.6 | temperature | 19.6 | °C |
| 2014-01-03 15:44:13 | thermostat_wohnzimmer | MAX | valveposition: 37 | valveposition | 37 | % |
| 2014-01-03 15:43:12 | thermostat_wohnzimmer | MAX | desiredTemperature: 20.0 | desiredTemperature | 20.0 | °C |
| 2014-01-03 15:43:12 | thermostat_wohnzimmer | MAX | temperature: 19.6 | temperature | 19.6 | °C |
| 2014-01-03 15:43:12 | thermostat_wohnzimmer | MAX | valveposition: 37 | valveposition | 37 | % |
| 2014-01-03 15:42:07 | thermostat_wohnzimmer | MAX | desiredTemperature: 20.0 | desiredTemperature | 20.0 | °C |
| 2014-01-03 15:42:07 | thermostat_wohnzimmer | MAX | temperature: 19.6 | temperature | 19.6 | °C |
| 2014-01-03 15:42:07 | thermostat_wohnzimmer | MAX | valveposition: 37 | valveposition | 37 | % |
| 2014-01-03 15:41:07 | thermostat_wohnzimmer | MAX | desiredTemperature: 20.0 | desiredTemperature | 20.0 | °C |
| 2014-01-03 15:41:07 | thermostat_wohnzimmer | MAX | temperature: 19.6 | temperature | 19.6 | °C |
| 2014-01-03 15:41:07 | thermostat_wohnzimmer | MAX | valveposition: 37 | valveposition | 37 | % |
| 2014-01-03 15:40:06 | thermostat_wohnzimmer | MAX | desiredTemperature: 20.0 | desiredTemperature | 20.0 | °C |
| 2014-01-03 15:40:06 | thermostat_wohnzimmer | MAX | temperature: 19.6 | temperature | 19.6 | °C |
| 2014-01-03 15:40:06 | thermostat_wohnzimmer | MAX | valveposition: 37 | valveposition | 37 | % |
Wie man sieht ändern sich die Werte der einzelnen Readings nicht. Wenn man identische Werte löscht, bis zu dem Zeitpunkt wo sich der Wert ändert, hätte man nur einen Bruchteil der Daten und würde trotzdem nichts an "Auflösung" verlieren, in einem Plot würde man keinen Unterschied erkennen, abgesehen davon dass er sich schneller aufbauen würde.
Just my 2 Cents.
Grüße,
Markus
Hallo,
Zitatin einem Plot würde man keinen Unterschied erkennen
Leider doch.
Ab 00:00 Uhr wirst du bis zur Änderung des Wertes keinen Plot gezeichnet bekommen da noch keine Werte für diesen Tag in der Datenbank sind.
Angenommen der Wert ändert sich um 21:20 Uhr - Eintrag in der DB
Wert ändert sich erst wieder um 09:17 Uhr (warum auch immer) - bis 09:16 Uhr wirst du keine Linie im Plot vorfinden.
Und um 09:17 Uhr dann von der Grundlinie um 00:00 Uhr ansteigend bis zum Wert um 09:17 Uhr - also eine Schräge.
Dagegen müsste dann wieder addLog einspringen und zusätzliche Readings um 23:59 Uhr und 00:01 Uhr generieren.
Dann haben wir noch das Problem das wir (um beim obigen Beispiel zu bleiben) um 09:16 Uhr aber immer noch keine Linie von 00:01 Uhr bis zum jetzigen Zeitpunkt haben.
Die Linie wird erst gezeichnet wenn um 09:17 Uhr der nächste Eintrag in der DB steht.
Also addLog doch stündlich triggern um einen halbwegs durchgehenden Plot zu bekommen?
Grüße
Edith: Ah - ok. Es geht um das nachträgliche ändern der Daten in der DB.
du verlierst sehr wohl auflösung im plot wenn auf einer zoomstufe der erste oder letzte wert ausserhalb des sichtbaren bereiches ist hast du auf jeden fall 'Löcher.'
und den gleichen effekt kannst du doch mit event-on-change-reading haben. und du sparst noch den overhead erst zu loggen und dann wieder aufzuräumen.
gruss
andre
Meiner Meinung nach ist das aber ein Problem mit dem Plotting, dafür sollte man nicht die gleichen Daten x-fach vorhalten müssen. Werde das mit event-on-change-reading jetzt mal ausprobieren, hab das fürs logging irgendwie nicht so auf der Pfanne gehabt.
soetwas steht schon auf meiner TODO Liste fürs DBLog Modul.
Mangels Zeit und detaillierteres Umsetzungskonzept noch nicht weiter dazu gekommen...
Hallo,
Da mich die Löcher bei der Anzeige der Plots trotz addLog gestört haben habe ich die SQL-Abfrage in DbLog so angepasst dass immer Daten im Plot dargestellt werden. Bei SQLite sollte dies funktionieren:
if ($hash->{DBMODEL} eq "SQLITE") {
$stm="SELECT * from (SELECT
$sqlspec{get_timestamp} as TIMESTAMP,
VALUE
$sqlspec{all}
FROM history
WHERE
DEVICE = '".$readings[$i]->[0]."'
AND READING = '".$readings[$i]->[1]."'
AND TIMESTAMP > $sqlspec{from_timestamp}
AND TIMESTAMP < $sqlspec{to_timestamp}) a
UNION select $sqlspec{from_timestamp} as TIMESTAMP, VALUE
$sqlspec{all} from (SELECT
TIMESTAMP,
VALUE
$sqlspec{all}
FROM history
WHERE
DEVICE = '".$readings[$i]->[0]."'
AND READING = '".$readings[$i]->[1]."'
AND TIMESTAMP <= $sqlspec{from_timestamp}
ORDER BY TIMESTAMP desc limit 1) b
UNION select $sqlspec{to_timestamp} as TIMESTAMP, VALUE
$sqlspec{all} from (SELECT
TIMESTAMP,
VALUE
$sqlspec{all}
FROM history
WHERE
DEVICE = '".$readings[$i]->[0]."'
AND READING = '".$readings[$i]->[1]."'
AND TIMESTAMP <= $sqlspec{to_timestamp}
ORDER BY TIMESTAMP desc limit 1) c
ORDER BY TIMESTAMP asc";
}
Eingefügt habe ich dies hinter dem Block my $stm= "SELECT
$sqlspec{get_timestamp},
...
ORDER BY TIMESTAMP";
Die Lösung ist nicht ganz korrekt da keine Interpolation der Werte außerhalb des angezeigten Fensters stattfindet, dies dürfte in der Praxis aber vernachlässigbar sein.
Grüße,
ChrisD
Sehr gute Idee. Da hatte ich gestern auch gerade drüber gebrütet, da meine Event-on-change Maßnahmen ein paar Nebeneffekte in den Plots haben.
Gruß
Veit
Moin Tobias,
hier mal ein Code-Schnipsel, den ich im Filelog eingebaut hatte, un die Datenmange zu reduzieren:
##################################### Aenderungen fuer change, debug ###############################################################
my $change = defined($attr{$ln}{"change"}); # Attribut change abholen und $change auf 1 setzen wenn gesetzt
my $debug = defined($attr{$ln}{"debug"}); # Attribut debug abholen und $debug auf 1 setzen, wenn gesetzt
my $convert = defined($attr{$ln}{"convert"}); # Attribut convert abholen und $convert auf 1 setzen, wenn gesetzt
my $LL; # Variable Loglevel $LL einfuehren
if("$debug" eq "1"){ # Debugmodus ein/ausschalten
$LL = 3;
} else {
$LL = 5;
}
if("$change" eq "1"){ # Changemodus ein/ausschalten
Log $LL,"Filelog Zeile 137 Changemodus ist eingeschaltet"; # Debugausgabe
my $new; # Variable Stundenwechsel $new einfuehren
my $loeschen; # Hilfsvariable $loeschen einfuehren
my $zusatz; # Hilfsvariable $zusatz einfuehren
my $line; # Hilfsvariable $line einfuehren
my @input; # Array @input einfuehren
my $IN; # Variable $IN einfuehren
my @input1; # Array @input1 einfuehren # ggf reihenfolge durch zusatzeintrag vertauscht
my @output; # Array @output einfuehren
my $out; # Variable $OUT einfuehren
my $logfile = $log->{currentlogfile}; # aktuelles logfile holen
my $v = "$t1{$n,$i}"." $n"." $s1{$n,$i}"; # Vergleichsstring "letztes Reading" befuellen
my $v1 = "$t2{$n,$i}"." $n"." $s2{$n,$i}"; # Vergleichsstring "vorletztes Reading" befuellen
my $tH = substr($t,11,2); # Vergleichsstring "Stunde" aktuelles Reading befuellen
my $tH1 = substr($t1{$n,$i},11,2); # Vergleichsstring "Stunde" letztes Reading befuellen
my $tH2 = substr($t2{$n,$i},11,2); # Vergleichsstring "Stunde" vorletztes Reading befuellen
Log $LL,"Filelog Zeile 153 aktuelle/letzte/vorletzte Stunde $tH / $tH1 / $tH2"; # Debugausgabe
Log $LL,"Filelog Zeile 154 vorletzter Wert $v1"; # Debugausgabe
Log $LL,"Filelog Zeile 155 letzter Wert $v"; # Debugausgabe
Log $LL,"Filelog Zeile 156 aktueller Wert $t $n $s"; # Debugausgabe
if("$t" eq "$t1{$n,$i}"){ # OWX gibt beim Start mehrere gleiche Werte in sehr kurzer Zeit aus
Log $LL,"Filelog Zeile 158 $t"; # Debugausgabe
Log $LL,"Filelog Zeile 159 $t1{$n,$i}"; # Debugausgabe
Log $LL,"Filelog Zeile 160 Die Messungen liegen zu dicht zusammen, der aktuelle Wert wird ignoriert"; # Debugausgabe
$t = "00-ignorieren";
}
if($tH2 eq ""){
$loeschen = 0; # Fall 0 Neustart von FHEM
$zusatz = 0;
Log $LL,"Filelog Zeile 166 >>>> Fall 0 <<<< FHEM wurde neu gestartet"; # Debugausgabe
goto CHANGEENDE;
}elsif((("$s" ne "$s1{$n,$i}") || ("$s" ne "$s2{$n,$i}")) && (($tH eq $tH1) || (($tH ne "00") && ($tH ne "06") && ($tH ne "12") && ($tH ne "18")))){
$loeschen = 0; # Fall 1 Readings ungleich kein Plotwechsel --> letzten Eintrag erhalten und kein Zusatzeintrag
$zusatz = 0;
Log $LL,"Filelog Zeile 171 >>>> Fall 1 <<<< Readings ungleich kein Plotwechsel"; # Debugausgabe
goto CHANGEENDE;
} elsif((("$s" eq "$s1{$n,$i}") && ("$s" eq "$s2{$n,$i}")) && (($tH eq $tH1) || (($tH ne "00") && ($tH ne "06") && ($tH ne "12") && ($tH ne "18")))){
$loeschen = 1; # Fall 2 Readings gleich kein Plotwechsel --> letzten Eintrag loeschen und kein Zusatzeintrag
$zusatz = 0;
Log $LL,"Filelog Zeile 176 >>>> Fall 2 <<<< Readings gleich kein Plotwechsel"; # Debugausgabe
} elsif((("$s" ne "$s1{$n,$i}") || ("$s" ne "$s2{$n,$i}")) &&
((($tH eq "00") || ($tH eq "06") || ($tH eq "12") || ($tH eq "18")) && ($tH ne $tH1))){
$loeschen = 0; # Fall 3 Readings ungleich und Plotwechsel --> letzten Eintrag erhalten und Zusatzeintrag
$zusatz = 1 ;
Log $LL,"Filelog Zeile 181 >>>> Fall 3 <<<< Readings ungleich und Plotwechsel"; # Debugausgabe
} elsif((("$s" eq "$s1{$n,$i}") && ("$s" eq "$s2{$n,$i}")) &&
((($tH eq "00") || ($tH eq "06") || ($tH eq "12") || ($tH eq "18")) && ($tH ne $tH1))){
$loeschen = 1; # Fall 4 Readings gleich und Plotwechsel --> letzten Eintrag loeschen und Zusatzeintrag auf YYYY-MM-DD_HH:00:00
$zusatz = 1;
Log $LL,"Filelog Zeile 186 >>>> Fall 4 <<<< Readings gleich und Plotwechsel"; # Debugausgabe
}
open( $IN, '<', $logfile) or die $!; # Logfile oeffnen und in Array @input einlesen
@input = <$IN>;
close $IN;
foreach $line(@input){ # Zeilenweises Vergleichen der eingelesenen Werte mit dem letzten Reading
if("$line" ne "$v\n") { # wenn die Zeile nicht mit dem letzten Reading uebereinstimmt
push @input1,$line; # uebernehmen in @input1
} else{
if(("$loeschen" == "1") && ("$zusatz" == "1")){ # Fall 4
$new = "$t"." $n"." $s1{$n,$i}";
substr($new,14,5,"00:00");
$new .= " >>>>> Zeit durch Filelog geaendert <<<<<\n";
Log $LL,"Filelog Zeile 199 letzten loeschen $v"; # Debugausgabe
Log $LL,"Filelog Zeile 200 Zusatz schreiben $new"; # Debugausgabe
push @input1,$new;
} elsif(("$loeschen" == "0") && ("$zusatz" == "1")){ # Fall 3
$new = "$t"." $n"." $s1{$n,$i}";
substr($new,14,5,"00:00");
$new .= " >>>>> Zeit durch Filelog geaendert <<<<<\n";
Log $LL,"Filelog Zeile 206 letzten schreiben $v"; # Debugausgabe
Log $LL,"Filelog Zeile 207 Zusatz schreiben $new"; # Debugausgabe
push @input1,$new;
push @input1,$line;
} else{ # Fall 2
Log $LL,"Filelog Zeile 211 letzten loeschen $v"; # Debugausgabe
}
}
}
@output = sort @input1; # sortieren, was beim Zusatzeintrag durcheinandergekommen ist
open( my $OUT, '>', $logfile) or die $!; # Logfile zum schreiben oeffnen und in Array @output schreiben
foreach $line(@output){
print $OUT $line;
}
close $OUT;
}
CHANGEENDE: # Fall 0 und 1
Log $LL,"Filelog Zeile 223 schreiben $t $n $s\n"; # Debugausgabe
$t2{$n,$i} = $t1{$n,$i}; # befuellen der Variablen $vorletzteTIME
$t1{$n,$i} = $t; # befuellen der Variablen $letzteTIME
$s2{$n,$i} = $s1{$n,$i}; # befuellen der Variablen $vorletzteREGEXP
$s1{$n,$i} = $s; # befuellen der Variablen $letzteREGEXP
##################################### Ende Aenderungen fuer change, debug ##########################################################
hat vom System her sehr gut funktioniert,
- immer nur den ersten Änderungswert behalten,
- und den aktuellen Wert,
- zu Plotwechselzeiten einen neuen Wert generiert
einziger haken war, das das Plotfile jedesmal neu geschrieben wurde, aber das würde ja bei einer Datenbank entfallen.
Bin gerade erst auf DbLog umgestiegen, und habe noch viel zu viel anderes auf dem Zettel.
Aber vielleicht kannst Du den Code-Schnipsel ja als Anregung gebrauchen.
Gruß Joachim
Hi Joachim,
was sind Plotwechselzeiten? Ein Plat kann einen halben Tag, einen ganzen Tag, eine Woche oder Monat oder Jahr darstellen. Die Wechselzeiten sind also immer von der Darstellung abhängig.
@ChrisD: diese vielen Unions und Subselects sehen ziemlich ressourcenintensiv bzw nicht performant aus... :(
Moin Tobias,
Mit den Plotwechselzeiten meine ich 00:00 / 06:00 /12:00 / 18:00 Uhr. Damit ist sichergestellt, dass kein Plotabriss in den normalen Ansichten erfolgt, hier wird, wie bei AddLog einfach ein zusatzreading generiert. Die SVG ist von Rudi schon so angepasst, dass für einen Plot ein Wert um 00:00:00 und 06:00:00 Uhr ausreicht, um den viertel Tag sauber anzuzeigen. Bei allen Wechselzeiten größer 1 Tag ist durch den 00:00:00 Eintrag sichergestellt, dass der Plot vollständig angezeigt wird.
Ansonsten wird ein Log, dass ungefähr so aussieht:
+---------------------+-----------------------+------+--------------------------+--------------------+-------------------------+-------+
| 2014-01-03 15:50:26 | thermostat_wohnzimmer | MAX | desiredTemperature: 20.0 | desiredTemperature | 20.1 | °C |
| 2014-01-03 15:49:23 | thermostat_wohnzimmer | MAX | desiredTemperature: 20.0 | desiredTemperature | 20.0 | °C |
| 2014-01-03 15:48:22 | thermostat_wohnzimmer | MAX | desiredTemperature: 20.0 | desiredTemperature | 20.0 | °C |
| 2014-01-03 15:47:20 | thermostat_wohnzimmer | MAX | desiredTemperature: 20.0 | desiredTemperature | 20.0 | °C |
| 2014-01-03 15:46:19 | thermostat_wohnzimmer | MAX | desiredTemperature: 20.0 | desiredTemperature | 20.0 | °C |
| 2014-01-03 15:45:18 | thermostat_wohnzimmer | MAX | desiredTemperature: 20.0 | desiredTemperature | 20.0 | °C |
| 2014-01-03 18:44:13 | thermostat_wohnzimmer | MAX | desiredTemperature: 20.0 | desiredTemperature | 20.0 | °C |
| 2014-01-03 18:43:12 | thermostat_wohnzimmer | MAX | desiredTemperature: 20.0 | desiredTemperature | 20.0 | °C |
| 2014-01-03 18:42:07 | thermostat_wohnzimmer | MAX | desiredTemperature: 20.0 | desiredTemperature | 20.0 | °C |
| 2014-01-03 18:41:07 | thermostat_wohnzimmer | MAX | desiredTemperature: 20.0 | desiredTemperature | 20.1 | °C |
| 2014-01-03 18:40:06 | thermostat_wohnzimmer | MAX | desiredTemperature: 20.0 | desiredTemperature | 20.0 | °C |
soweit eingedanpft:
+---------------------+-----------------------+------+--------------------------+--------------------+-------------------------+-------+
| 2014-01-03 15:50:26 | thermostat_wohnzimmer | MAX | desiredTemperature: 20.0 | desiredTemperature | 20.1 | °C |
| 2014-01-03 15:49:23 | thermostat_wohnzimmer | MAX | desiredTemperature: 20.0 | desiredTemperature | 20.0 | °C |
| 2014-01-03 18:00:00 | thermostat_wohnzimmer | MAX | desiredTemperature: 20.0 | desiredTemperature | 20.0 | °C |>>>>> Zeit durch Filelog geaendert <<<<<
| 2014-01-03 18:42:07 | thermostat_wohnzimmer | MAX | desiredTemperature: 20.0 | desiredTemperature | 20.0 | °C |
| 2014-01-03 18:41:07 | thermostat_wohnzimmer | MAX | desiredTemperature: 20.0 | desiredTemperature | 20.1 | °C |
| 2014-01-03 18:40:06 | thermostat_wohnzimmer | MAX | desiredTemperature: 20.0 | desiredTemperature | 20.0 | °C |
Das hat zur Folge, dass z.B. der Batteriestatus für einen ganzen Tag aus nur 4 Werten besteht, der Plot zu jeder Tageszeit ansehlich ist, aber trotzdem z.B. alle 5 Minuten ausgelesen wird, um zeitnah reagieren zu Können.
Gruß Joachim
Hallo,
@Tobias: Performance-Probleme habe ich keine feststellen können, was aber wahrscheinlich mit der eingesetzten Hardware und Datenbank zusammenhängt. Bei mir ist der Unterschied nicht messbar.
@Joachim: Das funktioniert aber nicht mit endPlotNow, da hier die Plotwechselzeiten variabel sind.
Grüße,
ChrisD
Moin ChrisD,
der Code-Schnipsel sollte als Anregung (ggf. zum abkupfern) dienen, und wenn soetwas integriert wird, dann mit einem attr steuerbar sein. Wer unbedingt endPlotNow benötigt, wird nicht drumherumkommen, wirklich alle Werte in der Datenbank zu halten.
Auf der anderen Seite ist es wirklich Irrsinn, von einem Device, dass nur 1 mal im Jahr (Batterie) seinen zustand ändert, alle 5 Minuten einen Eintrag in der Datenbank zu haben, nur damit der Plot vernünftig aussieht.
Gruß Joachim
wenn es um ein event geht das nur ein mal im jahr auftritt ist es aber sich unpassend eine kurve zu zeichnen. ein punkt oder ein histogramm hat die probleme mit den löcher nicht und ist viel passender. auch bei nur einem Wert im jahr.
gruss
andre
Mensch Andre,
das war nur ein Extrembeispiel mit der Batterie eines Sensors.
Fenster/Türüberwachung für eine Alarmanlage wäre z.B. ein anderes Beispiel. Hier ist es z.B. wichtig, in kurzen Abständen zu loggen, auch wenn die Terrassentür im Winter die ganze Zeit zu ist, also eine Statusänderung lange Zeit nicht erfolgt. Um trotzdem einen sinnvollen Plot zu erreichen, muss in entsprechend kurzen Zeiten ein event-min-intervall reading erzeugt werden (z.B. alle 10 Minuten also 144 Logeinträge am Tag gegen 4 mit dem Vorschlag / Codeschnipsel den ich gepostet habe.
Anderes Beispiel wäre im Frühjahr / Herbst der Heizungsthermostat, solange es warm genug ist, ist die Heizung aus, es wird aber trotzdem fleissig geloggt.
Und es gibt wahrscheinlich noch diverse weitere Beispiele, in denen es sinnvoll ist, nach event-on-change reading die Daten zu reduzieren.
Wer es nicht haben möchte, muss es ja nicht aktivieren.
Mein Vorschlag kam nur auf die Äußerung von Tobias
Zitatsoetwas steht schon auf meiner TODO Liste fürs DBLog Modul.
Mangels Zeit und detaillierteres Umsetzungskonzept noch nicht weiter dazu gekommen...
Der Codeschnipsel enthält zumindest ein Umsetzungskonzept, welches funktioniert, von mir schon ca 1 Jahr mit Filelog genutzt wurde, und "nur" noch auf DBLog adaptiert werden muss.
Habe teilweise das Gefühl dass Neuerungen ersteinmal zerredet werden.
Gruß Joachim
ich wollte weder etwas zerreden noch zweifle ich an das man das loggen und die plots noch deutlich optimieren kann. aber das beispiel mit der batterie war wirklich schlecht.
auf der anderen seite logge ich seit fast einem jahr auch sehr häufige events per sqlite und habe keine probleme damit. d.h. eine lösung sollte dann auch wirklich eine verbesserung sein die in jeder Zoom stufe und mit jedem plot range funktioniert.
vielleicht wäre eine möglichkeit sich mit limit 1 jeweils den tatsächlich jeweils ersten wert der rechts und links außerhalb liegt zu holen. das müsste in jeder zoom stufe funktionieren.
gruss
andre
Moin Andre,
Mal kurz ein Beispiel aus dem letzten Monat:
2013-12-04_22:10:03 HK_Regler_Gaestezimmer battery: ok
2013-12-04_22:10:03 HK_Regler_Gaestezimmer desiredTemperature: 15.0
2013-12-04_22:10:03 HK_Regler_Gaestezimmer valveposition: 0
2013-12-04_22:10:19 Temp_Sensor_Gaestezimmer temperature: 17.75 °C
2013-12-05_00:00:00 Temp_Sensor_Gaestezimmer temperature: 17.75 °C >>>Zeit durch Filelog geaendert um Logabriss zu verhindern<<<
2013-12-05_00:00:00 HK_Regler_Gaestezimmer battery: ok >>>Zeit durch Filelog geaendert um Logabriss zu verhindern<<<
2013-12-05_00:00:00 HK_Regler_Gaestezimmer desiredTemperature: 15.0 >>>Zeit durch Filelog geaendert um Logabriss zu verhindern<<<
2013-12-05_00:00:00 HK_Regler_Gaestezimmer valveposition: 0 >>>Zeit durch Filelog geaendert um Logabriss zu verhindern<<<
2013-12-05_06:00:00 Temp_Sensor_Gaestezimmer temperature: 17.75 °C >>>Zeit durch Filelog geaendert um Logabriss zu verhindern<<<
2013-12-05_06:00:00 HK_Regler_Gaestezimmer battery: ok >>>Zeit durch Filelog geaendert um Logabriss zu verhindern<<<
2013-12-05_06:00:00 HK_Regler_Gaestezimmer desiredTemperature: 15.0 >>>Zeit durch Filelog geaendert um Logabriss zu verhindern<<<
2013-12-05_06:00:00 HK_Regler_Gaestezimmer valveposition: 0 >>>Zeit durch Filelog geaendert um Logabriss zu verhindern<<<
2013-12-05_12:00:00 HK_Regler_Gaestezimmer battery: ok >>>Zeit durch Filelog geaendert um Logabriss zu verhindern<<<
2013-12-05_12:00:00 HK_Regler_Gaestezimmer desiredTemperature: 15.0 >>>Zeit durch Filelog geaendert um Logabriss zu verhindern<<<
2013-12-05_12:00:00 HK_Regler_Gaestezimmer valveposition: 0 >>>Zeit durch Filelog geaendert um Logabriss zu verhindern<<<
2013-12-05_12:00:00 Temp_Sensor_Gaestezimmer temperature: 17.75 °C >>>Zeit durch Filelog geaendert um Logabriss zu verhindern<<<
2013-12-05_12:05:09 HK_Regler_Gaestezimmer temperature: 16.8
2013-12-05_16:04:18 HK_Regler_Gaestezimmer temperature: 16.8
2013-12-05_17:00:28 Temp_Sensor_Gaestezimmer temperature: 17.75 °C
2013-12-05_17:05:28 Temp_Sensor_Gaestezimmer temperature: 17.63 °C
2013-12-05_17:10:28 Temp_Sensor_Gaestezimmer temperature: 17.75 °C
2013-12-05_17:20:38 Temp_Sensor_Gaestezimmer temperature: 17.75 °C
2013-12-05_17:25:43 Temp_Sensor_Gaestezimmer temperature: 17.63 °C
2013-12-05_17:30:48 Temp_Sensor_Gaestezimmer temperature: 17.75 °C
2013-12-05_17:35:54 Temp_Sensor_Gaestezimmer temperature: 17.75 °C
2013-12-05_17:40:59 Temp_Sensor_Gaestezimmer temperature: 17.63 °C
2013-12-05_17:56:16 Temp_Sensor_Gaestezimmer temperature: 17.63 °C
2013-12-05_18:00:00 HK_Regler_Gaestezimmer battery: ok >>>Zeit durch Filelog geaendert um Logabriss zu verhindern<<<
2013-12-05_18:00:00 HK_Regler_Gaestezimmer desiredTemperature: 15.0 >>>Zeit durch Filelog geaendert um Logabriss zu verhindern<<<
2013-12-05_18:00:00 HK_Regler_Gaestezimmer valveposition: 0 >>>Zeit durch Filelog geaendert um Logabriss zu verhindern<<<
2013-12-05_18:01:20 Temp_Sensor_Gaestezimmer temperature: 17.75 °C
2013-12-05_18:06:24 Temp_Sensor_Gaestezimmer temperature: 17.63 °C
2013-12-05_18:11:29 Temp_Sensor_Gaestezimmer temperature: 17.75 °C
2013-12-05_18:16:33 Temp_Sensor_Gaestezimmer temperature: 17.63 °C
2013-12-05_19:11:32 Temp_Sensor_Gaestezimmer temperature: 17.63 °C
Alle Readings waren auf 5 Minuten eingestellt.
Zitatd.h. eine lösung sollte dann auch wirklich eine verbesserung sein die in jeder Zoom stufe und mit jedem plot range funktioniert.
Ich glaube, die linke Seite des Filelogs wird so gemacht.
Zitat aus der 92_Filelog.pm:
Zitat# If no value found for some of the required columns, then look for the last
# matching entry outside of the range. Known as the "window left open
# yesterday" problem
Gruß Joachim
Hallo,
Ich verwende die Version mit LIMIT 1 seit mehreren Monaten, allerdings nicht mit SQLite sondern leicht modifiziert mit SQL Server 2005. Der gepostete Code funktioniert aber so mit SQLite.
@Joachim: Mein Post sollte keine Kritik an deinem Code sein. Ich wollte nur darauf hinweisen dass er bei aktiviertem 'endPlotNow' den gewünschten Effekt nicht optimal erzielt.
Grüße,
ChrisD
@ ChrisD und Andre,
Gut, vergeben, hatte mich nur geärgert, dass die Antworten nur "negatives" enthielten.
Der großte Vorteil für mich war, dass die Plots auf einer langsamen FB7570 nach Datenreduzierung genial schnell aufgebaut wurden, und das ohne nennenswerte Qualitätsverluste. Hatte allerdings nie endPlotnow in Betrieb.
Nachteil war die massive Beanspruchung des USB-Sticks, deshalb nie veröffentlicht.
Gruß Joachim
Hallo,
ZitatNachteil war die massive Beanspruchung des USB-Sticks, deshalb nie veröffentlicht.
Ich hab an meinem RasPi eine USB-HDD für DbLog mit sqlite3 im Einsatz.
Darf ich dir beim testen helfen?
Kann ich dir überhaupt beim testen helfen?
Grüße
Moin Puschel74,
noch gibt es nichts zu testen, es sei denn, Du willst wieder auf's FileLog umsteigen.
Gruß Joachim
Hallo,
Zitat03 Januar 2014, 22:33:05
ZitatBin gerade erst auf DbLog umgestiegen, und habe noch viel zu viel anderes auf dem Zettel.
Ich dachte der Beitrag war auch von dir.
Sorry - hab ich mich vertan.
Grüße
Der Beitrag war von mir, allerdings hatte ich den Logauszug von Markus Niemann angepasst, um zu illustrieren, wie es aussehen könnte. Noch gibt es hier nichts, was man testen könnte.
Gruß Joachim
Hallo,
ZitatNoch gibt es hier nichts, was man testen könnte.
Ok. Ich biet mich mal an wenn es soweit sein sollte ;D
Grüße
Mensch Puschel,
nicht so gierig.
Aber ich habe mir gerade mal DbLog angesehen, mein Code ist relativ einfach ab Zeile 392 zu integrieren.
Dafür muss noch nicht einmal was aus der Datenbank gelöscht werden, da das aktuelle reading in die Datenbank current geschrieben wird.
Das bedeutet, wenn das aktuelle Reading identisch mit dem reading current und history ist, und Bedingung zum löschen gegeben ist,
aktuelles reading --> current
current nicht nach history
Rest bleibt unverändert.
mal sehen, was tobias dazu sagt.
Gruß Joachim
auf jeden fall hört sich das ganz gut an...
Macht doch einen Patch, dann checke ich das ins contrib ein zum breiten testen. Bitte diese Funktionalität per Attr steuern.
Auf meiner TODO-Liste steht die Idee mit der Aggregation und dem daraus resultierenden Löschen... Meine Postgresql-DB ist zZ. 2GB groß
Moin Tobias,
versuche mich gerade daran, vielleicht schaffe ich das heute noch.
Habe mir heute nacht das ganze durch den Kopf laufen lassen, und es müsste funktionieren.
Auch dieser Punkt
Zitat@Joachim: Das funktioniert aber nicht mit endPlotNow, da hier die Plotwechselzeiten variabel sind.
wird wahrscheinlich kein Problem darstellen, wenn man SVG den richtigen Start und End-wert beim get unterjubelt.
da weiß ich allerdings noch nicht, wie das zu integrieren ist. Das ist dann aber der 2. Schritt.
Gruß Joachim
Hallo zusammen,
gibt es zum Thema dbLog aufräumen was Neues?
@Joachim: wie weit bist du gekommen.
Ich habe auch das Problem, dass die fhem.db anwächst und ich da gerne gegensteuern würde. Daher hole ich das Thema mal wieder hoch.
Gruß, zYloriC
Moin zYloriC,
hat sich für mich mit logproxy erledigt.
http://www.fhemwiki.de/wiki/LogProxy
Gruß Joachim
Evtl. ist das ja auch was für den ein oder anderen: http://forum.fhem.de/index.php?topic=41089
Gruß
Claudiu