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

[alkazaa]

Die neue Mittelung verstehe ich auch nicht so ganz (liegt vermutlich am Fehlverständnis von Datenpunkt, Mittelungsintervall & zeitliche Grenzen (BIN)) bzw. es entsteht nicht das, was ich erwarten würde (wenn das Intervall eine Miunte ist). Am Anfang / Mitte komme ich glaube ich soweit mit.
Z.B. die Minuten 26-29 sind ohne Werte - trotzdem ist das AVG-Ergebnis der Wert von Minute 25. Müsste das nicht zumindest kleiner werden - bzw. ab wann gilt denn 0?

OK, das mit Minute 30 ist in der Tat noch ein Fehler, denn da sollte gar kein Wert sein (timestamp_begin und _end war auf 00:00:00 und 00:30:00 gesetzt, dh. in Minute 30 sollte gar kein Wert auftauchen, aber nicht 0).

Dann muss man bedenken, dass der Mittelwert eines Teilintervalls (im engl. bin) dem Zeitstempel des Intervallanfangs zugeordnet wird (das war schon immer der Fall in DbRep).

Des weiteren: die gemessenen Originalwerte in FHEM gelten ja immer so lange, bis eine neue Messung neue Information liefert. Entweder weil man nicht oft genug misst, oder weil sich der Messwert innerhalb der Auflösung des Messgeräts nicht ändert. Fairerweise müsste man also im Plot eine Stufengraphik wählen: der Messwert bleibt in der graphischen Darstellung so lange konstant, bis eine neue Messung vorliegt (mit dem gleichen oder anderen Messwert als vorher). Ich logge in FHEM aber in der Regel mit 'event-on-change-reading'.

In graphischer Darstellung wird's vielleicht klarer: die roten Punkte sind die Oiginaldaten, verbunden mit der roten Linie als Stufengraphik. Die schwarzen Punkte sind die errechneten, sie liegen jeweils zur vollen Minute auf den senkrechten Linien, mit denen die minütlichen Intervallgrenzen markiert sind. Auch diese Punkte sind als Stufengraphik dargestellt. Am Beispiel des Wertes für Minute 17 kann man sich klar machen, wie gerechnet wird: 22 sec lang galt noch der letzte Wert 0,479, dann ab Minute 17:22 der Wert 0,272 für die restlichen 38 sec. Also 0,3479=(22*0,479+38*0,272)/60. Ab Minute 26 kam kein neuer Wert, daher 0,488 bis zum Ende. Und vor Minute 11 gab es noch keine Werte im Gesamtzeitraum [00:00 bis 30:00]. Und wenn man [00:00 bis 29:59] wählt, taucht auch die irritierende 0 am Ende nicht mehr auf.

Und natürlich ist das ganze Beispiel hier zwar anwendungsfremd, aber es lässt sich halt "zu Fuss" rechnerisch überprüfen (ohne höhere Mathematik, nur mit Grundrechenarten ).

Eine gründliche Überprüfung an realen Beispielen steht noch aus. Man sollte dabei aber praktisch keine Unterschiede zwischen der alten und der neuen Methode sehen, wenn die Zahl der zu mittelnden Daten einigermaßen groß ist. 

Beste Grüße
Franz

[DS_Starter]

Hallo,

ich habe den Zeitstempelfehler bein Rückschreiben in die DB gefixt (zumindest lt. meinen Tests).
Testet es mal bitte dagegen.

Den Code von Franz habe ich noch nicht integriert. Ich wollte erstmal das eine Prob erledigen.
Kommt als nächstes dran wenn der Fix klar ist.

Liegt im contrib als 8.51.2

[RalfRog]

...
Testet es mal bitte dagegen.
...

Ich probier es aus. Muss mir nur morgen ne Datenlücke suchen, da ich gestern relativ viel zu Fuß gemacht und 23:45 meine Chain zum ersten Mal läuft 

