FHEM Forum

Hallo,

vorab kenne mich mit Datenbanken überhaupt nicht aus.

Hab heute zufällig gelesen das man mit DbRep eine CSV-File einlesen kann, aber noch nicht tiefer eingelesen wie und weiß somit auch noch nicht ob mein Vorhaben, dann die eingelesenen Daten nach einer bestimmten Spalte deren Zeilen den gleichen Inhalt haben zu filtern um dann die Summe zweier anderer Spalten zu bilden, damit überhaupt umsetzbar ist ?

Im Wiki steht zu DBRep  das der Einsatz einer DBLog-Instanz vorausgesetzt wird.

Heißt das dann ich muss auch Daten loggen oder reicht einfach die Definition der DbLog-Definition ?
Wenn ich jetzt nach (https://wiki.fhem.de/wiki/DbLog#Beispiel:_Anlegen_und_Nutzung_einer_SQLite-Datenbank) eine SQLite-Datenbank angelegt habe und wie erwähnt nur die Voraussetzng für DbRep schaffen möchte, also gar keine Events loggen, wie wäre die DEF dann korrekt, kann ich als zweiten Parameter (regexp) einfach none eintragen oder ist das gar nicht vorgesehen gar nichts zu loggen ?

Gruß

Thomas

Hallo Thomas,

Zitat
Im Wiki steht zu DBRep  das der Einsatz einer DBLog-Instanz vorausgesetzt wird.

Heißt das dann ich muss auch Daten loggen oder reicht einfach die Definition der DbLog-Definition ?

Daten musst du nicht loggen. Es reicht die DbLog Definition. Aber natürlich muß die Datenbank ordentlich eingerichtet sein, so als ob du loggen möchtest.
Ich nutze auch solche "Dummies" mit einer solchen DEF (hier eine Standby DB die ich nur mit DbRep fülle, aber nichts logge):

./maria_VM.conf aaaaaa:bbbbbb

Wenn du deine Daten mit DbRep in die DB importiert hast, kannst du beliebige SQL Statements mit dem Set Befehl sqlCmd gegen die DB ausführen. Dabei hast du alle Freiheiten.
Wenn du bei den SQL Statements Hilfe benötigst, findest du hier im Forum mit Sicherheit Unterstützung.  :)

Grüße,
Heiko

 

Danke, sehr gut das mein Vorhaben umsetzbar ist.

Also wird ein regexp benötigt der auf nix matcht, es ist keine Angabe vorgesehen die das loggen einfach unterbindet ?

ZitatAlso wird ein regexp benötigt der auf nix matcht, es ist keine Angabe vorgesehen die das loggen einfach unterbindet ?

Doch so etwas gibt es auch, wenn auch für einen anderen Zweck eigentlich. Das Attr excludeDevs kannst du verwenden:

attr <> excludeDevs .*

schließt alles (alle Devices) global vom Logging aus.

Es muss aber irgendwas als zweiter Parameter in der DEF eingetragen werden, was trag ich dann da ein, irgendeinen regexp ?

Ja, irgendwas. DbLog ist eben fürs Loggen gedacht.  ;)

OK, nochmal Danke, werde mich also dann mit/zu DbRep beschäftigen/einlesen. 

Hier https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten
findest du sicherlich einige Anregungen.

LG

Bis ich mich mit DbRep beschäftigen kann, bin ich erstmal noch damit beschäftigt die .csv die ich importieren möchte (die ich vor etwas mehr als 20 Jahren erstellt habe) meinen heutigem Verständnis anzupassen und zu optimieren, das dauert noch bis ich mich da wieder eingefuchst.

Trotzdem schonmal noch eine Verständnisfrage zu DbLog:
Die current-Tabelle brauch in meinem Fall ( -> DbLog-Dummy) doch nicht, versteh ich doch richtig ?
Die Datenbank muss aber so aufgebaut sein als ob man loggen wollte, also lass ich bspw. die current-Tabelle einfach so wie im Wiki-Beispiel und passe mir (wenn ich mal soweit bin) nur die history-Tabelle den Spalten der .csv an ?

ZitatDie current-Tabelle brauch in meinem Fall ( -> DbLog-Dummy) doch nicht, versteh ich doch richtig ?

Die current brauchst du für deine Zwecke nicht. Alle Datenhaltung passiert in der history-Tabelle.

Zitat
Die Datenbank muss aber so aufgebaut sein als ob man loggen wollte, also lass ich bspw. die current-Tabelle einfach so wie im Wiki-Beispiel und passe mir (wenn ich mal soweit bin) nur die history-Tabelle den Spalten der .csv an ?

