Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)

[ch.eick]

Okay,
ich habe einfach einen Docker Container verwendet. Der ist wohl zu alt.

Code Auswählen Erweitern


MySQL [fhem]> select version();
+-----------------+
| version()       |
+-----------------+
| 5.5.60-0+deb7u1 |
+-----------------+


Hast Du einen Link zu einem aktuellen Container und ne Schnellanleitung fuer den Umzug?
Einen Dump mit DBRep habe ich schon getestet, das wird sicher der schnellste weg sein.
Welches MySQL oder Maria Image verwendet Ihr? Am liebsten waere mir ein Docker Container, weil man ja nicht alles selber machen kann

Im Container habe ich mal einen update versucht...

Code Auswählen Erweitern


root@raspberrypi:/# apt-get install mysql-server
Reading package lists... Done
Building dependency tree
Reading state information... Done
mysql-server is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
root@raspberrypi:/#


[DS_Starter]

Hi Christian(?),

Welches MySQL oder Maria Image verwendet Ihr? Am liebsten waere mir ein Docker Container, weil man ja nicht alles selber machen kann

Ich selbst benutze Docker im DB Umfeld nicht sondern verwende die Pakete auf meiner Synology und greife remote darauf zu.

Aber wie sieht es damit aus ?  -> https://hub.docker.com/r/mariadb/server

Scheint mir perfekt.
Ansonsten wäre es vielelicht besser für diese Frage einen separaten Thread aufzumachen. Sonst denke ich geht die Fragestellung hier möglicherweise unter.

Für den Umzug....

Einen Dump mit DBRep habe ich schon getestet, das wird sicher der schnellste weg sein.

Ja, passt.
Alternativ würde ich persönlich, weil meine DB auch schon recht groß ist, die Variante mit Standby-DB wählen. Beschrieben habe ich es hier im Wiki: https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#Inhalte_einer_prim.C3.A4ren_Datenbank_in_eine_andere_Standby-Datenbank_.C3.BCbertragen_.28syncStandby.29

Vorteil ist, dass das Ganze smooth parallel im Hintergrund abläuft. Wenn man zu Beginn wegen fehlender Übung Fehler macht ist das auch nicht kritisch. Standby gelöscht und neu created -> neuer Versuch bis es rennt.

LG,
Heiko

[ch.eick]

Hallo Heiko,

vielen Dank fuer die Tipps.
Ich habe mir DBRep mal naeher angeschaut, da ist so wie ich das sehe alles drin, was ich brauche. Somit macht es sinn, dass ich da erst mal weiter mache.

Mein Export ist erst 890 MB gross und ich raeme immer sehr streng auf. Was interessiert mich das wetter von vor drei Monaten
Firmenbedingt stehe ich auch eher auf Hotstandby DB, aber alles zu seiner Zeit und es sollte im Rahmen bleiben.

Viele Gruesse
    Christian

[flummy1978]

Hallöchen zusammen,

ich habe mein Aufräumwahn lange nicht mehr aktiv gehabt, weil ich (auf dem LiveSystem) relativ gute Einstellungen hinbekommen hab um möglichst viele Infos mit mögichst wenigen Daten zu bekommen. Auf dem Testsystem läuft aktuell ein Wetter Modul mit einem neuen Gerät, was ich mir angeschafft hab und 4 Stromzähler. Dass hier die Daten nicht klein gehalten werden können, ist klar 

onTopic:

in meinem contrib liegt die Version 8.29.0.
In dieser Version habe ich wie versprochen ein Feature zur FullDay-Erweiterung eingebaut, welches hier https://forum.fhem.de/index.php/topic,104710.msg986236.html#msg986236 requestet/besprochen wurde.

Ich hätte gern die Wetter Daten so detailliert wie sie sind - Allerdings nur für 7 Tage. Danach sollen sie zusammengefasst werden (reduceLog)
Allerdings habe ich auch noch andere Daten, die erst nach 30 oder 60 Tagen in ReduceLog zusammen gefasst werden sollen.

Wie löst man das mit den neuen Attributen "timeDiffToNow" und "timeOlderThan"?

Hier kann ich nach meinem Verständniss lediglich einmal älter als angeben und nicht mal 7 mal 30 mal 60 Tage 

Edith ergänzt noch: Entweder ich habe es übersehen oder was war vorher auch besser zu löschen? Wenn ich jetzt über delEntries nicht aufpasse und falschen Tag drin hab, lösche ich mehr als gewollt. Da muss ich sagen fand ich die vorherige Einschränkung  "delentries XX[:yy] besser, weil man BEWUSST bei jedem löschen einen Zeitraum angegeben hab und nicht auf ein Attribut zurück gegriffen hat 

