Mehrere DbLog Devices

[nesges]

DbLog per Regex einzuschränken kann mitunter mühsam werden. Ich habe daher testweise mal mehrere DbLog-Devices angelegt:

Code Auswählen Erweitern

define DBLOG1 DbLog sky.db.conf [AWKSB]_(HUMID|THERMO|HEIZUNG|FENSTER).*:(temperature|humidity|desiredTemperature|valveposition|onoff|T).*
define DBLOG2 DbLog sky.db.conf (Wetter|WETTER|SYSMON|FRITZ|FRITZ2):.*
define DBLOG3 DbLog sky.db.conf .*:([Bb]attery|state)
define DBLOG4 DbLog sky.db.conf CUL1:credit10ms

Bisher konnte ich keine Probleme feststellen, alle erwarteten Readings werden in die Datenbank geschrieben. Spricht irgend etwas dagegen so zu verfahren? Falls nicht würde ich das im Wiki ergänzen, da die Frage nach einer Vereinfachung der Notation schon öfter kam.

[betateilchen]

Es ist völlig normal, mehrere DbLog Devices zu haben - wo ist das Problem? Wo steht, dass das nicht gehen soll/darf/kann?

Grundsätzlich ist das aber eher dazu gedacht, mehrere unterschiedliche Datenbanken/Tabellen für verschiedene readings zu haben. Denn das, was Du da tust, ist schon ziemlich schräg und eigentlich genau das, wofür man DbLog eigentlich nicht einsetzt. Du forkst nämlich irgendwann unzählige Datenbankprozesse immer auf die gleiche Datenbank, bis irgendwann die Performance Deines gesamten fhem in die Knie geht.

Empfehlenswert und/oder sinnvoll ist Dein Vorgehen nicht.

Du sollest das bitte nicht auch noch versuchen, per Wiki zu verbreiten.

[nesges]

Das eigentliche Problem ist, dass DbLog addRegexpPart und die damit einhergehende Regex-Listen-Notation (wie zB in FileLog) nicht implementiert, sondern nur einen einzigen Regex auswertet (der zudem aus zweien concateniert ist, was die Sache zusätzlich verkompliziert). Eine etwas komplexere Auswahl an Logparametern fällt dadurch nicht nur sehr schwer, sondern wird verunmöglicht. Betrachtet man mein Beispiel, stellt man schnell fest, dass die Obermenge aus DBLOG2 und DBLOG3 mit .*:.* definiert ist. Lösbar ist das Problem dann nur noch durch relativ hohen Aufwand mit DbLogExclude. Sollte ich allerdings eine alternative, einfache Lösung übersehen habe, bin ich für einen Hinweis sehr dankbar.

Es damit aus Performancegründen nicht zu übertreiben ist auf jeden Fall ein guter Hinweis. Mein Beispiel lässt sich leicht auf drei Devices reduzieren, indem man DBLOG1 und DBLOG4 zusammen fasst; idR sollte man damit auch auskommen.

[chris1284]

ich hatte selbes "problem". entweder unzählige sachen  in den regexp mit aufnehmen oder excluden.
ich habe mich für letzteres entschieden. jedes neue device bekommt bei mir automatisch DbLogExclude verpasst (notify global:DEFINED.* attr $EVTPART1 DbLogExclude .*).
wenn ich ein device loggen will muss ich nur noch das attr löschen / anpassen (alle readings im device excluden die ich nicht will). ggf noch mit event-on-change-reading die einträge minimieren. das iat bei mir in summer der geringere aufwand.

warum ich sachen in einzelnen dbs loggen sollte erschoss sich bisher nicht. eine db mit allen daten reicht mir. es macht sich auch blöd wenn man db übergreifend plotten will OHNE weiter module wie logProxy usw

[nesges]

notify global:DEFINED.* attr $EVTPART1 DbLogExclude .*

Das ist sexy!

warum ich sachen in einzelnen dbs loggen sollte erschoss sich bisher nicht. eine db mit allen daten reicht mir. es macht sich auch blöd wenn man db übergreifend plotten will OHNE weiter module wie logProxy usw

Meine DBLOG*-Devices nutzen alle die gleiche Datenbank, das ist der "Trick" dabei und gleichzeitig das von betateilchen genannte Problem.

[marvin78]

