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

Begonnen von DS_Starter, 19 Mai 2016, 22:52:13

Vorheriges Thema - Nächstes Thema

DerFrickler

Zitat von: DS_Starter am 19 August 2016, 09:17:48
Prinzipiell wäre soetwas sicherlich umsetzbar mit definierten Rahmenbedingungen. Also wenn Fehler,  dann x mal wiederholen mit Abstand y -> sonst Error. (Endlosschleifen vermeiden)
Welches Scenario schwebt dir denn da konkret vor ?  Es wäre wahrscheinlich nicht nötig bei jeder Selektionsvariante eine solche Zusatzfunktion vorzusehen.
ich benutze aktuell ausschliesslich diffValue

Zitat von: DS_Starter am 19 August 2016, 09:17:48
Ich war auch nicht untätig und habe in das Modul ein Attribut "timeOlderThan" eingebaut was quasi das Gegenstück zu "timeDIffToNow" ist.
Wird dieses Attribut gesetzt, werden alle Selektionen bzw. Löschungen alle alten  Datensaätze in der DB BIS zu dem Zeitpunkt <aktueller Timestamp>-<timeOlderThan> (dynamisch kalkuliert) ausgeführt.

Also wenn das Attr auf z.B. 172800 (s) gesetzt ist, denn werden alle Datensätze in der DB die älter als 1 Tag sind und den sonstigen Bedingungen wie Device bzw. Reading entsprechen, gelöscht. 
Das geht bei aktuell noch relativ einfach über deleteOldDays, da ich alle Werte Tagesgenau kappe. Aktuell nutze ich zwei DBs, eine für die Daten die ich lediglich für 3 Tage aufbewahre (Charts) und dann noch eine die mir Zählerdaten für 2 Jahre aufbewahrt. Beide werden nachts mit Hilfe von deleteOldDays gekappt. Interessant wäre die neue Funktion für die Kurzzeitdaten... dann könnte ich bei einer einzelnen Datenbank bleiben, nur leider werden genau diese Kurzzeitdaten nicht mit DbRep ausgewertet.

Zitat von: DS_Starter am 19 August 2016, 09:17:48
Ich hänge die neue Version V3.5 wieder in den Eingangsthread und ergänze die Doku. Über das WE will ich die commandref noch beschreiben und das Modul mit dem Entwicklungsstand auch wieder einchecken.
Mal sehen ob ich in den nächsten Tagen zum Testen komme....

DerFrickler

kann man die aktuelle Moduldatei auch direkt mit einem "sudo wget" runter laden? Ich habe gerade meinen Testrechner nicht in Reichweite und müsste die Datei remote via terminal auf's System bringen.

DS_Starter

Zitatkann man die aktuelle Moduldatei auch direkt mit einem "sudo wget" runter laden?

Du kannst sie von meiner Synology runterladen:  https://gofile.me/2KVvT/mRprfHgn

ZitatDas geht bei aktuell noch relativ einfach über deleteOldDays

Ja, ich weiß. Nur arbeitet timeOlderThan wie das gesamte Modul nonblocking. Außerdem kannst du die Selekt/Löschfunktion natürlich wieder auf ein spezielles device und/oder reading beschränken.

Zitatnur leider werden genau diese Kurzzeitdaten nicht mit DbRep ausgewertet.

Damit meinst du sicherlich dass die Daten der Tabelle "history" betrachtet werden. Ich verwende ausschließlich die Tabelle "history" für alle Daten. Was ich nur kürzer in der DB haben möchte lösche ich halt wieder nach der Zeit x raus (mit dieser Funktion). Der Nutzen der Tabelle "current" ist mir bisher nicht so wirklich transparent geworden. Allerdings könnte ich durchaus die Funktionen wiederum über ein Attribut  wahlweise auf "current" oder "history" anwendbar machen.
War das mit "Kurzzeitdaten" gemeint ?

viele Grüße
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DerFrickler

Mit Kurzzeitdaten meine ich Daten die ich lediglich für 3-7 Tage speichere, da mich eine längere Darstellung nicht interessiert. Mit Langzeitdaten meine ich Daten die ich 2 Jahre lang speichere. Dazu gehören z.B. Zählerstände oder Verbrauchsdaten die im mit dem Vorjahr vergleiche.

DS_Starter

Hallo Karsten.

dann habe ich deine Anmerkung ...