Für jegliche Tipps, vielen Dank im Voraus
Grüße
Andreas

[ch.eick]

Hallo Andreas,
Wie wäre ein DBRep Device pro Anforderung?
Gruß Christian

Gesendet von meinem SM-G930F mit Tapatalk

[flummy1978]

Hai Christian,

Wie wäre ein DBRep Device pro Anforderung?

wäre eine Möglichkeit..... Ich finde sie nur .....sagen wir.... unsinnig. Ich habe ja dann schon pro automatisiertes Bereinigung ein at (oder ähnliches). Dann ein zusätzliches RepDevice, dann steigt die Anzahl unnötig hoch ?
Mit Optionen kann ich es bewusst nur für diese eine Ausführung machen und nicht "aus versehen" falsche Anzahl an Tagen löschen.

Grüße
Andreas

[DS_Starter]

Hallo Andreas,

Ich habe ja dann schon pro automatisiertes Bereinigung ein at (oder ähnliches). Dann ein zusätzliches RepDevice, dann steigt die Anzahl unnötig hoch ?

Christian hat schon recht mit mehreren DbReps für die unterschiedlichen Anforderungen. Allerdings kannst du das alles mit nur  einem at Device antriggern. Stichwort heisst Chain mit den Attribut executeAfterProc.
Ich glaube ich habe es im Wiki näher erläutert, wenn nicht, kann ich heute Abend weiter unterstützen. Habe grad keine Zeit.

Die Verwendung von Attr statt Optionen ist wie immer Ansichtssache. Andere User sagen sie möchten es lieber einmal fest einstellen und die Einstellung kontrollieren, dann kann man sich nicht durch Unachtsamkeit vertippen. 

Grüße,
Heiko

[flummy1978]

Hallo Heiko,

auch Dir vielen Dank für die schnelle Antwort 

Die Ausführungen mit den at muss ich mir nochmal genauer anschauen. Diese Attribute sagen mir bis dato nichts. Muss ich aber dann in Ruhe mal lesen 

Was die Optionen in den Befehlen angeht:
Als ich mal ein Hilfs"device" (war kein Modul, sondern eine universell einsetzbare myUtils Erweiterung) vorgestellt habe (jaja es war eine sehr sehr kleine, meine erste und ich war irgendwie sehr stolz drauf  ), wurde mir u.a auch der Hinweis gegeben solche Angaben eben über Optionen oder (damit sie nicht jedes Mal eingetippt werden müssen, aber dennoch anpassbar sind) diese als readings zu machen.
Hat eben den Vorteil dass man automatisiert Optionen anpassen kann UND es nicht das Böse Fragezeichen in der Config gibt, weil Attribute geändert wurden......

Mir ist es einfach aus dem Grund aufgefallen, weil ich meine Testsystem Datenbank genauso aufräumen wollte wie damals meine LiveSystem. Dort waren dann eben schnelle Anpassungen möglich lösche älter als x... Lösche älter als y wenn..... Usw. ReducelLog 60 xy.....  ReducelLog 30....... Reduce log 7......  Das war eine Sache  von wenigen Minuten.

Nun muss ich jedesmal die Attribute ändern und wehe ich vertippe mich hier mal oder vergesse d:7 aufd:60 zu ändern vor dem Löschen.... Dann ist eine Menge weg 
Ich persönlich sehe hier die viel größeren Gefahren als ein einfaches Vertippen. Wenn man ehrlich ist, nutzt kaum ein Anfänger dieses Tool.
Ich habe zb früher mal was mit Datenbanken gemacht aber erst nach ca. 1 jahr  von Log datei auf DBLog umgestellt.... Config bis heute nicht getraut -.-

Viele Grüße
Andreas

P. S. Unsinnige groß klein / Schreibfehler bitte ignorieren..... Bin unterwegs und das Tablett hat eine sagen wir eigensinnige Autokorrektur

[DS_Starter]

Hallo Andreas,

Nun muss ich jedesmal die Attribute ändern und wehe ich vertippe mich hier mal oder vergesse d:7 aufd:60 zu ändern vor dem Löschen.... Dann ist eine Menge weg 

Naja, so ist die Philosophie der DbRep-Anwendung nicht gedacht.
Es sollen keinesfalls immer die Attribute eines Devices geändert werden. Die Idee hinter DbRep ist, dass man sich für alle regelmäßig anfallenden Auswertungsaufgaben ein DbRep anlegt, mit den Attributen einstellt und dann wiederholt ausführt.

Als Beispiel sei die Auswertung einer PV-Anlage genannt -> https://wiki.fhem.de/wiki/Datenbankgest%C3%BCtzte_Erstellung_der_Energiebilanz_einer_SMA_PV-Anlage_mit_%C3%9Cberschusseinspeisung

Alle Werten in der dort dargestellten Tabelle werden durch jeweils ein DbRep Device geliefert. Das ist das ursprüngliche Einsatzgebiet des Moduls und deswegen werden grundlegende EInstellungen über Attribute gemacht.

Aber ich kann auch nachvollziehen, dass in bestimmten Fällen eine etwas mehr "dynamische" Verwendungsmöglichkeit gewünscht ist. Bei manchen Funktionen habe ich die Verwendbarkeit von optionalen Angaben bereits eingebaut.

So könnte ich mir speziell bei den Funktionen delEntries und reduceLog einen Einbau/Erweiterung von optionalen Angaben vorstellen. Allerdings kann es nicht den kompletten Umfang der möglichen Zeitabgrenzungen, die DbRep bietet, umfassen.
Es kann maximal eine einfache Angabe der zu berücksichtigenden +/- Tage sein, sonst wird es zu kompliziert.
Ich schaue mir das mal an.

Momentan kannst du wie schon geschrieben das Attribut executeAfterProc nutzen um eine sequentielle Ausführung von mehreren DbRep-Devices zu verketten. D.h. einmal angestartet, wird nacheinander jedes verkettete DbRep ausgeführt und arbeitet seine jeweils eingestellten Aufgaben ab.

Grüße,
Heiko

[flummy1978]

Hallöchen nochmal,

vielen herzlichen Dank für die ausführliche Erklärung der Arbeitsweise... Je länger ich darüber nachdenke umso mehr Sinn macht es auch.

Naja, so ist die Philosophie der DbRep-Anwendung nicht gedacht.

Ich habe mir das o.g. Beispiel mal angeschaut und klar, wenn ich täglich solche Auswertungen machen möchte, die ich dann ggf. anpasse macht es natürlich mehr Sinn für jedes Teil ein eigenes DBRep Device zu erstellen, anstatt wie es manch ein anderer machen würde: Ein DBRep Device, einen Dummy der das steuert, ein AT das dieses aktiviert und eine DOIF wenn weil deshalb was passiert.

WENN ich meine kompletten FileLog Dateien importiert habe, wird einmal mit der groben Kelle aufgeräumt und dann lege ich mir für die wichtigsten Dinge DBRep Devices zu, die dann Ordnung in der Datenbank halten. Mit dem Hinweis auf die Mehrfachausführung in dem AT habe ich auf jeden Fall noch ganz andere Möglichkeiten (die Aufgabe auch mit anderen Dingen zu verknüpfen)

So könnte ich mir speziell bei den Funktionen delEntries und reduceLog einen Einbau/Erweiterung von optionalen Angaben vorstellen. Allerdings kann es nicht den kompletten Umfang der möglichen Zeitabgrenzungen, die DbRep bietet, umfassen.
Es kann maximal eine einfache Angabe der zu berücksichtigenden +/- Tage sein, sonst wird es zu kompliziert.
Ich schaue mir das mal an

Ich weiss nicht welchen vollständigen Umfang Du meinst. Aber ich für meinen Teil, wäre für meine regelmäßigen NICHT automatisierten Reinigungsaktionen vollkommen zufrieden, wenn ich bei beiden bestimmten kann welches Reading und welcher Zeitraum. Das waren für mich persönlich bisher die beiden wichtigsten Funktionen. Sicherlich kann das Ding noch mehr aber bsw. del(seq)Doublets kann man auch wunderbar automatisch einsetzen, WENN man es eh in eine Abfrage setzen kann

Vielen Dank
und viele Grüße
Andreas

[DoubleD]

Hallo zusammen,

ich hänge mich hier mal ran weil das Problem ein Ähnlich ist!

@DS_Starter
Ich verwende eine SQLite Datenbank lokal am RPi ohne user und passwort!
Muss ich zwingend eine user und passwort vergeben um das Modul nutzen zu können?

Die Logausgabe mit Verbose 4

Code Auswählen Erweitern


2020.03.17 10:44:50 2: DbRep DatenbankReport - user "" doesn't have rights "INDEX" and "ALTER" as needed - try use adminCredentials automatically !
2020.03.17 10:44:50 2: DbRep DatenbankReport - ERROR - adminCredentials not set. Use "set DatenbankReport adminCredentials" first.
2020.03.17 10:44:50 2: DbRep DatenbankReport - ERROR - admin credentials are needed for database operation, but are not set or can't read it
2020.03.17 10:51:35 3: DbRep DatenbankReport - ################################################################
2020.03.17 10:51:35 3: DbRep DatenbankReport - ###                    New Index operation                   ###
2020.03.17 10:51:35 3: DbRep DatenbankReport - ################################################################
2020.03.17 10:51:35 3: DbRep DatenbankReport - Command: index recreate_Report_Idx
2020.03.17 10:51:35 2: DbRep DatenbankReport - user "" doesn't have rights "INDEX" and "ALTER" as needed - try use adminCredentials automatically !
2020.03.17 10:51:35 2: DbRep DatenbankReport - ERROR - adminCredentials not set. Use "set DatenbankReport adminCredentials" first.
2020.03.17 10:51:35 2: DbRep DatenbankReport - ERROR - admin credentials are needed for database operation, but are not set or can't read it


