Probleme beim Einrichten von dbLog

[betateilchen]

Die Feldlängen wurden ja autoamtisch mit dem Skript erstellt:

Code Auswählen Erweitern

CREATE DATABASE `fhem` DEFAULT CHARACTER SET utf8 COLLATE utf8_bin;
CREATE USER 'fhemuser'@'%' IDENTIFIED BY 'fhempassword';
CREATE TABLE `fhem`.`history` (TIMESTAMP TIMESTAMP, DEVICE varchar(32), TYPE varchar(32), EVENT varchar(512), READING varchar(32), VALUE varchar(32), UNIT varchar(32));
CREATE TABLE `fhem`.`current` (TIMESTAMP TIMESTAMP, DEVICE varchar(32), TYPE varchar(32), EVENT varchar(512), READING varchar(32), VALUE varchar(32), UNIT varchar(32));
GRANT SELECT, INSERT, DELETE, UPDATE ON `fhem`.* TO 'fhemuser'@'%';
CREATE INDEX Search_Idx ON `fhem`.`history` (DEVICE, READING, TIMESTAMP);


Das war die im Ordner abgelegte Datei: /opt/fhem/contrib/dblog/
Irgendwo habe ich zwischendurch gelesen, dass diese Datei nicht aktualisiert ist.

Nur mal so zur Info: die aktuelle Datei
./contrib/dblog/db_create_mysql.sql
sieht so aus:

Code Auswählen Erweitern

##################################################################################
# Note:
# =====
# The default installation of the MySQL/MariaDB database provides
# for the use of the utf8mb4_bin collation.
# With this setting characters up to 4 bytes long (e.g. emojis) can be stored.
# 
# If the MySQL/MariaDB version used does not offer utf8mb4 for some reason, utf8
# can be used instead.
# In this case the MySQL/MariaDB database would be created with the
# following statement:
#
#   CREATE DATABASE `fhem` DEFAULT CHARACTER SET utf8 COLLATE utf8_bin; 
#
# instead of the statement:
#
#   CREATE DATABASE `fhem` DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;
#
# shown in the first line below.
#
##################################################################################
CREATE DATABASE `fhem` DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;
CREATE USER 'fhemuser'@'%' IDENTIFIED BY 'fhempassword';
CREATE TABLE `fhem`.`history` (TIMESTAMP TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, DEVICE varchar(64), TYPE varchar(64), EVENT varchar(512), READING varchar(64), VALUE varchar(128), UNIT varchar(32));
CREATE TABLE `fhem`.`current` (TIMESTAMP TIMESTAMP, DEVICE varchar(64), TYPE varchar(64), EVENT varchar(512), READING varchar(64), VALUE varchar(128), UNIT varchar(32));
GRANT SELECT, INSERT, DELETE, UPDATE ON `fhem`.* TO 'fhemuser'@'%';
CREATE INDEX Search_Idx ON `fhem`.`history` (DEVICE, READING, TIMESTAMP) USING BTREE;


und da sind die Werte korrekt.

Ich habe mich an eine gefundene Anleitung gehalten und hänge nun eben wie oben beschrieben.
Ich habe auch absolut keine Ahnung wie ich die Tabellen mit einem Script anlegen kann.

Keine Ahnung, nach welchem alten Kram Du da vorgegangen bist.

Fang doch einfach nochmal komplett von vorne an, nimm die in FHEM verfügbare Dokumentation (und nicht irgendwas aus dubiosen Dritt-Quellen) und dann wird es auch funktionieren.
Du bist schließlich nicht der erste Anwender, der sein Logging mit DbLog einrichten möchte.

[RalfRog]

Je nachdem wie gut du die Korrekturen in der Datenbankinstallation umgesetzt hast ist der Vorschlag von betateilchen nicht das Schlechteste

Fang doch einfach nochmal komplett von vorne an, nimm die in FHEM verfügbare Dokumentation (und nicht irgendwas aus dubiosen Dritt-Quellen) und dann wird es auch funktionieren.
Du bist schließlich nicht der erste Anwender, der sein Logging mit DbLog einrichten möchte.

