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

[DS_Starter]

Danke 
Habe die V eingecheckt. Morgen früh im Update.

[300P]

@300P,

ich habe dir eine Version zum Test in mein contrib geladen.
Die V sollte sowohl die Vorteile des letzten Change von diffValue bewahren als auch dein Problem beheben.
Teste sie mal bitte. Auch mit writeToDB.

LG

Nachsatz:
Es klappt auch ohne die Option "writeToDB"

Nachsatz II:
M.E. kann man ab jetzt am Reading erkennen ob Datensätze vorhanden sind oder nicht

Datensätze sind GARNICHT vorhanden.
(Datum wird am Readingnamenende eingefügt und ein "-" wird als Ergebnis gezeigt)

2023-04-11__FCU__FCU_Erzeugung_akt_Zaehlerstand__DIFF__2023-04-11       -      2023-04-11 09:10:22
oder
2017-06-13__SB40__etotal__DIFF__2017-06-13       -           2023-04-11 00:15:02

Datensätze sind genügend VORHANDEN
(alles okay)

2018-09-03_23-59-59__FCU__FCU_Erzeugung_akt_Zaehlerstand__DIFF__no_aggregation   4915.0000       2023-04-11 00:15:02



Gruß
300P

[Christian83]

Hallo,

bei mir ist nun das Problem, dass bei nur einem vorhandenem Wert (Zählerstand hat sich im Zeitraum nicht verändert) die Warnung "less_data..." im State steht. Da ich auf State "done" prüfe geht nichts mehr weiter.
Das war bisher nicht so. Da gab es die Fehlermeldung nicht und das Ergebnis war einfach 0.

[300P]

Hallo Christian83,

um welche Zeiträume ohne Werte geht es denn ?

Eventuell hilft dir da schon der Einsatz / Nutzung des Attributes "event-min-interval" im zugehörigen Zähler-Device
->>>  z.B. "attr <Devicename> event-min-interval <Zählerstandname>:300" für spätestens 5 Minuten nach dem letzten Wert den aktuellen Wert wieder schreiben.

Aber der Zeitraum muss je nach deiner Auswertungshäufigkeit gewählt werden. Ansonsten kann es ja bis unendlich dauern ehe von dort ein neuer Wert kommt.

Gruß
GW

[DS_Starter]

Hallo,

bei mir ist nun das Problem, dass bei nur einem vorhandenem Wert (Zählerstand hat sich im Zeitraum nicht verändert) die Warnung "less_data..." im State steht. Da ich auf State "done" prüfe geht nichts mehr weiter.

Das ist ein einigen Fällen bei mir nun auch so. Ich habe dafür die state-Prüfung erweitert, dann klappt es wieder wie es soll:

Code Auswählen Erweitern

if ($READING eq 'state' && $VALUE =~ /done|WARNING/xs) {
}

[Christian83]

Hallo Christian83,

um welche Zeiträume ohne Werte geht es denn ?

Eventuell hilft dir da schon der Einsatz / Nutzung des Attributes "event-min-interval" im zugehörigen Zähler-Device
->>>  z.B. "attr <Devicename> event-min-interval <Zählerstandname>:300" für spätestens 5 Minuten nach dem letzten Wert den aktuellen Wert wieder schreiben.

Aber der Zeitraum muss je nach deiner Auswertungshäufigkeit gewählt werden. Ansonsten kann es ja bis unendlich dauern ehe von dort ein neuer Wert kommt.

Gruß
GW

Es geht um den Stromzählerstand der eingespeisten Menge. Die ist ja bis zum nächsten Einspeisen, was irgendwann am Nachmittag sein kann 0 bzw. keine Änderung. Da jetzt aller 5 Minuten einen Wert in die DB zu schreiben ist für die Datenmenge nicht förderlich.
Zumal es ja vorher ging.

[Christian83]

Hallo,

Das ist ein einigen Fällen bei mir nun auch so. Ich habe dafür die state-Prüfung erweitert, dann klappt es wieder wie es soll:

Code Auswählen Erweitern

if ($READING eq 'state' && $VALUE =~ /done|WARNING/xs) {
}

Super danke. Jetzt geht es wieder.

[dk3572]

Hallo Heiko,

ich erhalte morgens von Rep.STP5000.Erzeugung.heute folgende Warnung:

Code Auswählen Erweitern

WARNING - see readings 'less_data_in_period' or 'diff_overrun_limit_XX'

2023-04-24 06:13:18   2023-04-24_00-00-04__SMA_Wechselrichter__etoday__DIFF__no_aggregation 0.0000      2023-04-24 06:13:18   background_processing_time 0.0084      2023-04-24 06:13:18   less_data_in_period no_aggregation ||      2023-04-24 06:13:18   sql_processing_time 0.0018      2023-04-24 06:13:18   state           WARNING - see readings 'less_data_in_period' or 'diff_overrun_limit_XX'

Hast du eine Idee wie ich die los werde?

Danke und VG
Dieter

[DS_Starter]

Morgen Dieter,

entweder die Auswertung in einen Zeitraum verschieben in dem genügend Daten zu erwarten sind oder die Warnung im state ignorieren.
Ist ja nur eine Warnung bzw. Information über den festgestellten Sachverhalt dass keine Daten zur Auswertung.

Auszug aus der Commandref:

Im Auswertungs- bzw. Aggregationszeitraum (Tag, Woche, Monat, etc.) sollten dem Modul pro Periode mindestens ein
       Datensatz zu Beginn und ein Datensatz gegen Ende des Aggregationszeitraumes zur Verfügung stehen um eine möglichst
       genaue Auswertung der Differenzwerte vornehmen zu können. <br>
       
       Wird in einer auszuwertenden Zeit- bzw. Aggregationsperiode nur ein Datensatz gefunden, kann die Differenz in
       Verbindung mit dem Differenzübertrag der Vorperiode berechnet werden. in diesem Fall kann es zu einer logischen
       Ungenauigkeit in der Zuordnung der Differenz zu der Aggregationsperiode kommen. In diesem Fall wird eine Warnung
       im state ausgegeben und das Reading <b>less_data_in_period</b> mit einer Liste der betroffenen Perioden erzeugt.

LG,
Heiko

[Christian83]

Morgen Dieter,

entweder die Auswertung in einen Zeitraum verschieben in dem genügend Daten zu erwarten sind oder die Warnung im state ignorieren.
Ist ja nur eine Warnung bzw. Information über den festgestellten Sachverhalt dass keine Daten zur Auswertung.

Auszug aus der Commandref:

Im Auswertungs- bzw. Aggregationszeitraum (Tag, Woche, Monat, etc.) sollten dem Modul pro Periode mindestens ein
       Datensatz zu Beginn und ein Datensatz gegen Ende des Aggregationszeitraumes zur Verfügung stehen um eine möglichst
       genaue Auswertung der Differenzwerte vornehmen zu können. <br>
       
       Wird in einer auszuwertenden Zeit- bzw. Aggregationsperiode nur ein Datensatz gefunden, kann die Differenz in
       Verbindung mit dem Differenzübertrag der Vorperiode berechnet werden. in diesem Fall kann es zu einer logischen
       Ungenauigkeit in der Zuordnung der Differenz zu der Aggregationsperiode kommen. In diesem Fall wird eine Warnung
       im state ausgegeben und das Reading <b>less_data_in_period</b> mit einer Liste der betroffenen Perioden erzeugt.

LG,
Heiko

Hallo,

ist das neu? Das war bis vor einiger Zeit nämlich kein Problem bzw. gab es da kein WARNING im state.

[DS_Starter]

Nein, das ist nicht neu. Aber es ist durchaus möglich, dass im Zuge von Bugfixing ein Fehler beseitigt wurde der die Anzeige dieser Warnung bisher verhindert hat obwohl die Warnung hätte angezeigt werden müssen.
Ich hoffe das war jetzt nicht verwirrend 

[ch.eick]

Hallo zusammen,

ich suche noch immer eine Möglichkeit das DbRep mit sqlCmd zyklisch auszuführen.
Das Problem ist z.B. dass meine SQL Aufrufe sehr lang sind und dies aus einem DOIF ziemlich unübersichtlich ist.
Weiterhin habe ich ein SQL Kommando, das über das Device mit "set <Device> sqlCmd aus dem FHEMWeb problemlos startet, jedoch über den aufruf einen SQL Error bringt.

Im DOIF FHEM Modus wird folgendes Aufgerufen, was im DbRep genau so läuft und auch in der FHEMWEB Kommandozeile.

Code Auswählen Erweitern

(set LogDBRep_Statistic_previous_Month sqlCmd SELECT * FROM (SELECT h.TIMESTAMP, CONCAT('WB_0_', h.READING) AS READING, h.VALUE FROM history h JOIN (SELECT max(TIMESTAMP) AS TIMESTAMP, READING FROM history WHERE DEVICE = 'WB_0' AND READING = 'Kia_eNiro_kWhCounter_Month' AND TIMESTAMP > DATE_FORMAT(NOW() - INTERVAL 1 MONTH, '%Y-%m-01 00:00:00') AND TIMESTAMP < DATE_FORMAT(LAST_DAY(NOW() - INTERVAL 1 MONTH), '%Y-%m-%d 23:59:59') GROUP BY READING) x1 USING(TIMESTAMP,READING)) x UNION ALL SELECT h.TIMESTAMP, CONCAT('WB_0_', h.READING) AS READING, h.VALUE FROM history AS h JOIN (SELECT max(TIMESTAMP) AS TIMESTAMP, READING FROM history WHERE DEVICE = 'WB_0' AND READING = 'Gast_kWhCounter_Month' AND TIMESTAMP > DATE_FORMAT(NOW() - INTERVAL 1 MONTH, '%Y-%m-01 00:00:00') AND TIMESTAMP < DATE_FORMAT(LAST_DAY(NOW() - INTERVAL 1 MONTH), '%Y-%m-%d 23:59:59') GROUP BY READING) x2 USING(TIMESTAMP,READING) UNION ALL SELECT h.TIMESTAMP, CONCAT('WB_1_', h.READING) AS READING, h.VALUE FROM history h JOIN (SELECT max(TIMESTAMP) AS TIMESTAMP, READING FROM history WHERE DEVICE = 'WB_1' AND READING LIKE 'lp_%_kWhCounter_Month' AND TIMESTAMP > DATE_FORMAT(NOW() - INTERVAL 1 MONTH, '%Y-%m-01 00:00:00') AND TIMESTAMP < DATE_FORMAT(LAST_DAY(NOW() - INTERVAL 1 MONTH), '%Y-%m-%d 23:59:59') GROUP BY READING) x3 USING(TIMESTAMP,READING) UNION ALL SELECT max(TIMESTAMP) AS TIMESTAMP, 'EVU_Tibber_Pulse_nodes_consumption_Month' AS READING, cast(sum(VALUE) AS DECIMAL(10,0)) AS VALUE FROM history WHERE DEVICE='EVU_Tibber_Pulse' AND READING='nodes_consumption' AND TIMESTAMP > DATE_FORMAT(NOW() - INTERVAL 1 MONTH, '%Y-%m-01 00:00:00') AND TIMESTAMP < DATE_FORMAT(LAST_DAY(NOW() - INTERVAL 1 MONTH), '%Y-%m-%d 23:59:59') ;)

Als Meldung kommt dann

Code Auswählen Erweitern

SQL_Format Normal! 2023-04-28 12:06:00
errortext DBD::mysql::st execute failed: Unknown table 'h' in field list at ./FHEM/93_DbRep.pm line 11623. 2023-04-28 12:05:49

sqlCmd
SELECT * FROM (SELECT h.TIMESTAMP, CONCAT('WB_0_', h.READING) AS READING, h.VALUE FROM history h JOIN (SELECT max(TIMESTAMP) AS TIMESTAMP, READING FROM history WHERE DEVICE = 'WB_0' AND READING = 'Kia_eNiro_kWhCounter_Month' AND TIMESTAMP > DATE_FORMAT(NOW() - INTERVAL 1 MONTH, '%Y-%m-01 00:00:00') AND TIMESTAMP < DATE_FORMAT(LAST_DAY(NOW() - INTERVAL 1 MONTH), '%Y-%m-%d 23:59:59') GROUP BY READING) x1 USING(TIMESTAMP,READING)) x UNION ALL SELECT h.TIMESTAMP;
2023-04-28 12:05:49

state error 2023-04-28 12:05:49

VG  Christian

[DS_Starter]

Hallo Christian,

die Frage bzgl. dem DOIF kann ich  dir nicht beantworten, setze DOIF nicht ein.

Aber du könntest dir dein langes Statement in der sqlcmd History speichern (Attr sqlCmdHistoryLength).
Wenn es dort gespeichert wurde, kannst du es immer wieder mit einem Index-Key neu ausführen lassen,
z.B.

   set ... sqlCmd ckey:1

Das ist in der Hilfe zu sqlCmd beschrieben.
Vllt. hilft dir das ?

Edit: mit verbose 4 müsstest du das SQL-Kommando im Log sehen welches vom DOIF übergeben wird kurz bevor der Error im Log steht.

[ch.eick]

Aber du könntest dir dein langes Statement in der sqlcmd History speichern (Attr sqlCmdHistoryLength).
Wenn es dort gespeichert wurde, kannst du es immer wieder mit einem Index-Key neu ausführen lassen,
z.B.
   set ... sqlCmd ckey:1

Das ist in der Hilfe zu sqlCmd beschrieben.
Vllt. hilft dir das ?

Okay, genau das hatte ich gesucht.

EDIT:
Die sqlCmdHistory wurde bei mir nur gesetzt, wenn man es mit "set <Device> sqlCmd SELECT...." auf der FHEM Kommandozeile aufgerufen hat.
Die Zählung hat jedoch nicht bei ckey:1 begonnen, sondern bei einem Device bei 2 und bei einem anderen bei 5.
Nach einem ___purge_sqlhistory___ und erneutem set ging es dann bei 1 los.
Mit dem set <Device> sqlCmd aus dem Device heraus wurde nichts in der sqlCmdHistory gespeichert.

Edit: mit verbose 4 müsstest du das SQL-Kommando im Log sehen welches vom DOIF übergeben wird kurz bevor der Error im Log steht.

Das schau ich mir dann auch noch an.

[DS_Starter]

Die Zählung hat jedoch nicht bei ckey:1 begonnen, sondern bei einem Device bei 2 und bei einem anderen bei 5.
Nach einem ___purge_sqlhistory___ und erneutem set ging es dann bei 1 los.

Das ist normal.

Mit dem set <Device> sqlCmd aus dem Device heraus wurde nichts in der sqlCmdHistory gespeichert.

Kann ich nicht glauben. 
Funktioniert bei mir tadellos.