DBLog - Historische Werte ausdünnen

[gero]

Allerdings hat man dann keine Möglichkeit mehr nur einzelne Readings zu includen, bzw. müsste man für das Reading weiterhin die Database-ReadingRegExp verwenden?

Einzelne Readings wären im SELECT doch kein Problem. Sobald eine Perl-Regexp angegeben ist , müßte man allerdings im nachfolgenden Code filtern.
Ich muß aber über das Problem nochmal nachdenken.

Für die devices würde es allerdings sicherlich Sinn machen das sowohl für include als auch exclude über devspec2array zu lösen.

Wenn du Lust has hierfür einen Patch zu bauen, gerne, ansonsten schreib ich mir das mal auf die todo und mach das bei Gelegenheit (Kann aber bisschen dauern).

Mal sehen, wann ich Zeit habe. Meine TODO Liste ist auch noch ziemlich lang.

Gruß,
Gero

[zYloriC]

Hallo rapster,

danke für dein reduceLog-Feature. Es ist genau war ich gesucht hatte.

Ich habe es vor kurzem ausprobiert, leider ist meine SD parallel voll gelaufen und nun habe ich beim Schreiben in die DB-Datei folgende Fehler:
   

• DbLog: Failed to insert new readings into database: DBD::SQLite::st execute failed: database disk image is malformed at ./FHEM/93_DbLog.pm line 465.
• DbLog: Failed to insert new readings into database: DBD::SQLite::st execute failed: attempt to execute on inactive database handle at ./FHEM/93_DbLog.pm line 465.

    (siehe auch http://forum.fhem.de/index.php/topic,42714.msg351612.html#msg351612)

Hast du eine Idee, wie ich sowas wieder behoben bekomme. Ich habe erst mal eine neue DB angefangen, da leider mal wieder kein geeignetes Backup da war...
Könnte ein erneutes reduceLog es besser machen? oder schlimmer? Wird die DB bei einem reduceLog zunächst mit einem LOCK versehen?

PS: Parallel grüble ich aktuell hier (http://forum.fhem.de/index.php/topic,43279.msg352645.html#msg352645) wie ich meine DB schlank bekomme.
Habt ihr eine Idee? Ich wollte mit der Frage nicht das Thema hier sprengen. Gerne aber den Link zu meiner Frage herstellen.

Besten Dank für eure Ideen. Viele Grüße,
zYloriC

[rapster]

Da deine SD vollgelaufen ist, hast du nun leider eine beschädigte sqlite-Datei, deswegen erhälst du den "malformed" fehler.
Sqlite bietet hierfür integrity check Funktionen, sowie kannst du versuchen die Daten in eine neue sqlite-datei zu dumpen.
Siehe hier: http://www.sqlite.org/faq.html#q21
Oder einfach mal nach "sqlite database disk image is malformed" googlen, da findet sich recht viel.

Gelockt selber wird das file nicht, allerdings arbeitet reduceLog mit Tranactions, ich kann leider nicht sagen wie sich das DB-File verhält wenn mitten während einer Transaction die Disk vollläuft 

Wegen dem schlank bekommen, hast du bestimmt schonmal einen Blick ins Wiki geworfen oder? http://www.fhemwiki.de/wiki/DbLog

Gruß
  Claudiu

[zYloriC]

Hi rapster,

vielen Dank für deinen schnellen Hinweis.

Wie bekomme ich inf Fhem etwa "PRAGMA schema.quick_check; " an die SQL übergeben? Funktioniert das als userCommmand?
Wie muss ich "PRAGMA schema.quick_check; " anpassen, damit sich meine DB angesprochen fühlt?

Gruß, zYloriC

[rapster]

Du musst die Befhele direkt über den sqlite Konsole ausführen.

Also in der Linux shell mit "#sqlite3 meindb.db" die Datenbank öffnen und dann den Befehl eingeben.

[mdorenka]

hallo zusammen,

ich habe mir den code gerade angeschaut - wird das AVG bestimmen wirklich in PERL durchgeführt?
warum nicht das DBMS das ganze selbst machen lassen?
Ich hatte das mal für mich umgesetzt, allerdings schon etwas länger her.

https://github.com/mdorenkamp/fhem_dbcleansing/blob/master/cleanse.sql

viele grüße
marcel

[rapster]

ja bei reduceLog wird i.M. alles in Perl erledigt.
Du kannst allerdings gerne einen Patch bereitstellen der das für die supporteten Datenbanktypen (SQLITE, MYSQL, ORACLE und POSTGRES) anders implementiert.

[mdorenka]

ich bin gerade an der umsetzung, dabei ist mir jedoch ein problem aufgefallen. die zeitzone. wird das momentan überhaupt in irgendeiner form betrachtet und entsprechend korrigiert? wir bewegen uns ja zwischen +1 und +2h offset zu utc

[JoeALLb]

Und wo genau liegt das Problem In meiner DB wird die Ortszeit eingetragen, nicht die UTC. somit sehe ich hier keine Schwierigkeiten...?!?

[mdorenka]

ganz einfach: keine bzw doppelte werte zwischen 2 und 3 uhr an den tagen an denen es zum wechsel zwischen MEZ und MESZ kommt

[gadget]

Hallo,

ich wollte mal fragen ob es Bestrebungen gibt auch rrd-Datenbanken bei dblog zu unterstützen. Mit denen würde das Problem die Daten nachträglich aufwändig auszudünnen gar nicht erst stellen ...
Beruflich habe ich viel mit Nagios zu tun, da ist das seit Jahren der defacto-Standard um historische Daten zu speichern und zu visualisieren und das Ganze funktioniert mit rrd auch sehr performant und ressourcensparend  für viele  Messwerte gleichzeitig (z.B. Auslastung der Switchports eines Unternehemnsnetzwerks, da kommen problemlos viele tausend Messwerte pro Sekunde zusammen).

Grüße,

gadget

[Sunny]

Moin Claudiu,

wollte mal nach horchen, ob Dir schon etwas zu folgendem

... für z.B. Temperatur-Daten die Möglichkeit für 1 Minute, 5 Minuten oder 15 Minuten Intervalle "ein zubauen".
...
Ich würde mich sehr darüber freuen...

...
Werde mir mal Gedanken drüber machen wie sich das am besten einbauen lässt, denke da an sowas wie "average=min=<mins>", und falls mir was gutes einfällt bei Gelegenheit einbauen

eingefallen ist ?


Vielen Dank & viele Grüße
Sunny

[rapster]

Moin Sunny,

ja eingefallen schon, nur leider zeitlich noch keine Möglichkeit gehabt... 

Denke wird leider auch noch ein bissi dauern, stehn davor noch paar andere Sachen auf der ToDo zu denen ich leider genausowenig komme, aber vergessen hab ichs nicht 

Gruß
  Claudiu

[dev0]

rrd-Datenbanken bei dblog zu unterstützen

Das passt nicht zusammen, dblog ist ein sql wrapper. Unterhalb von ./contrib/rrd findest Du aber vielleicht etwas, dass Du zur Implementierung nutzen kannst.

[Sunny]

Moin Claudiu,

bloß keinen Stress, um Diese Zeit. 
Das Du schon eine Idee hast freut mich.

Danke & eine entspannte Zeit
Sunny