Gruß Ralf

[RalfRog]

...
Des weiteren: die gemessenen Originalwerte in FHEM gelten ja immer so lange, bis eine neue Messung neue Information liefert. Entweder weil man nicht oft genug misst, oder weil sich  man [00:00 bis 29:59] wählt, taucht auch die irritierende 0 am Ende nicht mehr auf.

Und natürlich ist das ganze Beispiel hier zwar anwendungsfremd, aber es lässt sich halt "zu Fuss" rechnerisch überprüfen (ohne höhere Mathematik, nur mit Grundrechenarten ).
...

Super danke für die ausführliche Erläuterung. Die Idee sich das mit der Grafik zu veranschaulichen ist echt gut.
Nach dem Schnelldurchgang muss ich noch mal intensiver ran
- und tatsächlich mal meine Datenreihe vom PV Balkon-Modul anschauen ob ich am Ende der Sonnenscheindauer sauber aufhöre.
Wegen des Plots schreibe ich abends und morgens schon händisch ne 0 in die DB rein weil sonst öfter mal schiefe Linien entstehen. Irgend ein Umstand lässt öfter mal als ersten Wert um 10W erscheinen und dann geht es gemächlichab 0,5W aufwärts.

Im Grunde hat mich das Ende verwirrt in der Mitte konnte ich folgen - eben wie im Zitat:
"0,3479=(22*0,479+38*0,272)/60. Ab Minute 26 kam kein neuer Wert, daher 0,488 bis zum Ende."
Der letzte Wert muss einfach in Gedanken ala "event-on-change" gehalten werden.

[RalfRog]

Ich probier es aus. Muss mir nur morgen ne Datenlücke suchen, da ich gestern relativ viel zu Fuß gemacht und 23:45 meine Chain zum ersten Mal läuft 

Habe dummerweise doch noch schnell vor dem Chain-Lauf probieren wollen. Leider Error. Konnte das alte DBRep noch pünktlich reloaden.

Also, habe die Datei aus dem Contrib nach ~/FHEM geladen und ein "reload reload 93_DbRep.pm" gemacht.

Attribute gesetzt
aggregation       day   (versehentlich, hätte hour sein sollen)
averageCalcForm   avgTimeWeightMean
timestamp_begin   2023-01-11 00:00:00
timestamp_end   2023-01-11 23:59:59

Kommando
LASTCMD    averageValue writeToDBSingle

Log

Code Auswählen Erweitern