Das war die im Ordner abgelegte Datei: /opt/fhem/contrib/dblog/
Irgendwo habe ich zwischendurch gelesen, dass diese Datei nicht aktualisiert ist. Daher haben wohl auch die Spaltenbreiten nicht gepasst.

Genau... allerdings stimmen die Feldlängen schon seit mindestens 5 Jahren. Deine lokale contrib ist seeehr alt.

Auch in der CommandRef/Hilfe ist ein Verweis/Link auf die aktuelle Version der SQL-Scripte.

Code Auswählen Erweitern

Beispielcode bzw. Scripts zum Erstellen einer MySQL/PostgreSQL/SQLite Datenbank ist im SVN -> https://svn.fhem.de/trac/browser/trunk/fhem/contrib/dblog enthalten.
(Achtung: Die lokale FHEM-Installation enthält im Unterverzeichnis ./contrib/dblog nicht die aktuellsten Scripte!)


Scheinbar wird da ziemlich viel in deine DB geloggt. Hast du das so umgesetzt?

Code Auswählen Erweitern

Beispiel:
    define myDbLog DbLog /etc/fhem/db.conf .*:.*
    speichert alles in der Datenbank Besser fängst du etwas kleiner an und loggst erstmal nur ein Device "<Name>:.*"  statt ".*:.*"

Welche Angaben oder Screenshots wären noch sinnvoll für die Fehlersuche?
Irgendwie rutsche ich aktuell von Problem zu Problem.....kaum ist das der eine Fehler behoben taucht der nächste auf.

Da hilft schon ein List des Logging-Devices.

Generell solltest du im Vorfeld mal überlegen was genau alles in die Datenbank soll. So wie es jetzt aussieht platzt die ja schon nach einem Tag.

[Knallfrosch]

Hallo,

ja, hätte ich das mit der aktuellen Datei nicht nur gelesen, sondern auch umgesetzt wäre mir einiges an Stress erspart geblieben.
Lernen durch Schmerz oder so ähnlich.
Ja, meine Installation ist schon alt und daher war eben auch die Datei stark veraltet.

Nachdem ich nochmal alles durchgegangen bin, hat es dann gestern Abend auch funktioniert.
Die Daten werden auch komplett in die Datenbank geschrieben.

Es sind allerdings tatsächlich viel zu viele Daten.
Aktuell sind nach ca. 12h schon fast 240.000 Datensätze angefallen.
Hier muss ich nochmal sehr genau drüber schauen und die Datenflut reduzieren.


Danke für eure Hilfe.

Grüße

[Klaus_R]

Es sind allerdings tatsächlich viel zu viele Daten.
Aktuell sind nach ca. 12h schon fast 240.000 Datensätze angefallen.
Hier muss ich nochmal sehr genau drüber schauen und die Datenflut reduzieren.

Ich habe das so gelöst. Für jedes Device sind 2 Attribute gesetzt.

Code Auswählen Erweitern

attr Dev_Brauchwasser DbLogExclude .*
attr Dev_Brauchwasser DbLogInclude DS18B20-1_Temperature
Das erste schält das komlette loggen aus. Das zweite wählt dann aus was doch gelogt werden soll.
Mein Device im Beispiel heisst "Dev_Brauchwasser". Gelogt soll dann nur der Wert des Temperatursensors "DS18B20-1_Temperature" werden.
Damit das ganze funktioniert muss wohl auch das Attribut DbLogType in deinem DBlog-Device auf Current/History gesetzt werden.

Code Auswählen Erweitern

attr Dev_DBLog DbLogType Current/History
Falls Du viele Devices hast kannst Du zumindest das eintragen von "DbLogExclude .*" in einem Rutsch erledigen (für das "wie" kann Dir hier sicher jemand helfen)  Die Wahl der gewünschten Readings mus man wohl eher von Hand machen.

Ausserdem kann es ein Notify geben das die Eintragung für jedes neu angelegte Device automatisch macht.

Da ich mich selbst noch zu den "Anfängern" zähle "keine Gewähr"


Gruss Klaus

[Knallfrosch]

Hallo Klaus,

vielen Dank für diesen super Tipp!
Das klingt ziemlich vielversprechend.

Damit werde ich mich dann noch ausführlich beschäftigen um die benötigten Werte zu selektieren.