ZitatInteressant wäre die neue Funktion für die Kurzzeitdaten... dann könnte ich bei einer einzelnen Datenbank bleiben, nur leider werden genau diese Kurzzeitdaten nicht mit DbRep ausgewertet.

noch nicht richtig verstanden. Kannst du mit anderen Worten nochmal beschreiben was du damit meinst ?
Wenn ich es verstanden habe läßt sich bestimmt auch etwas machen.

Grüße,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DerFrickler

Kurzzeitdaten: Daten die ich nur für kurze Zeit 3-7 Tage speichere
Langzeitdaten: werden für knapp 2 Jahre gespeichert

Situation:
Wenn ich alle Daten in eine DB schreiben würde, dann wären dass 3-4 unterschiedliche Readings die ich für einen längeren Zeitraum (2 Jahre) behalten möchte und den Rest lediglich für 3-7 Tage. Die 3-4 Langzeitdaten (die Readings dazu) sind recht einfach zu identifizieren (da überschaubar), die restlichen Kurzzeitdaten (die Readings dazu) separat aufzulisten ist schon etwas Arbeit.

Deshalb die 2 DBs
DB 1: Zählerstände für 2 Jahre
DB 2: der Rest (über include gemanagt); hier gehen auch der Einfachheit halber die selben Daten aus DB 1 mit aufgenommen, aber halt nur für die 3-7 Tage Ansicht

Wenn ich jetzt nur eine DB hätte und für die Langzeitdaten ein deleteOldDays durchführen würde, dann ist das für die Kurzzeitdaten unbedenklich, da eh für den Zeitraum nicht mehr von Interesse. Wäre die Situation jetzt genau umgekehrt... 3-4 Kurzzeitdaten und der Rest Langzeitdaten, und die 3-4 Kurzzeitdaten würden über DbRep ausgewertet, könnte ich innerhalb einer einzigen DB die Datenflut durch ein gezieltes delete (Deine neue Funktion) beheben. Leider ist es aber genau umgekehrt und ich möchte auch nicht für alle Kurzzeitdaten (die Readings dazu) ein DbRep einführen. Deshalb die beide DBs, die ich täglich mit deleteOldDays bearbeite.

DS_Starter

Ok, jetzt habe ich es verstanden, denke ich  ;)

Für mich heißt das , du hast (sehr) viele unterschiedliche device/reading-Kombinationen in der DB mit einem kurzen Soll-Lebenszyklus. Um diese selektiv zu löschen müßtest du dementprechend viele spezifische DbRep-Devices anlegen um dieses Sätze selektiv zu löschen. Das wäre in deinem Fall mit recht hohem (einmaligen) Aufwand versehen.

Adhoc fällt mir dazu ein dass ich die device/reading Spezifikation auf Regex (Like-Selektion in DB) umstellen könnte. Aber das habe ich mit Absicht bisher vermieden um nicht unbeabsichtigt falsche Datensätze mit zu berücksichtigen/zu löschen. Deswegen würde ich im DbRep gern darauf verzichten.

Allgemein habe ich noch vor eine Export/Import-Funktion zu implementieren, dass man Daten selektiv archivieren bzw. in eine andere Datenbank verschieben kann. Nur so als Aussicht.

viele Grüße
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DerFrickler

Das Problem mit den 2 DBs sollte jetzt nicht ein Problem sein was mit dem DbRep Modul gelöst werden sollte. Ansonsten hätte ich da noch etwas...

Ich hatte in meinen DbRep Instanzen noch ein User-Reading angelegt: currentPowerMeasurement. Kann es sein dass bei jeder Neukalkulation (diffValue) alle Readings ausnahmslos erst einmal gelöscht werden?

DS_Starter

ZitatKann es sein dass bei jeder Neukalkulation (diffValue) alle Readings ausnahmslos erst einmal gelöscht werden?

Ja, das stimmt. Es sollen keine Readingleichen verbleiben. Die Db Selekt-Ergebnisse können sich ständig ändern. Daten gelöscht und Zeitgrenzen dynamisch verschoben werden. Aber ich sehe dein/das Problem...

EDIT. Wobei ... Userreadings ist ja ein Attribut und wird jedesmal neu berechnet. ???
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DerFrickler

Zitat von: DS_Starter am 19 August 2016, 16:56:36
EDIT. Wobei ... Userreadings ist ja ein Attribut und wird jedesmal neu berechnet. ???