2023.01.12 23:32:03.067 3: WARNING: DBLogging attribute bulkInsert was renamed to insertMode
2023.01.12 23:32:03.070 1: PERL WARNING: Use of uninitialized value $cm in split at ./FHEM/93_DbLog.pm line 6931.
2023.01.12 23:32:03.072 1: PERL WARNING: Use of uninitialized value $ac in pattern match (m//) at ./FHEM/93_DbLog.pm line 6933.
2023.01.12 23:32:03.073 1: PERL WARNING: Use of uninitialized value $ta in pattern match (m//) at ./FHEM/93_DbLog.pm line 6937.
2023.01.12 23:32:03.084 1: PERL WARNING: Use of uninitialized value $name in concatenation (.) or string at ./FHEM/93_DbLog.pm line 7065.
2023.01.12 23:32:03.086 1: PERL WARNING: Use of uninitialized value $history in concatenation (.) or string at ./FHEM/93_DbLog.pm line 7065.
2023.01.12 23:32:03.087 1: PERL WARNING: Use of uninitialized value $name in concatenation (.) or string at ./FHEM/93_DbLog.pm line 7066.
2023.01.12 23:32:03.088 1: PERL WARNING: Use of uninitialized value $current in concatenation (.) or string at ./FHEM/93_DbLog.pm line 7066.

2023.01.12 23:32:13.936 2: DbRep DBRep2_MT - ERROR - DBD::mysql::st execute failed: called with 6 bind variables when 7 are needed at ./FHEM/93_DbRep.pm line 11221.


Achtung merke ich gerade erst:
Habe heute Nachmittag  17:14 Uhr ein "offizielles" Update 93_DbLog.pm & 93_DbRep.pm jeweils mit Reload der Module gemacht (kein Restart FHEM).
Seit dem (17:16:09) kommen alle 2 Minuten die 7-Log-Einträge zur DBLog.

[RalfRog]

Habe jetzt doch noch einen Fhem-Restart gemacht.

Die DBLog-Meldungen alle 2 Minuten sind weg und ich sehe im Log, dass sie schon weg waren nachdem um 23:45 mein reduceLog (nicht mehr Contrib-Version) gelaufen ist.
Hmmmm.....

Zumindest hier noch die Log Daten zum DB* beim Hochlauf:

Code Auswählen Erweitern


2023.01.13 00:06:32.031 2: DbLog DBLogging - Subprocess >22099< initialized ... ready for non-blocking operation
2023.01.13 00:06:32.047 3: WARNING: DBLogging attribute bulkInsert was renamed to insertMode
2023.01.13 00:06:34.589 2: DbLog DBTest - Subprocess >22100< initialized ... ready for non-blocking operation
2023.01.13 00:07:47.442 3: DbLog DBLogging - DB connection parameters are initialized in the SubProcess
2023.01.13 00:07:47.479 3: DbLog DBTest - DB connection parameters are initialized in the SubProcess
2023.01.13 00:07:47.524 3: DbLog DBTest - DB connection parameters are stored in SubProcess
2023.01.13 00:07:47.675 3: DbLog DBLogging - DB connection parameters are stored in SubProcess
2023.01.13 00:08:17.548 3: DbLog DBLogging - SubProcess connected to fhem


Vom DBRep im Contrib lass ich nach dem Error jetzt aber die Finger bis zur Rückmeldung.
Generell:  Reicht der Reload?

Gruß Ralf

[DS_Starter]

Moin Ralf,

die Meldungen von DbLog sind die Standardmeldungen der aktuellen Version. Im letzten Update wurde das Attr bulkInsert automatisiert umbenannt. Stand ja auch in den Update-Notes.

2023.01.12 23:32:13.936 2: DbRep DBRep2_MT - ERROR - DBD::mysql::st execute failed: called with 6 bind variables when 7 are needed at ./FHEM/93_DbRep.pm line 11221.

Da ist eines der Felder für die DB "undefined". Vermutlich ist bei dir eines der Felder ausgeblendet (Attr col... im DbLog) oder aber beim Rückschreiben "undef". Aber egal, dass muss ich abfangen und die Schreibfunktion nochmal ändern. Mache ich nachher gleich.

Generell:  Reicht der Reload?

Klare Antwort ... es kommt darauf an.
Bei "einfachen" Modulen reicht ein reload meistens. ABER ... komplexere Module lagern Funktionen in andere Library-Module aus, haben subProzesse (wie DbLog) und andere Architekturen. Dann führt der eine reload u.U. zu unpassenden Codes.
Der Normal-User kann das nicht überblicken.
Deswegen ganz klare Empfehlung ... bei Updates IMMER einen Restart machen es sei denn man weiß genau dass ein reload reicht weil man sich z.B. genauer mit dem Modul befasst hat.

LG,
Heiko

[RalfRog]

Im DBLog habe ich kein Attribut Col... gesetzt.

In den Spalten UNIT hatte ich letzte Woche mit changeValue Einheiten nachpflegt.
Vorher waren sie leer "". Die Funktionen averageValue (min, max) setzen ja (NULL) - also ohne Wert. .
Undef und (NULL) sind aber vermutlich 2 verschiedene Paar Schuhe. 

Bei normalen Updates ist ein Restart zwar gelebte Praxis aber für die beiden Module wollte ich mein Livesystem nicht rund fahren.
Mach dann zukünftig bei DBLog/Rep auf jeden Fall mit Restart.

Vielen Dank für deine Arbeit 

[DS_Starter]

So, neue DbRep liegt im contrib. Es reicht ein reload 

Naja, es kann theoretisch immer passieren dass ein errechnetes Feld undef / NULL ist. Deswegen darf kein Fehler kommen.
Sollte nun nicht mehr in der Rewrite Routine passieren.

<OT> Bei Update DbLog wegen des Subprozesses auf jeden Fall restarten </OT>

[RalfRog]

So habe die Version aus dem Contrib probiert.

Für ein Reading am 12.1  00:00:00 bis 23:59:59 mit "averageValue writeToDBSingle" und "aggregation = hour" wurde der gewichtete Mittelwert berechnet.

TYPE ist Uppercase und die Daten sind mit korrekten Zeitstempeln von 00:59:59 bis 23:59:59 eingetragen 

Gruß Ralf

[DS_Starter]

Wieder ein Fortschritt. 
Wahrscheinlich werde ich die Version heute einchecken und mich morgen dann mal an den Patch von Franz heranmachen.

[alkazaa]

Wahrscheinlich werde ich die Version heute einchecken und mich morgen dann mal an den Patch von Franz heranmachen.

Hab gerade meinen Patch in Deine neueste Version integriert und dabei gemerkt, dass ich an einer Stelle meine Änderung nicht kenntlich gemacht hatte. Daher hier jetzt der korrekt markierte patch...

Gruß
Franz

[alkazaa]

Hallo!
Ich ging bisher immer davon aus, dass die gemittelten Werte als timestamp den Beginn des Mittelungsintervalls zugeordnet bekommen, siehe die Diskussion in  meinem obigen Beitrag. Ich habe jetzt erstmals auch die gemittelten Daten abgespeichert und bemerkt, dass aber das Ende des Mittelungsintervalls zum timestamp des gemittelten Wertes wird.

Ich halte den Beginn des Mittelungsintervalls aber für die bessere Wahl, und möchte das mit den Bildern hier begründen. Dargestellt sind die gleichen Daten wir im erwähnten Beitrag, aber
a) für die Originaldaten ohne Verbindungen der Messpunkte
b) für die berechneten Daten mit direkter Verbindung der Punkte (wie es bei Liniengraphiken üblicherweise gewählt wird)