warum ich sachen in einzelnen dbs loggen sollte erschoss sich bisher nicht. eine db mit allen daten reicht mir. es macht sich auch blöd wenn man db übergreifend plotten will OHNE weiter module wie logProxy usw

Ganz einfach: Es gibt Daten, die man eventuell länger vorhalten möchte, als andere (Wetterdaten, Energieverbrauch). Diese loggt man in eine gesonderte DB um die Tabelle, welche die anderen Daten enthält, leicht mit FHEM Mitteln (deleteOldDays) übersichtlich halten zu können. Es gibt sicher auch noch andere sinnvolle Gründe, wie bspw. die Verwendung einiger spezieller Daten in externen Anwendungen.

Es macht natürlich keinen Sinn, Daten in verschiedenen DBs zu loggen, die man danach wieder gemeinsam plotten möchte. Planung ist eben alles. Auch RegEx in DB-Log ist leichter, wenn man die Device-Namen logisch wählt. Ich denke, die Kombination von RegEx und DbLogExclude macht die Sache schon recht leicht.

[chris1284]

Das ist sexy!

ich hatte auch schon einen vorschlag gemacht ein DblogInclude mit einzubauen. das würde bei vielen devices (wie zb sysmon) den aufwand start reduzieren wenn nicht 100 readings excluden müsste sondern nur 2 includen 

einfach dblog definieren mit "logge nix" und nu in den devices zb temp und hum includen. für euch mit mehreren dbs wäre hier dann evtlnoch die angabe der db interessant.

@marvin78: klar kann man die länger zu lagernden daten in eine extra db packen, man könnte aber auch die anderen einfach  regelmäßig aus der großen "tabelle" löschen. ist sicher geschmackssache.

[SventeHof]

Hallo Chris,

a)
wie kann man denn im Device hinterlegen, welche DB genutzt werden soll?

b)
Hast du ein Beispiel, wie man die "anderen" einfach aus der Tabelle löschen kann.

Gruß
Sven

[betateilchen]

a)
wie kann man denn im Device hinterlegen, welche DB genutzt werden soll?

Umgekehrt. Du sagst der Datenbank im define, welche devices (oder devicetypen) sie loggen soll. Das geht bis auf einzelne readings.

Code Auswählen Erweitern


define fhemDbLog DbLog ./FHEM/logDB.cfg (.*:lumi.*|GW1_.*|.*:batVoltage.*|.*:measured-temp.*|.*:desired.*|.*:actuator.*|.*:valve.*|.*:Bb]attery:.*|.*:temperature.*|.*:humidity.*|.*:dewpoint.*|.*:pressure.*|Melder.*:.*|RM_.*:.*|sunDummy.*:.*|out_Regen.*:.*|.*_SenPwr.*|gds.*)


[JoeALLb]

Ich habe meine Datenbank dazu mit Partitionen versehen. Dann reicht ein log Device, und eine partition mit den Langzeitdaten. Die kurzzeitdaten werde  wieder in Wochentage aufgeteilt, so kann ich selbst am raspi ohne Verzögerung alle alten Daten sofort ohne Hänger löschen.... Und auf die Langzeittabelle habe ich sogar einen löschschutz in den Rechten hinterlegt.
Die Aufteilung kann ich entweder per triggern leicht anpassen oder per alter table die partitionsdefinition anpassen...

[SventeHof]

Alles klar .. danke für die Antworten!
Wie hast du das mit den Partitionen bei den Datenbanken gemacht? Partitionen kenne ich gerade nicht im Bereich von Datenbanken..

Gruß
Sven

[JoeALLb]

Wie hast du das mit den Partitionen bei den Datenbanken gemacht? Partitionen kenne ich gerade nicht im Bereich von Datenbanken..

Beispiel: Aufteilung in 2*7 Untertabellen. Abfragen kannst Du wie gewohnt nur die Tabelle history, wenn Du aber beispielsweise alle Logs von Montag löschen willst reicht ein

Code Auswählen Erweitern

ALTER TABLE history DROP PARTITION monNolong  ;
Das geht praktisch ohne Verzögerung selbst am rpi. Nun, ich will eigentlich gar keine ganzen Montags-Logs löschen, nutze das aber
da die Aufteilung auf 7 Tabellen am langsamen rpi mit SD-Speicher schneller geht.

Code Auswählen Erweitern

CREATE TABLE history (
`TIMESTAMP` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
`DEVICE` VARCHAR(32) NOT NULL DEFAULT '',
`TYPE` VARCHAR(32) NULL DEFAULT NULL,
`EVENT` VARCHAR(512) NULL DEFAULT NULL,
`READING` VARCHAR(32) NOT NULL DEFAULT '',
`VALUE` VARCHAR(32) NULL DEFAULT NULL,
`UNIT` VARCHAR(32) NULL DEFAULT NULL,
`Longterm` TINYINT NOT NULL DEFAULT 0,
PRIMARY KEY (`DEVICE`, `READING`, `TIMESTAMP`,`Longterm`)
)
COLLATE='latin1_swedish_ci'
    PARTITION BY RANGE (WEEKDAY(timestamp))
    SUBPARTITION BY HASH (Longterm) (
        PARTITION mon VALUES LESS THAN (1) (
            SUBPARTITION monNolong  ENGINE = MyISAM,
            SUBPARTITION monLong  ENGINE = MyISAM
        ),
        PARTITION tue VALUES LESS THAN (2) (
            SUBPARTITION tueNolong ENGINE = MyISAM,
            SUBPARTITION tueLong ENGINE = MyISAM
        ),
        PARTITION wen VALUES LESS THAN (3) (
            SUBPARTITION wenNolong ENGINE = MyISAM,
            SUBPARTITION wenLong ENGINE = MyISAM
        ),
        PARTITION tur VALUES LESS THAN (4) (
            SUBPARTITION turNolong ENGINE = MyISAM,
            SUBPARTITION turLong ENGINE = MyISAM
        ),
        PARTITION fri VALUES LESS THAN (5) (
            SUBPARTITION friNolong ENGINE = MyISAM,
            SUBPARTITION friLong ENGINE = MyISAM
        ),
        PARTITION sat VALUES LESS THAN (6) (
            SUBPARTITION satNolong ENGINE = MyISAM,
            SUBPARTITION satLong ENGINE = MyISAM
        ),
        PARTITION sun VALUES LESS THAN (7) (
            SUBPARTITION sunNolong ENGINE = MyISAM,
            SUBPARTITION sunLong ENGINE = MyISAM
        )
    );

Achtung: Ich benutze bewußt KEINE Unicode-Tabelle und habe bewußt den Index angepasst, dass doppelte Einträge bei mir nicht geloggt werden können.

Über einen Trigger steuere ich nun, ob bei einem neuen Eintrag in die Spalte Longterm eine 1 oder eine 0 kommt.
Will ich nun am Freitag die nicht dauerhaft benätigten Logeinträge von Montag löschen, führe ich den oben genannten Befehl aus.

[betateilchen]

Partitionen kenne ich gerade nicht im Bereich von Datenbanken..

Das funktioniert auch nicht mit allen SQL-Datenbanken und setzt ein ziemlich tiefes Verständnis von Datenbank-Engines und deren Möglichkeiten voraus.
Meines Erachtens für fhem etwas overkill.

[linuzer]

jedes neue device bekommt bei mir automatisch DbLogExclude verpasst (notify global:DEFINED.* attr $EVTPART1 DbLogExclude .*).

Ich habe das bei mir genauso eingetragen, aber es funktioniert nicht. Habe ich irgend etwas übersehen? Hier mein ganzer Eintrag:

Code Auswählen Erweitern

define nDbLogExclude notify global:DEFINED.* attr $EVTPART1 DbLogExclude .*

[Sunny]

Moin,

Du hast die Klammern vergessen.

Viele lesende Grüße
Sunny

[linuzer]

Sehr witzig! An welcher Stelle denn genau? 

[Sunny]

Moin,

sorry, bin jetzt zuhause und habe das bei mir funktionierende notify, mit dem Deinigen verglichen und es ist Identisch!

Dazu fällt mir dann nur noch ein, hast Du Dein FHEM neugestartet nach dem Erstellen?
Apropos Neustart sollten Wir wohl auch machen!

Gruß
Sunny

[linuzer]

Neustart. Einverstanden! Gute Idee!

Also, ja, habe ich natürlich gemacht. Kann es sein, dass das notify nicht auf devices anspringt, die es schon gibt? Obwohl die bei einem Neustart doch auch "neu" hinzukommen?

Gruß
linuzer

[Sunny]

Moin,

teste es am besten wenn Du etwas neues definierst.

Sonst alle händisch oder

Ist nicht getestet, setzt es dann aber für alles in Deiner FHEM Installation.

Code Auswählen Erweitern

attr .* DbLogExclude .*

Ein Neustart ist ungleich neu definieren.

Guss
Sunny

[linuzer]

Das wäre eine sehr interessante Variante vom notify... leider funktioniert sie nicht (zumindest bei mir).

Sehr wahrscheinlich liegt das Problem tatsächlich darin:

Ein Neustart ist ungleich neu definieren.

Somit muss ich die Excludes wohl doch alle von Hand eintragen...
Aber trotzdem vielen Dank für die konstruktive Hilfe! 

Gruß,
linuzer

[Sunny]

Moin linuzer,

2. Versuch vom Tablet Dir zu antworten.

Das wäre eine sehr interessante Variante vom notify... leider funktioniert sie nicht (zumindest nicht bei mir).

Kann ich mir nicht vorstellen.
Hast Du es schon mit anlegen eines neu Device getestet?

Code Auswählen Erweitern

attr .* DbLogExclude .*

Also das ist schon auf meinem Test- und Wohnungssystem aus geführt worden.
Da das notify, ja auch nix anders erledigt, wenn man etwas neues definierst. 

Da ich nicht weiß wie viele Devices Du hast. (Meine "Fhem info", findest Du im Thread "allergy")
Überwiegt das händisch anlegen oder das löschen nach den "Code Tags"...

Viele Grüße
Sunny

[schachti]

Ich grabe mal diesen alten Thread wieder aus: meine MySQL-DB für fhem belegt inzwischen 260 MB und umfasst 3,85 Millionen Einträge. Demnächst möchte ich das gesamte System umstellen (Umzug auf RPi 4 mit USB-SSD, Migration der MySQL-DB vom lahmen NAS auf ebenfalls auf den RPi 4), und da dann sowieso gewisse Umbauten nötig sind, frage ich mich, ob es aus Performance-Sicht Sinn macht, die Logs verschiedener Geräte-Gruppe auf verschiedene Tabellen und dementsprechend mehrere DbLog-Devices zu verteilen (z.B. 1 x für Wetterdaten, 1 x Strom, 1 x Wasser, 1 x Gas, ...)?

[DS_Starter]

Da hast aber einen echt alten Thread vorgeholt.

Meiner Meinung nach macht es aus Performance Sicht zumindest bei den Schreibvorgängen wenig Sinn es zu trennen, vor allem wenn du den asynchronen Modus benutzt.
Bei Lesevorgängen, also dem Datenabruf über Plots zum Beispiel, kann es Performancevorteile geben wenn mehrere Plots im selben Raum vorhanden sind und diese Daten gleichzeitig aus der DB geholt werden sollen.
Aber ob die so sehr spürbar sind mag ich momentan nicht beurteilen, MySQL ist doch recht leistungsfähig und robust.   

Grüße,
Heiko

[schachti]

Ich habe durchaus mehrere Räume, in denen ich recht viele Plots darstelle, oft so um die 10 Plots. Genau da habe ich mir einen Vorteil erhofft, wenn nicht mehr knapp 4 Millionen Datensätze in der DB liegen, sondern vielleicht nur noch eine halbe Million.

Andererseits bringt die schnellere Hardware und die Tatsache, dass die DB bald lokal läuft, vielleicht auch schon so viel, dass man weitere Verbesserungen nicht mehr merkt.

[Frank_Huber]

wenn Dudie Datenbanken auf verschiedene Server oder zumindest verschiedene Datenträger legst wird das schon was bringen.
Wenn aber die Daten alle wieder auf der gleichen Platte liegen schrumpft das wieder zusammen.

Ich würde alles in einer DB belassen und eher auf gute Hardware setzen.

Ich hab bei mir jetzt ca 20Mio Datensätze in MySQL auf Windoes Server 2012R2.
Hatte früher auf jeder Instanz (4 produktive, 1 Test) jeweile eine eigene SQLite.
Durch das zusamenlegen auf MySQL  sind die Plots ein vielfaches schneller.