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

[DS_Starter]

Das Problem von Franz konnte ich fixen. Ganz kleiner Fehler mit großer Wirkung.
Testet mal bitte -> contrib

[RalfRog]

Kann ich das auf mein Livesystem loslassen 
Auf dem Testsystem muss ich das ganze Logging noch einrichten...

hmm... ich zieh nen SQL Export

Gruß

[DS_Starter]

Nur Mut 

[RalfRog]

ok hat mir keine Ruhe gelassen....

timestamp_begin 2022-06-16 01:05:00
timestamp_end   2022-06-16 04:59:00
==> hatte funktioniert funktioniert noch

timestamp_begin 2022-06-16 01:05:00
timestamp_end   2022-06-16 23:59:00
==> hatte nicht funktioniert ==> liefert ein Ergebnis

Soweit zumindest eine positive Veränderung 

Jetzt kann ich ja mal die beiden Methoden im Rechenergebnis vergleichen, um zu sehen ob der einfache "average" besser mit der zeitgewichteten Methode ersetzt wird.


Gruß Ralf

[DS_Starter]

Jetzt sind schon viele Verbesserungen und Fixes ins Modul geflossen.
Ich warte mal noch bis morgen Abend, dann würde ich den Stand ins Repo bringen.

Gute Nacht @all,
Heiko

[RalfRog]

Macht Sinn, vielleicht gibts ja noch ne Meldung.

Ich glaube der gewichtete Mittelwert hat deutliche Vorteile, da die Null-Werte bzw. starke kurze Leistungsspitzen nicht so stark durchschlagen.

@Schluss für heute
Ralf

[alkazaa]

Ich warte mal noch bis morgen Abend, dann würde ich den Stand ins Repo bringen.

Moin Heiko,
vielleicht kannst Du noch warten:
Mir fiel bei der Beschäftigung mit dem gerichteten Mitteln nämlich auf, dass der jeweils letzte Datenpunkt am Ende eines Teilintervalls nicht berücksichtigt wird. Liegt, wenn ich den Perl-Code richtig verstanden hab, daran dass die Datenpakete pro Teilintervall separat mit SQL eingelesen und verarbeitet werden.
Ich hab bei der Methode mit reinem SQL die  Beiträge eines Teilintervall-übergreifenden Datenpunkts dagegen mitgenommen und anteilig gewichtet beiden Intervallen zugeordnet.

Vielleicht lässt sich die ,,nur-SQL" Methode ja in das Modul integrieren. Die Korrektheit der Berechnung habe ich jedenfalls mit ner Gegenrechnung in Excel überprüft.

Ich versuche mal im Laufe des Tages, das obige im Wiki etwas detaillierter zu erläutern.

Gruß
Franz

[DS_Starter]

Moin Franz,

ja gerne.

Das Problem ist, dass der Code sowohl für MySQL/MariaDB, SQLite und PostgreSQL funktionieren muss.
Es geht ja schon bei den Variablen los:

Code Auswählen Erweitern


SET @sortformat="hour",
  @weighted="yes",
  @device = "E_Zaehler",
  @reading = "power",
  @start = "2022-10-29 00:00:00",
  @end = "2022-10-29 05:00:00";


SQLite kann es so nicht. Habe diverse Varianten mit temporären Tabellen im Netz eruiert.
Meine MariaDB kann auch den Code aus dem Wiki nicht verarbeiten. Es kommt der Fehler:

Code Auswählen Erweitern


DBD::mysql::st execute failed: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '( ORDER BY tim) AS preavgtim, LEAD(avgtim) OVER ( ORDER BY tim) AS nextavgtim FR' at line 1 at ./FHEM/93_DbRep.pm line 11100.