Im oberen Plot sind die avg Daten dem Intervallende zugeordnet (wie es z.Zt. in DbRep gemacht wird).
Im unteren sind sie dem Intervallanfang zugeordnet.

Ich hoffe, man erkennt warum ich das untere vorziehen würde.

-Franz

[RalfRog]

Sieht insbesondere in dieser "minutenauflösung" nachvollziehbar und logisch aus.

Bei mir persönlich ist es egal, da ich zur Zeit nur Energie als DayLast-Werte über das Statistik-Modul plotte.
Durchschnittswerte halte ich quasi nur als historischen Trend im Stunden-/Tagestakt fest um ältere Originaldaten der Zähler/Shellies deutlich zu reduzieren.

Aber ich kann mir vorstellen, dass es Fälle gibt wo es in der von dir gezeigten Weise auf jeden Fall besser passt.

Das soll jetzt aber keine Arbeitsbeschaffungsmaßnahme für Heiko sein  gruß Ralf

[DS_Starter]

Es gibt ja verschiedene Schreibvarianten:

    writeToDB    : schreibt jeweils einen Wert mit den Zeitstempeln XX:XX:01 und XX:XX:59 innerhalb der jeweiligen Auswertungsperiode
    writeToDBSingle    : schreibt nur einen Wert mit dem Zeitstempel XX:XX:59 am Ende einer Auswertungsperiode
    writeToDBInTime    : schreibt jeweils einen Wert am Anfang und am Ende der Zeitgrenzen einer Auswertungsperiode