[DS_Starter]

HI,

Muss ich zwingend eine user und passwort vergeben um das Modul nutzen zu können?

Nein, braucht SQLite ohnehin nicht.

Diese Logs sind irreführend und ich hatte sie in der aktuellen Version eliminiert.
Update DbRep bitte mal (aktuell auf 8.32.4-s21429/2020-03-15). Dann sollte das passen.

LG,
Heiko

[ritter_runkel]

Hallo Gemeinde,
ich habe ein Verständnisproblem.

Folgendes DBRep soll eine Summierung von DB-Einträgen durchführen und das Ergebnis in die Datenbank schreiben:

Code Auswählen Erweitern


defmod Rep.Einspeisung.Strom.Jahr DbRep DBLOG
attr Rep.Einspeisung.Strom.Jahr aggregation no
attr Rep.Einspeisung.Strom.Jahr devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
attr Rep.Einspeisung.Strom.Jahr device SMA_Energy_Meter
attr Rep.Einspeisung.Strom.Jahr diffAccept 2300
attr Rep.Einspeisung.Strom.Jahr event-on-update-reading state
attr Rep.Einspeisung.Strom.Jahr group Berechnungen Solar
attr Rep.Einspeisung.Strom.Jahr reading Einspeisung_WirkP_Zaehler_Diff
attr Rep.Einspeisung.Strom.Jahr room System
attr Rep.Einspeisung.Strom.Jahr showproctime 1
attr Rep.Einspeisung.Strom.Jahr timeout 180
attr Rep.Einspeisung.Strom.Jahr timestamp_begin current_year_begin
attr Rep.Einspeisung.Strom.Jahr timestamp_end current_year_end
attr Rep.Einspeisung.Strom.Jahr userExitFn setDumEnergy .*:.*
attr Rep.Einspeisung.Strom.Jahr verbose 2


Dabei werden immer 2 Einträge in der Datenbank erzeugt. Das ist unabhängig vom Zeitraum über den gerechnet wird. Es erfolgen immer jeweils ein Eintrag am Anfang des Zeitraums (bspw. 2020-01-01 00:00:01) und am Ende des Zeitraums.
Im Idealfall wird nur ein Eintrag am Ende des Zeitraums erzeugt. Das macht sich auch für Grafiken sehr schön.

Ist das so gewollt?

Das ist für mich sehr unglücklich, da ich Zeiträume kaskadierend summiere und die Daten der untersten Stufe (minütliche Erfassung bspw. von SMAEM) löschen will. Bei meiner Summierung


Hat jemand eine andere Idee?

Grüße aus Leipzig
Erik

[DS_Starter]

Hallo Erik,

ja das ist so gewollt bei Aggregierungsfunktionen die keinen definierten Zeitpunkt des Auftretens haben (averageValue, sumValue).
Es folgt aus der Diskussion hier https://forum.fhem.de/index.php/topic,105787.msg1014562.html#msg1014562 und ff.

Ich könnte mit vorstellen zusätzlich zu der Option writeToDB eine weitere Option  writeToDBSingle (z.B.) anzubieten die generell nur einen Point schreibt.
Überlege aber grad noch ob sich evtl. schon mit den jetzt eingebauten Mitteln dieses Verhalten erreichen lässt ...

LG,
Heiko

[ritter_runkel]

Hallo Heiko,
danke für das Angebot. Ich nehm das gerne an.
Hintergrund der ganzen Aktion (Du hast es vielleicht am Listing gesehen) ist die Idee Deine PV-Auswertung aus dem WIKI mit mehr Datensparsamkeit zu erledigen.
Am Ende des Jahres möchte ich je interessanter Kategorie (Erzeugung, Bezug, Einspeisung) maximal 365 Datensätze zzgl. der Monatsscheiben und des Jahreswertes haben. Das sind dann auch Mengen, die man lange aufheben kann.

Idealerweise gäbe es eine Funktion, die einen Wert direkt in ein anderes Reading schreibt - also den Umweg über das Notify aus dem Wiki spart.
Für mich würde das Sinn machen

Egal was raus kommt - herzlichen Dank, dass Du Dir die Zeit nimmst.

Grüße
Erik