93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)

[DS_Starter]

Hallo Marco,

ich gehe stark davon aus, dass es in deiner DB keinen Wert für den 31.10.2019 des besagten Devices/Readings gibt.
Dadurch gibt es für den Werteparser keinen Anfangswert zur Berechnung der Tagesdifferenz und die Resultierende ist quasi "unendlich" -> wird nicht ausgegeben ab V 4.8.0.

Zur Lösung schlage ich dir vor, einfach einen definierten Anfangswert in der DB zu speichern, z.B. 0 oder du weißt welchen kWh-Wert du dort besser platzieren solltest. Am 01.12. sollte sich dieses Problem  von allein erledigen.

Läuft dein DbLog im asynchronen Mode, kannst du einfach diesen Befehl nutzen:

Code Auswählen Erweitern


set <name> addCacheLine 2019-10-31 23:00:00|HM_6CF841_IEC_01|CUL_HM|manual|kWh|0|


Ansonsten gehen Einfügungen auch einfach über ein DbRep-Device.

Grüße,
Heiko

[firebladerx52]

Vielen Dank.

Hab einen wert für den 31.10.2019 eingetragen -> funktioniert!

Gruß
Marco

[DS_Starter]

Hallo miteinander,

in diesem Thread https://forum.fhem.de/index.php/topic,106769.0.html wurde berichtet, dass das Eventsplitting dann nicht richtig funktioniert, wenn der Value eines Events leer ist.

In dem vorliegenden Fall ist es tatsächlich so, dass das Fehlen eines Wertes "vermuten" lässt, es handele sich um das state-Reading obwohl "state" als Reading mitgeliefert wird. Es ist der default wenn das Attribut addStateEvent nicht explizit 0 gesetzt wird.

Ich habe die Defaultzerlegung so angepasst, dass ein solcher Fall berücksichtigt wird. Der Test war bei mir und im obigen Thread erfolgreich, würde mich aber freuen wenn der eine oder andere auch noch testen würde.

Die Testversion 4.9.4 liegt in meinem contrib.
Zum Download in der FHEMWEB Kommandozeile inklusive der Ausführungszeichen angeben:

Code Auswählen Erweitern

"wget -qO ./FHEM/93_DbLog.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbLog.pm"

Danach FHEM restarten.

LG,
Heiko

[jnewton957]

Hallo,

ich suche nach einer Optimierung des Löschens von Einzelwerten nach dem Motto: Was interessiert mich das reading von gestern.

Ich messe alle 30 Sekunden den Aktuellen Stromverbrauch im Haus und lasse schreibe das als dummy in ein Device "Aktueller Verbrauch".
Früher habe ich das brav über ein FileLog geloggt und hatte eben jeden Tag Werte. Ab und zu habe ich dann die Logdatei gelöscht. Durch die vielen Schreibvorgänge auf der SD Karte hatte ich dann auch schon mal saubere crashes.


Nun habe ich auf dbLog umgestellt. Klar kann ich den AktuellerVerbrauch dort entweder mit dblogInclude oder eben der dblog.conf als |AktuellerVerbrauch.:.*| in die Datenbank schreiben.

Aber auch hier sind es mir zuviele Werte und letztlich brauche ich die von gestern nicht in der Detaillierung.

Im TabletUI möchte ich aber einen Tageschart haben. Also muss ich loggen.

Wie bekomme ich nun automatisch z.B. alle Werte AktuellerVerbrauch vom Vortag (oder älter 24 Stunden) aus der Datenbank (ohne die dabei zu korrumpieren,zerstören ect??

Danke für die Hilfe
Jörg

[DS_Starter]

Hallo Jörg,

für Pflegemassnahmen von Datenbankdaten gibt es das Modul DbRep. Es stellt umfangreiche Möglichkeiten bereit Daten auszudünnen, zu verändern und zu löschen.
Es können relevante Zeiträume, devices und readings festgelegt werden.
Der einfachste Fall ist im Wiki hier beschrieben (delEntries): https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#.28regelm.C3.A4.C3.9Figes.29_l.C3.B6schen_von_Datenbanks.C3.A4tzen

Ansonsten schau dir im DbRep auch mal die set-Befehle delDoublets, delSeqDoublets und reduceLog an.

Weiterhin gibt es eingebaute Möglichkeiten für Backup und Restore. Ein valides Datenbankbackup sollte immer ! verfügbar sein.

Grüße,
Heiko

[Morgennebel]

Wie bekomme ich nun automatisch z.B. alle Werte AktuellerVerbrauch vom Vortag (oder älter 24 Stunden) aus der Datenbank (ohne die dabei zu korrumpieren,zerstören ect??

Hier ist ein .gplot für Heute und Gestern, Werte pro Stunde am Beispiel eines Regenmessers aus DBLOG (so heißt das DbLog-Device):

Code Auswählen Erweitern


# Created by FHEM/98_SVG.pm, 2019-11-10 17:46:51
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title 'Regenmenge'
set ytics
set y2tics
set grid
set ylabel ""
set y2label "Niederschlag mm/qm"
set yrange [0:]
set y2range [0:]

#LP_LogProxy DbLog:DBLOG,offset=24*60*60:DI_RainGaugeStats:RainNewValue::delta-h
#DBLOG DI_RainGaugeStats:RainNewValue::delta-h

plot "<IN>" using 1:2 axes x1y2 title 'mm/qm Gestern' ls l2 lw 1 with steps,\
     "<IN>" using 1:2 axes x1y2 title 'mm/qm Heute' ls l7fill lw 1 with steps


Ciao, -MN

[thburkhart]

Result of encoding check

Encoding used by Client (connection): LATIN1
Encoding used by DB fhem: UTF8
Recommendation: Both encodings should be identical. You can adjust the usage of UTF8 connection by setting the UTF8 parameter in file './configDB.conf' to the right value. Your DBD version fulfills UTF8 support, no need to update DB

ich möchte einheitlich UFT8 haben
welche Einträge muss ich genau in welchen configs ergänzen ?

besten Dank

Thomas

[DS_Starter]

Hallo Thomas,

das machst du in dem Config-File für die DB Verbindung, so wie es ja ausgeschrieben wird. Bei dir heißt sie ja configDB.conf. Per default wäre es die db.conf.

Es ist der letzte Parameter:

Code Auswählen Erweitern


%dbconfig= (
connection => "mysql:database=fhemtest;host=192.168.2.10;port=3307",
user => "......",
password => "........",
utf8 => 1,
);

Grüße,
Heiko


[thburkhart]

danke schön !

[davidgross]

Hallo,

ich nutze FHEM bereits viele Jahre. Der Grund warum ich bisher noch nicht auf dblog umgestellt habe ist der Speicherverbrauch. Klar ist die SD Karte groß genug. Viele kleine Dateien lassen sich besser handhaben als eine riesige Datei, die auch noch größer ist als alle kleinen Dateien zusammen durch den Index und Overhead. Gerade in Bezug auf Backup.
Aktuell scheint dblog noch immer nur eine Tabelle zu nutzen und die Daten stumpf so abzuspeichern wie in den log files.?
Warum werden nicht die immer wieder gleichen Daten wie DEVICE TYPE READING usw. in jeweils separaten Tabellen gespeichert? Also der Aufbau einer relationalen Datenbank und und nicht einer Tabelle. Verbraucht das zu viel CPU-Performance?

Eine normale Logzeile sieht so aus:
2020-01-01_00:00:04 Hzg_Wozi_Weather measured-temp_avg_day: 18.8

dann würde nur noch dies geloggt werden müssen:
time             IndexDevices indexREADING
2020-01-01_00:00:04 1234           9876    18.8

VG

[DS_Starter]

Hallo,

Es gab auch schon vor dir ähnliche Anfragen von Usern mit einem vergleichbaren Anliegen.

Das aktuelle Modul ist schon fast so alt wie fhem selbst und ich hatte es vor ca. vier Jahren in Pflege genommen und stabilisiert dass es den Ansprüchen genügte. Auch das Datenmodell stammt noch aus der Anfangszeit. Warum es damals so und nicht anders erfolgte vermag ich nicht zu beurteilen. Vermutlich aus Vereinfachungsgründen.

Aber grundsätzlich gebe ich dir recht dass einiges verbessert werden sollte und auch das Datenmodell verbesserungeswürdig ist. Auch so manches Handling in FHEM bezüglich Definition und manuellen Tätigkeiten sind suboptimal.
Ebenfalls  ist die Indexierung bei dem jetzigen Model ungünstig weil es eben nur eine flachen Tabellenstruktur nutzt.

Um auf deine Frage zu antworten ... An dem jetzigen DbLog Modul werde ich im Hinblick auf die erreichte Stabilität und dem breiten Usereinsatz keine grundlegenden Veränderungen mehr vornehmen. Die damit einhergehende Unruhe, Supportnotwendigkeit und der Aufwand für nötige Migrationsroutinen wäre einfach zu hoch und würde meinen Zeitfonds überstrapazieren. Ich spreche da aus Erfahrung 

Aber ich habe eigentlich vor ein Nachfolgemodul zu entwickeln welches ein besseres Datenmodell und dementsprechend angepasste SQL verwendet sowie auch sonstige Nachteile des jetzigen Moduls zumindest teilweise behebt.

Bei diesem Vorhaben möchte ich mir auch die Unterstützung von DB / SQL Experten mit ins Boot holen um gleich zu Beginn einen tragfähigen Ansatz zu bauen den ich dann implementiere.
Es wäre zunächst also etwas Konzeption und Diskussionen nötig bevor es losgeht.

Die Frage ist natürlich wann das alles passiert. Ich kann es dir heute noch nicht sagen da ich auch noch ein paar eigene Projekte habe die immer wieder im Interresse der Community bei mir verschoben wurden.

Beobachte das Forum Automatisierung weiterhin und ich würde mich über deine Unterstützung freuen wenn es dann mal los gehen sollte.

viele Grüße,
Heiko

[davidgross]

Hallöchen,

ich habe mich die letzten Tage dem erstellen einer neuen DB ein wenig angenommen und mal ein kleines Grundgerüst erstellt, welches auf Basis von MariaDB eine DB anlegt, Tabellen erstellt und Daten in die Tabellen speichern kann.
Hier in den einzelnen Tabellen soll es nix doppeltes geben. Im Idealfall werden pro Logeintrag nur noch 5 Zahlen abgespeichert:
MariaDB [fhemlog]> select * from Log01;
+----------+--------------+-----------+------------+--------------+
| Log01_ID | Timestamp_ID | Device_ID | Reading_ID | ReadValue_ID |
+----------+--------------+-----------+------------+--------------+
|        1 |            1 |         1 |          1 |            1 |
|        2 |            1 |         1 |          1 |            1 |
|        3 |            4 |         1 |          4 |            4 |
|        4 |            5 |         5 |          5 |            5 |
|        5 |            6 |         5 |          5 |            6 |
|        6 |            7 |         5 |          5 |            7 |
|        7 |            8 |         5 |          5 |            8 |
|        8 |            9 |         5 |          5 |            9 |
+----------+--------------+-----------+------------+--------------+

Ich habe die Scripte angehängt.
Eine Abfrage der Daten, also das wieder einlesen habe ich noch nicht angefangen.
Auch wünschenswert ein Import aus alten log files und der alten db habe ich noch nix gemacht.

Guten Rutsch!

[kadettilac89]

Bei diesem Vorhaben möchte ich mir auch die Unterstützung von DB / SQL Experten mit ins Boot holen um gleich zu Beginn einen tragfähigen Ansatz zu bauen den ich dann implementiere.
Es wäre zunächst also etwas Konzeption und Diskussionen nötig bevor es losgeht.

Wie ist der Stand hier. Willst du das aktiv angehen, oder bleibt es wie es ist? Läuft ja auch stabil.

Wenn hier größer umgebaut wird meine Bitte ... schon mal woanders kurz angesprochen ... Integration von InfluxDB wenn möglich.

Hier in den einzelnen Tabellen soll es nix doppeltes geben. Im Idealfall werden pro Logeintrag nur noch 5 Zahlen abgespeichert:

Da ist das Normalisieren etwas zu eifrig erfolgt.

Beispiel ReadValue_ID ... es ist schneller einen Wert 100 einzufügen statt in einer eigenen Tabelle nachzusehen ob der Wert 100 schon eine value_ID hat. Außerdem werden beim Normalisieren nur Werte ausgelagert wenn mehrere Spalten von einem Feld abhängig sind. Das ist bei "Value" nicht der Fall.

Die einzigen Informationen die in eine eigene Tabelle ausgelagert werden können, sollten

ReadingID mit Feldern als Schlüssel
- Device
- Reading
- Unit

Feld Event ist (eigentlich) redundant.

Bevor hier Module gebaut werden sollten erstmal die Anforderungen gesammelt und die bekannten Probleme dokumentiert werden.

[DS_Starter]

Hallo allerseits,

danke davidgross für die Startsequenz.
Allerdings gebe ich kadettilac89 recht was die Normalisierung betrifft und würde auch nur

- Device
- Reading
- Unit

in separate Tabellen auslagern und per Fremdschlüssel in die Haupttabelle integrieren. Beim Value bin ich mir unsicher. Könnte
tatsächlich der Fall sein, dass sich im laufe der Zeit ein gewisser Wertevorrat aufbaut aus dem man per Fremdschlüssel partizipieren könnte.
Wir müssen auch die contraints beim Löschen von Datensätzen berücksichtigen etc.

Wie ist der Stand hier. Willst du das aktiv angehen, oder bleibt es wie es ist? Läuft ja auch stabil.

Wenn hier größer umgebaut wird meine Bitte ... schon mal woanders kurz angesprochen ... Integration von InfluxDB wenn möglich.

Bis jetzt habe ich für mich noch keinen Projektstart gesetzt. Das Modul werde ich mit dem Projektnamen  DbLogNG (NG= new Generation) starten.
Das bisherige 93_DbLog wird im Grunde so bleiben wie es ist, nur Bug Fixes, Code Restrukturierung wo nötig usw habe vor umzusetzen. Insbesondere an der DB-Struktur wird sich aber nichts ändern. Ich will an dieser Stelle Ruhe haben, sonst frisst der Support meine Zeit auf und ich habe keine Ressourcen für etwas Neues.
Momentan arbeite ich an einer DbRep Code Restrukturierung um auch in diesem Modul die Vorraussetzung für eine spätere Verwendung zur Datenpflege zu haben.

Für DbLogNG starte ich am Besten einen neuen Projektthread hier in Automation und lade alle zur Mitarbeit ein.

Ein erfolgreiches Jahr 2022 wünsche ich uns allen !
Heiko

[kadettilac89]

Für DbLogNG starte ich am Besten einen neuen Projektthread hier in Automation und lade alle zur Mitarbeit ein.

Ein erfolgreiches Jahr 2022 wünsche ich uns allen !
Heiko

Ob es nötig ist kannst nur du entscheiden. Du machst ja den ganzen Support Sooo schräg finde ich das aktuelle Tabellendesign auch nicht. Es ist auf Performance ausgelegt.

Wenn jemand (z. B. Anforderung davidgross) die DB auf mehrere Tabellen aufteilen will geht das ggf. sogar mit insertable views in MySql und kleinen Änderungen. Müsste man sich ansehen sofern Bedarf besteht.

Solltest du es machen wollen wäre das sicher interessant und lehrreich. Vor allem wenn man InfluxDb mit aufnehmen könnte da diese DB so performant ist. Aber das würde SVG und andere Änderungen nach sich ziehen sonst ist der Mehrwert in keinem Verhältnis zum Aufwand.

@davidgross, was ist dein genaues Problem, von welcher DB-Größe sprichst du? Welche Probleme bereitet dir das Backup?