Grüße

[betateilchen]

Es gibt m.E. bessere und einfachere Wege, sowas festzulegen, als in jedem device entsprechende Attribute zu pflegen. Seit Jahren pflege ich das, was gelogged werden soll, im DEF des DbLog devices, dadurch habe ich nur eine einzige Stelle, an der ich ggf. Änderungen anpassen muss.

Hier ein Beispiel aus meiner Testinstallation, in der ich nur bestimmte devices (diese aber mit allen readings) logge:

Code Auswählen Erweitern

defmod dbLog DbLog ./sqldb/dblog.conf (bme688_1|ub4|owo_Jork|yrno_Jork|Jork_Wetter|CUX_Wetter):.*

Das Ganze geht natürlich auch beliebig komplex:

Code Auswählen Erweitern

defmod fhemDbLog DbLog ./conf/logDB.cfg (pidActor.*|pid.actuation:..|pid.measured:.*|pid.desired:.*|st_fl_PIR_Motion:.*|mqtt_erdgas:full.*|.*motion:.*|.*Super.*|.*lumi.*|.*measured.*|.*desired.*|.*level.*|.*temperature.*|.*humidity.*|.*pressure.*|out_Regen.*|owo.*)

Hier werden sowohl gelogged:

• bestimmte devices mit allen readings: out_Regen.*
• bestimmte readings aller devices: .*temperature.*
• ein bestimmtes reading aus einem bestimmten device: mqtt_erdgas:full.*

[Knallfrosch]

Hallo,

argh....jetzt hatte ich die Datenbank nochmal komplett gelöscht. In 24h waren es schon über 600.000 Einträge.
Ich habe zwar noch einiges an Platz auf der NAS, aber die Datenmenge macht natürlich keinen Sinn.

Ich habe nun mal alle Readings mit DBExclude eingeschlossen und nur ein einzelnes Reading mit DBInclude eingeschlossen.

Und siehe da.....es kommt nichts in der Datenbank an.

Meine Fehlersuche brachte mich auf das Attr: DbLogSelectionMode dieses habe ich nun auf Include gesetzt....damit wird nun auch das definierte Reading in die Datenbank geschrieben.

Wie ich die Selektion der einzelnen Readings machen werde, muss ich mir nochmal überlegen.
Danke für das Zeigen der beiden Möglichkeiten.

Grüße

[Knallfrosch]

Hallo,

ich habe noch ein Problem!

Ich habe nun das Reading ENERGY_Power mit DbLogInclude mit der Datenbank verbunden.

Das Reading wird im 30s-Takt durch MQTT beschrieben.

Nun wollte ich das Reading zum reduzieren der Datenmenge nur alle 60sec. in die Datenbank schreiben.

Versucht habe ich

Code Auswählen Erweitern

attr Solarertrag_2 DbLogInclude ENERGY_Power:60
trotzdem erfolgt alle 30sec ein Eintrag in der Datenbank.

Wie muss ich hier ansetzen, damit der Eintrag nur in der definierten Zeit übertragen wird?

Vielen Dank.

Grüße

[Christian83]

event-min-interval und event-on-change-reading

[Knallfrosch]

event-min-interval und event-on-change-reading

Ok, Danke!

Ich hatte gehofft, ich könnte das mit einem attr erschlagen.


Grüße

[RalfRog]

Ich hatte gehofft, ich könnte das mit einem attr erschlagen.

Lt. CommandRef müsste das gehen:

Code Auswählen Erweitern

DbLogInclude Regex[:MinInterval][:force],[Regex[:MinInterval][:force]], ...

    Mit dem Attribut DbLogInclude werden die Readings definiert, die in der Datenbank gespeichert werden sollen.
    Die Definition der zu speichernden Readings erfolgt über einen regulären Ausdruck und alle Readings, die mit dem regulären Ausdruck matchen, werden in der Datenbank gespeichert.
    Der optionale Zusatz <MinInterval> gibt an, dass ein Wert dann gespeichert wird wenn mindestens <MinInterval> Sekunden seit der letzten Speicherung vergangen sind.
    Unabhängig vom Ablauf des Intervalls wird das Reading gespeichert wenn sich der Wert des Readings verändert hat.
    Mit dem optionalen Modifier "force" kann erzwungen werden das angegebene Intervall <MinInterval> einzuhalten auch wenn sich der Wert des Readings seit der letzten Speicherung verändert hat.

                | Modifier |         innerhalb Intervall          | außerhalb Intervall |
                |          | Wert gleich        | Wert geändert   |                     |
                |----------+--------------------+-----------------+---------------------|
                | <none>   | ignorieren         | speichern       | speichern           |
                | force    | ignorieren         | ignorieren      | speichern           |
Mit dem Parameter force wird  erst gespeichert wenn das hinter dem Doppelpunkt angegebene Intervall abgelaufen ist.
             

[Christian83]

Ich hatte gehofft, ich könnte das mit einem attr erschlagen.

Lt. CommandRef müsste das gehen:

Code Auswählen Erweitern

DbLogInclude Regex[:MinInterval][:force],[Regex[:MinInterval][:force]], ...

    Mit dem Attribut DbLogInclude werden die Readings definiert, die in der Datenbank gespeichert werden sollen.
    Die Definition der zu speichernden Readings erfolgt über einen regulären Ausdruck und alle Readings, die mit dem regulären Ausdruck matchen, werden in der Datenbank gespeichert.
    Der optionale Zusatz <MinInterval> gibt an, dass ein Wert dann gespeichert wird wenn mindestens <MinInterval> Sekunden seit der letzten Speicherung vergangen sind.
    Unabhängig vom Ablauf des Intervalls wird das Reading gespeichert wenn sich der Wert des Readings verändert hat.
    Mit dem optionalen Modifier "force" kann erzwungen werden das angegebene Intervall <MinInterval> einzuhalten auch wenn sich der Wert des Readings seit der letzten Speicherung verändert hat.

                | Modifier |         innerhalb Intervall          | außerhalb Intervall |
                |          | Wert gleich        | Wert geändert   |                     |
                |----------+--------------------+-----------------+---------------------|
                | <none>   | ignorieren         | speichern       | speichern           |
                | force    | ignorieren         | ignorieren      | speichern           |
Mit dem Parameter force wird  erst gespeichert wenn das hinter dem Doppelpunkt angegebene Intervall abgelaufen ist.
             

Oh das kannte ich gar nicht.
Aber dann scheint wichtig zu sein:

Code Auswählen Erweitern

Das Attribut DbLogSelectionMode muss entsprechend gesetzt sein um DbLogInclude zu aktivieren.

[RalfRog]

...
Versucht habe ich

Code Auswählen Erweitern

attr Solarertrag_2 DbLogInclude ENERGY_Power:60
trotzdem erfolgt alle 30sec ein Eintrag in der Datenbank.

Wie muss ich hier ansetzen, damit der Eintrag nur in der definierten Zeit übertragen wird?
...

Aufgrund #21/22 ist der DbLogSelectionMode wohl richtig gesetzt.

[Knallfrosch]

So:

Code Auswählen Erweitern

attr Solarertrag_2 DbLogInclude ENERGY_Power:60:force
klappt es, wie ich mir das vorgestellt habe.

Danke.

Grüße

[Knallfrosch]

Hallo,

ich arbeite nun schon etwas mit dbLog und komme auch halbwegs damit klar.

Jedoch habe ich ein Problem mit der DB selbst.

Ich greife auf die DB mit phpmyadmin auf meiner Synology-NAS zu.
Dabei ist mir aufgefallen, dass seit einiger Zeit die Anzahl der Datensätze nicht mehr ansteigt.
Aktuell werden also neue Datensätze zwar eingetragen, aber damit eben die älteren Überschrieben.

Das wollte und will ich nicht.
Allerdings habe ich nirgends eine Einstellung für eine "Größenbegrenzung" gefunden.

Aktuell hat meine DB -805274- Datensätze
Du darfst diesen Dateianhang nicht ansehen.

Wie schaffe ich es auch noch mehr Datensätze speichern zu können?

Ich habe in FHEM auch kein Attr. zum löschen von Daten o.ä. bewusst angelegt.
Es scheint also eine Default-Einstellung zu sein!?

Danke für eure Hilfe.

Grüße