Passt für meine MariaDB 10.1.48 noch nicht. Hatte auch noch keine Zeit den Grund genauer zu analysieren.
Da gibt es (wie schon öfter festgestellt) Unterschiede in den DB-Systemen und DB Versionen wenn es um komplexe SQL geht.
Es gibt mittlerweile auch ein DBD::MariaDB (https://metacpan.org/pod/DBD::MariaDB). Das hat den letzten Stand vom April 22, also recht aktuell. Werde ich mal bei Gelegenheit auch installieren, probieren und schauen ob ich es für DbLog/DbRep als DB-Typ integriere.

Kurzum, wenn wir für alle unterstützten DB's einen validen Code erarbeiten können, dann kann der gerne in die Funktion.
Ansonsten kann man nur über sqlCmd gehen mit Wiki Unterstützung.

LG

[alkazaa]

Klar, macht Sinn. Die Vielfalt der SQL-Dialekte hatte ich nicht auf dem Schirm
-Franz

[DS_Starter]

Ich habe noch einen kleinen Fehler korrigiert.
Weiterhin wird nun bei sqlCmd.../Blocking der formatierte SQL Code im Reading sqlCmd ausgegeben wenn das Statement fehlerhaft war.
Das erleichtert das Editieren und neu ausführen des Codes.
-> contrib

LG

[ch.eick]

Klar, macht Sinn. Die Vielfalt der SQL-Dialekte hatte ich nicht auf dem Schirm
-Franz

Ich verwende direkt das Oracle MySQL im Docker Container, das ist teilweise noch restriktiver, dafür aber immer aktueller.
Gerade bei den Variablen wird sich etwas ändern und auch für GROUP BY ist es schon jetzt anders gehandhabt.

VG  Christian

[RalfRog]

...
SQLite kann es so nicht. Habe diverse Varianten mit temporären Tabellen im Netz eruiert.
Meine MariaDB kann auch den Code aus dem Wiki nicht verarbeiten. Es kommt der Fehler:

Code Auswählen Erweitern


DBD::mysql::st execute failed: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '( ORDER BY tim) AS preavgtim, LEAD(avgtim) OVER ( ORDER BY tim) AS nextavgtim FR' at line 1 at ./FHEM/93_DbRep.pm line 11100.


Deswegen bin ich dankbar, wenn das Modul solche Sachen kann.
Bei den SQL-Statements (wie im Wiki) wäre ich völlig verloren (geht schon beim ausführen per CMD oder so im Modul los).

Gruß Ralf

[alkazaa]

Bei den SQL-Statements (wie im Wiki) wäre ich völlig verloren (geht schon beim ausführen per CMD oder so im Modul los).

Moin Ralf,
falls Du Dich auf das erste der Mittelungsqueries beziehst: einfach das gesamte Query ins Eingabefenster von sqlCmd (oder sqlCmdBlocking) kopieren und ausführen sollte gehen.
Inzwischen gibt es auch das Attribut sqlCmdVars, dorthin könnte (und sollte) man den Anfangsteil mit den SET @... auslagern und danach das Statement ab SELECT... im sqlCmd Fenster ausführen, also zuerst:

Code Auswählen Erweitern

attr <dein DbRep-device> sqlCmdVars SET @sortformat="hour", @weighted="yes", @device="E_Zaehler", @reading="power", @start = "2022-10-29 00:00:00", @end = "2022-10-29 05:00:00";
Dann das statement ab SELECT... als sqlCmd Befehl.

Falls das gesamte (von SET ... bis ... GROUP by grouptim) Statement über die FHEM Commandozeile laufen soll (also mit set <dein DbRep-device> sqlCmd SET... ... GROUP by avgtim), musst das Semikolon vor SELECT verdoppelt werden.

Das das ganze ja auch noch vom SQL-"Dialekt" abhängt (s.o.): bei mir läuft es auf einer MariaDB 10.3er Version

Aber Du willst ja auch die reduzierten Werte zurückschreiben in die DB, brauchst also sowieso die Gesamt-Funktionalität innerhalb des Moduls umgesetzt. Das in ein statement zu packen trau ich mich nicht (wenn's überhaupt geht)

Gruß
Franz

[RalfRog]

Danke für die Erläuterung.
Was wo reinkommt wäre im Wiki hilfreich (das war mir nicht so recht klar).

Für die zeitlich gewerteten Mittelwerte (per Modul) muss ich noch etwas Gehirnschmalz verwenden.
Die berechneten Werte werden mit neuem (angelehnten) Namen zusätzlich in die DB geschrieben.
So weit so schön - im zweiten (oder auch dritten) Schritt müssen dann noch die Originaleinträge rediziert werden sowie (je nach Parameter) noch einer der beiden berechneten Werte am Anfang/Ende des Intervalls reduziert und zusätzlich ggfs. auch noch die neuen Namen in den Readings angepasst werden.

Dann ist (wenn es reicht, dass die Werte ungefähr den Trend zeigen) eventuell ein einfaches "reduceLog average" einfacher (auch hinsichtlich der Wartbarkeit des Konstrukts).

Gruß Ralf

[alkazaa]

Habe die Erläuterungen im Wiki überarbeitet. Der Code wurde so umgeschrieben, dass jetzt die üblichen DbRep-Attribute für device, reading, Zeitraum genutzt werden (in der Form §device§ etc.)
-Franz