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

[DS_Starter]

Hallo kadettilac89,

danke für den Link, schaue ich mir mal an.

Meine Frage war eher allgemeiner Natur, weil es immer wieder Nutzer gibt die über doppelte Datensätze klagen.
Ich persönlich arbeite mit primary key seit ich die Unterstützung dafür in DbLog eingebaut habe, aber nicht jeder Nutzer tut das und ist ja auch nicht der "default" bei der Einrichtung von DbLog.

Außerdem muß ich mit DbLog/DbRep auch SQLite und Postgre SQL unterstützen.

Ansonten umständlicher Weg den Satz lokal zwischenspeichern, doppelte Sätze löschen und im Anschluss wieder einfügen.

Genau ein solches/ähnliches Verfahren würde ich in ein set-Kommando gießen als Pflegetool ... sofern eben Bedarf besteht.

LG,
Heiko

[DS_Starter]

Hallo Martin (knxler), @all,

Mit der Version 7.7.0 habe ich begonnen, die Voraussetzung für die Verwendung unterschiedlicher Mittelwertberechnungsmethoden zu implementieren.
Der set-Befehl "averageValue" bleibt unverändert und stellt durch SQL-AVG die einfache arithmetische Mittelwertberechnung dar.
Zusätzlich habe ich die Variante für die Berechnung des Tagesmittels entsprechend der Vorschriften des DWD eingebaut.

Für die averageValue-Funktion gibt es nun das Attribut "averageCalcForm" mit zur Zeit zwei Auswahlmöglichkeiten:

* avgArithmeticMean - Berechnung arithmetischer Mittelwert (default) -> ist gleichbedeutend wenn Attr nicht gesetzt (wie bisher)
* avgDailyMeanGWS - Berechnung des Tagesmittels von Temperaturen gemäß den Vorschriften des deutschen Wetterdienstes (https://www.dwd.de/DE/leistungen/klimadatendeutschland/beschreibung_tagesmonatswerte.html),  GWS = German Weather Service

Wird "avgDailyMeanGWS" benutzt, wird automatisch die aggregation=day verwendet. Entsprechend der Eingrenzung über timestamp_begin (z.B. previous_month_begin) kann man sich damit die Durchschnittstemperaturen der Tage entsprechend der DWD-Regeln für einen ganzen Monat usw. ermitteln. Mit der Verwendung von "set ... averageValue writeToDB" kann man die berechneten Werte wie gweohnt in die DB zurückschreiben  -> SVG-Anzeige.

Sollten die Messwerte eines Tages gemäß den DWD-Richtlinien ungenügend sein, wird im Ergebnis des Tages "insufficient values" ausgegeben.
Für die Berechnung mit "avgArithmeticMean" könnten jedoch genügend Werte vorliegen !

Die unterschiedlichen Ergebnisse beider Methoden sieht man recht gut in den angehängten Screenshots.
Wenn ich wieder Zeit habe, schaue ich mir die Average-Methode an auf die Joe hingewiesen hat und würde mich bis dahin über Feedback freuen.

Grüße
Heiko

[DS_Starter]

Guten Morgen,

manchmal macht man eine DB-Auswertung oder Anzeige die jede Menge Readings erzeugt.
Dann ist es lästig wenn man herunterscrollen muss um Attribute nachzuschauen, zu ändern etc. Außerdem wird die ganze Readingliste in fhem.save gespeichert.
Eine erzeugte Liste mit 7000 Reading verbraucht auch etwas Hauptspeicher.

Damit man sich ganz einfach der Daten entledigen kann, gibt es nun den set-Befehl "eraseReadings". Er löscht alle erzeugten Readings im Device außer "state" und Readings, die in der Ausnahmeliste (Attribut "readingPreventFromDel") enthalten sind.

Version 7.8.0 im ersten Beitrag.

schönes WE,
Heiko

[knxler]

Hallo Heiko,

danke für die schnelle Reaktion. Leider kann ich mit diesem Mittelwert nichts anfangen. Ich bin dabei meine Vissmann Heizung fein zu tunen. Dabei hilft mir nur der gemittelte wert über die Zeit. Da ich genau wissen möchte, wie war die Temperatur gestern.
Mir ist aber aufgefallen, das deine Bereichsangabe nicht so funktioniert wie ich es erwartet habe. Wenn du den Bereich von 2018-02-20 00:00:00 bis 2018-02-02 23:59:59 angibst und einen Datensatzexport machst, sollte dann nicht auch ein existierender Wert bei 23:59:59 mit in das File geschrieben werden? Bei mir wird dann der letzte Wert weggelassen.

Gruß Martin

[DS_Starter]

Hallo Martin,

Leider kann ich mit diesem Mittelwert nichts anfangen.

Die Mittelwertberechnung des DWD war nur der Anfang und diente gleich dazu die notwendige Struktur im Modul für unterschiedliche Average-Berechnungen zu schaffen.
Jetzt kommt die zeitgewichtete Funktion dran, die dir hoffentlich die benötigten Ergebnisse bringt... bin dabei.

Mir ist aber aufgefallen, das deine Bereichsangabe nicht so funktioniert wie ich es erwartet habe. Wenn du den Bereich von 2018-02-20 00:00:00 bis 2018-02-02 23:59:59 angibst und einen Datensatzexport machst, sollte dann nicht auch ein existierender Wert bei 23:59:59 mit in das File geschrieben werden? Bei mir wird dann der letzte Wert weggelassen.

Habe ich global mit Version 7.8.1 im ersten Beitrag korrigiert. 
Probiers mal bitte bei dir aus. Sollte nun wie erwartet reagieren.

Grüße
Heiko

[knxler]

Hallo Heiko,

leider fehlt noch immer der letzte Wert.

Gruß Martin

[DS_Starter]

Hi Martin,

mach mal bitte ein verbose 4 log und poste die SQL-Statements aus dem Log.
Du hast das Modul auch nach 93_DbRep umbenannt und FHEM restartet bzw. reload 93_DbRep gemacht ?

Grüße
Heiko

[knxler]

Hallo Heiko,

hier die Logs von DBRep

2018.02.06 07:54:20.493 4: DbRep DBReport - -------- New selection ---------
2018.02.06 07:54:20.493 4: DbRep DBReport - Command: exportToFile
2018.02.06 07:54:20.495 4: DbRep DBReport - Timestamp begin human readable: 2018-02-02 00:00:00
2018.02.06 07:54:20.496 4: DbRep DBReport - Timestamp end human readable: 2018-02-02 23:59:59
2018.02.06 07:54:20.497 4: DbRep DBReport - Aggregation: no
2018.02.06 07:54:20.532 4: DbRep DBReport -> Start BlockingCall expfile_DoParse
2018.02.06 07:54:20.551 4: DbRep DBReport - SQL execute: SELECT TIMESTAMP,DEVICE,TYPE,EVENT,READING,VALUE,UNIT FROM history where READING = 'Temp_Aussen_Tiefpass' AND TIMESTAMP >= '2018-02-02 00:00:00' AND TIMESTAMP <= '2018-02-02 23:59:59' ORDER BY TIMESTAMP;
2018.02.06 07:54:20.845 4: DbRep DBReport -> BlockingCall expfile_DoParse finished
2018.02.06 07:54:20.852 4: DbRep DBReport -> Start BlockingCall expfile_ParseDone
2018.02.06 07:54:20.881 3: DbRep DBReport - Number of exported datasets from fhem to file ./log/dbexport.log: / -- Temp_Aussen_Tiefpass -- 129.
2018.02.06 07:54:20.881 4: DbRep DBReport -> BlockingCall expfile_ParseDone finished

Gruß Martin

[knxler]

Hallo noch einmal,

zu deinen Fragen. Ja ich habe das Modul umbenannt und ich habe neu gestartet. Im DeviceOverview von DBReport wird die Version 7.8.1 angezeigt.

Gruß Martin

[DS_Starter]

Hallo Martin,

SQL execute: SELECT TIMESTAMP,DEVICE,TYPE,EVENT,READING,VALUE,UNIT FROM history where READING = 'Temp_Aussen_Tiefpass' AND TIMESTAMP >= '2018-02-02 00:00:00' AND TIMESTAMP <= '2018-02-02 23:59:59' ORDER BY TIMESTAMP;

Also die Selektion ist korrekt. Ich kann mir momentan nicht vorstellen wieso der Datensatz mit dem Timestamp 23:59:59 nicht exportiert werden sollte.
Kannst du bitte noch ein verbose 5 anfertigen.
Das kann ziemlich groß werden. Vllt. als File anhängen. Und wenn möglich auch das resultierende Exportfile.

Grüße
Heiko

[knxler]

Hallo Heiko,

hier der Output.
Ich habe den Zeitraum bei den Output_Daten bewusst erweitert, damit du siehst das es um 23:59:59 einen Datensatz gibt.
Kann es sein, dass der Select einen Datensatz um 23:59:59.000 erwartet?
Der Datensatz ist natürlich ein paar 1000stel später. Kannst du den Select entsprechend auf 23:59:59.999 erweitern?

Gruß Martin

[knxler]

Hallo

hier die Logeinträge mit Loglevel 5

Martin

[DS_Starter]

Also wenn ich nichts übersehen habe, werden doch alle datensätze in die output_daten exportiert oder interpretiere ich das file falsch ?
Komischerweise zeigt tatsächlich das log dass der letzte satz nicht geschrieben werden würde wobei er ja in output_daten drin steht.
Wo siehst du dass der letzte timestamp  23:59:59.xxx ist ? deine Db scheint doch ebenfalls wie es der standard im logging ist ohne millisekunden zu arbeiten.

bekomme es momentan noch nicht zusammen. vllt. kannst nochmal erläutern was ich falsch sehe oder falsch interpretiere.

lg,
Heiko

[knxler]

Hallo Heiko,

ich habe für die Output_Daten den timestamp_end auf 2018-02-03 00:20:59 gesetzt, damit du siehst das es dort auch einen Datensatz gibt. Der wird aber wenn ich timestamp_end auf 2018-02-02 23:59:59 setze nicht mit ausgegeben.

Gruß Martin

[DS_Starter]

Hallo Martin,

konnte es jetzt bei mir nachstellen und bin momentan etwas ratlos.
Es betrifft genau den Satz um 23:59:59. Aber nur bei exportToFile. Mit der gleichen Selektion, was intern auch das gleiche Selectstatement ist, bringt fetchrows den Datensatz mit raus.
Kannst du bei dir auch mal probieren.

Das ist schon ziemlich kurios.

Grüße
Heiko