Obacht, nicht die history-Tabelle anpassen, sondern so anlegen wie in der DbLog-Hilfe beschrieben.
Anpassen musst du die zu importierende(n) csv-Dateien, damit sie problemlos importiert werden können.
DbLog/DbRep sind auf die beschriebenen DB/Tabellenstruktur abgestimmt und können auch nur mit dieser zusammenarbeiten.

Edit: kleine Korrektur, die Spaltenbreiten der Tabelle kannst du problemlos anpassen und danach mit Attributen im DbLog anpassen.

Ich habe dir ein Beispiel-csv angehängt damit du siehst wie die csv aufgebaut sein muß. Die Datei habe ich gerade eben exportiert.

ZitatDbLog/DbRep sind auf die beschriebenen DB/Tabellenstruktur abgestimmt und können auch nur mit dieser zusammenarbeiten.

Achso, hatte jetzt angenommen die history-Tabelle kann ich mir anpassen wie ich möchte.
Es muss also die Vorgabe der Spalten TIMESTAMP,DEVICE,TYPE,EVENT,READING,VALUE,UNIT mit den entsprechenden Datentypen eingehalten werden.

Das war aber nicht das was ich vorhatte.
Ich wollte bspw. sowas wie TIMESTAMP TIMESTAMP, Bezeichnung varchar(64), Wert1 varchar(128), Wert2 varchar(128)
Also nur vier Spalten.

ZitatAnpassen musst du die zu importierende(n) csv-Dateien, damit sie problemlos importiert werden können.

Versteh ich jetzt so das ich nicht mehr wie 7 Spalten importieren kann.
Kann ich dann in meiner CSV einfach drei "dummy-Spalten" dazunehmen um die Vorgabe mit TIMESTAMP,DEVICE,TYPE,EVENT,READING,VALUE,UNIT einzuhalten, natürlich unter Berücksichtigung der Datentypen ?
Und mit DbRep trotzdem mit den SQL Statements die Auswertung nur der 4 Spalten wie oben beschrieben vornehmen ?

edit :

Und die Feld-Trennzeichen müssen Kommata sein ?
Und das (ich weiß nicht die Bezeichnung) Trennzeichen der Zeilen "nix" ?

ZitatEs muss also die Vorgabe der Spalten TIMESTAMP,DEVICE,TYPE,EVENT,READING,VALUE,UNIT mit den entsprechenden Datentypen eingehalten werden.

Je nachdem was du vorhast, kannst du die Datentypen anpassen sofern es nicht mit dem Inhalt kollidiert. Du musst auch nicht unbedingt alles füllen. Z.B. EVENT, TYPE, UNIT leer lassen ... geht auch. TIMESTAMP ist obligatorisch.
Aber die Spaltennamen müssen so heißen wie definiert.
Wenn dich das nicht behindert, kannst du auch nur 4 Spalten importieren. Die anderen mit "" füllen.

ZitatVersteh ich jetzt so das ich nicht mehr wie 7 Spalten importieren kann.

Ja, es sei denn du erweiterst dir auch die Module dazu.  ;)

Zitat
Kann ich dann in meiner CSV einfach drei "dummy-Spalten" dazunehmen um die Vorgabe mit TIMESTAMP,DEVICE,TYPE,EVENT,READING,VALUE,UNIT einzuhalten, natürlich unter Berücksichtigung der Datentypen ?

Ja, siehe zuvor.

Zitat
Und mit DbRep trotzdem mit den SQL Statements die Auswertung nur der 4 Spalten wie oben beschrieben vornehmen ?

Ja, wie gesagt kannst du mit sqlCmd beliebige Statement abarbeiten mit denen du in die Tabelle gehst.
Nur die Export/Import-Funktion und die Standard-Befehle (z.B. maxValue) sind hart an die Standard Tabellendefinition gebunden.

ZitatUnd die Feld-Trennzeichen müssen Kommata sein ?

Ja, so ist es momentan fest eingebaut.
Zeilentrenner ist Newline (\n).

Wie erwähnt hab keine Ahnung von Datenbanken.

ZitatTIMESTAMP ist obligatorisch.

Hab mich zu CREATE INDEX Search_Idx ON noch nicht eingelesen, daher die Frage: -> Ist TIMESTAMP der Primärschlüssel.

Weil dann hätt ich ein Problem, ich speichere die Uhrzeit nicht, daher kann einer auch mehrfach vorkommen:

bspw.:

31.12.2020 00:00:00 ...
31.12.2020 00:00:00 ...
...

ZitatIst TIMESTAMP der Primärschlüssel.

Nein, per default gibt es keinen Primärschlüssel.
Der Timestamp kann auch mehrfach identisch vorkommen. Aber er ist eben ein Pflichtfeld was zu füllen ist.