wenn der Wert aus dem Originaldevice sich ändert und das notify anspricht. Aber das ist im Grunde nebensächlich.

DS_Starter

Ich könnte mir etwas überlegen das gewisse vorbestimmte Readings nicht gelöscht werden wenn so etwas gebraucht wird.
Bisher war es nicht im Fokus bzw. nötig.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DerFrickler

Zitat von: DS_Starter am 19 Mai 2016, 22:52:13
mir kam die Idee zu diesem Modul durch den Wunsch die Energiedaten meiner PV-Anlage auszuwerten.

Was für eine Anlage benutzt Du? Ich hatte vor das ganze mal im kleinen Stil in der Gartenhütte zu verbauen (natürlich ohne Einspeisung  ;) ins Stromnetz), nur suche ich noch nach einer geeigneten Installation die mir dann auch die Daten zum Haus rüber funkt bzw. mir erst mal in einer geeigneten Weise die Daten zur Verfügung stellt.

Gruß!

DS_Starter

ZitatWas für eine Anlage benutzt Du?

Ich habe eine 5 kW -Anlage auf dem Dach. Dazu alles aus dem SMA-Programm, also STP-5000, SMA Energy Meter und Sunny Home Manager.
Wahrscheinlich eine Konstellation wie sie x-mal in D vorkommen wird und demzufolge auch nichts besonderes. Den STP und den EM konnte ich problemlos über die Speedwire Schnittstelle und die Module SMAEM bzw. SMAUtils mit SBFSpot in das Heimnetz bzw. FHEM integrieren (bin dabei auf das Modul SMAInverter umzustellen).

Ich habe einen Freund der sich eine kleine Inselanlage auch für den Garten angeschafft hat lädt damit eine Batterie die dann per Inverter 220V liefern soll. Er eruiert auch gerade wie sinnoll nutzbar das ist.
Das war ein Komplettprodukt, Name/Hersteller weiß ich momentan nicht. Allerdings hat er noch nichts über FHEM gehört. Deswegen weiß er/ich auch nicht inwieweit die Ladestation netzfähig ist und über ein Interface verfügt was man anzapfen könnte.

viele Grüße,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Willi666

Hallo Heiko,

erstmal vielen Dank für das tolle Modul.
Ist genau das was ich gesucht habe.

Hätte da aber noch eine Frage. Wenn ich eine Auswertung diffValue fahren, dann erzeugt es als Reading immer einen Zeitstempel mit aktuellem Datum und Uhrzeit, wie z.B.:

2016-08-22_22-22-56__MeinStromzaehler__total_consumption__DIFF__all between timestamps

Wie kann ich dann auf das Variable Reading - z.B. beim Zuweisen auf einen Dummy - zugreifen, bzw. gibt es eine Möglichkeit die Uhrzeit wegzulassen?

Gruß
Willi


DS_Starter

Hallo Willi,

das Reading in DbRep setzt sich immer zusammen durch Blöcke

<Datum/Zeit>__<Device aus DB>__<Reading aus DB>__<Funktion ....>   

also in deinem Fall

2016-08-22_22-22-56__MeinStromzaehler__total_consumption__DIFF__all between timestamps


Weglassen geht nicht prinzipiell, da der Timestamp am Anfang ein wichtiges Sortierkriterium in der Readingsdarstellung ist (siehe ein paar Beiträge weiter vorn, EDIT: #49), zumindest wenn mehrere Readings erzeugt werden.
Aber ich habe zwischen den Blöcken einen doppelten Unterstrich als Trenner eingeführt. Den kannst du z.B. für eine Splitfunktion bzw. Regex mit Userreadings nutzen, den du dann dem Dummy zuweist. Das sollte m.M. nach funktionieren, probiers mal aus.

EDIT: Das war jetzt nicht korrekt. Userreadings wahr schon ok, aber es dient nur dazu ein eigenes Reading aus dem vorhandenen zu erzeugen.
Also wird wohl der nächste Satz eher zutreffen ...

Ich könnte mir auch noch vorstellen ein Attr einzuführen mit dem der Nutzer bewußt den führenden Timestamp abschalten kann, sofern er sich klar darüber ist dass dann unter Umständen die Reihenfolge der Ergebnisse in der Darstellung nicht eingehalten wird.

Grüße
Heiko

ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter