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

[DS_Starter]

@Parallix,

ich habe die Version 8.53.17 eingecheckt, ist morgen früh im Update. Die Auflösung der symbolischen Links sollte nun funktionieren.

Grüße,
Heiko

[PeterLustig]

Hallo Heiko,

um meine Datenbank im Rahmen zu halten, nutze ich einige DbRep mit delEntries.
Dabei ist mir vor einiger Zeit aufgefallen, dass zwei Devices nicht vom Status "running" zu "done" wechseln.

Beide Devices besitzen ein reading-Attribut, welche längere Listen von Readings beinhalten. Die Listen sind mit Zeilenumbrüchen auf mehrere Zeilen im FHEMweb aufgeteilt

Die Datensätze werden in der Datenbank gelöscht, aber die DbRep-Devices bleiben bei "running" und beim nächsten Durchlauf erscheint im Log (mit Verbose 5) z.B.:
DbRep NASDbRepShortTime - WARNING - running process DEAD:988612 will be killed now to start a new operation

Die Zeilenumbrüche aus dem FHEMweb sind im SQL-Command in der Logausgabe an gleicher Stelle erkennbar und es fehlen (im Vergleich zu einem fehlerfreien DbRep-Device) die letzten beiden Zeilen bei der Log-Ausgabe:

Code Auswählen Erweitern

2025.06.03 03:10:00.003 3: DbRep NASDbRepShortTime_Wechselrichter - WARNING - running process DEAD:3094649 will be killed now to start a new operation
2025.06.03 03:10:00.003 4: DbRep NASDbRepShortTime_Wechselrichter - -------- New selection ---------
2025.06.03 03:10:00.003 4: DbRep NASDbRepShortTime_Wechselrichter - Command: delEntries
2025.06.03 03:10:00.003 4: DbRep NASDbRepShortTime_Wechselrichter - timeOlderThan - year: , day: 30, hour: , min: , sec:
2025.06.03 03:10:00.004 4: DbRep NASDbRepShortTime_Wechselrichter - startMonth: 2 endMonth: 4 lastleapyear:  baseYear: 2025 diffdaylight:1 isdaylight:1
2025.06.03 03:10:00.004 4: DbRep NASDbRepShortTime_Wechselrichter - FullDay option: 0
2025.06.03 03:10:00.004 5: DbRep NASDbRepShortTime_Wechselrichter - Timestamp begin epocheseconds: 1742342412
2025.06.03 03:10:00.004 4: DbRep NASDbRepShortTime_Wechselrichter - Timestamp begin human readable: 2025-03-19 01:00:12
2025.06.03 03:10:00.004 4: DbRep NASDbRepShortTime_Wechselrichter - Time difference to current time for calculating Timestamp end: 2592001 sec
2025.06.03 03:10:00.004 5: DbRep NASDbRepShortTime_Wechselrichter - Timestamp end epocheseconds: 1746320999.00426
2025.06.03 03:10:00.004 4: DbRep NASDbRepShortTime_Wechselrichter - Timestamp end human readable: 2025-05-04 03:09:59
2025.06.03 03:10:00.019 5: DbRep NASDbRepShortTime_Wechselrichter - BlockingCall with PID "3182397" started
2025.06.03 03:10:00.072 4: DbRep NASDbRepShortTime_Wechselrichter - Database Model: MARIADB
2025.06.03 03:10:00.072 4: DbRep NASDbRepShortTime_Wechselrichter - Database connect - user: fhemuser, UTF-8 option set: no
2025.06.03 03:10:00.074 5: DbRep NASDbRepShortTime_Wechselrichter - IsTimeSet: 1, IsAggrSet: 0
2025.06.03 03:10:00.075 5: DbRep NASDbRepShortTime_Wechselrichter - Devices for operation -
included (1): Wechselrichter
included with wildcard: 
excluded (0): 
excluded with wildcard:
2025.06.03 03:10:00.075 5: DbRep NASDbRepShortTime_Wechselrichter - Readings for operation -
included (12): 'usr_VerbrauchSumme','usr_VerbrauchPV','usr_insHaus','PM_Leistung_Momentan_W','usr_VerbrauchNetz','
usr_ausNetz','WR_String_Effizienz','usr_insNetz','WR_String2_Effizienz','WR_String1_Effizienz','
WR_Energie_Gesamt_kWh','WR_Leistung_EingangSolar_Gesamt_kWh'
included with wildcard: 
excluded (0): 
excluded with wildcard:
2025.06.03 03:10:00.075 4: DbRep NASDbRepShortTime_Wechselrichter - SQL execute: delete FROM history where ( DEVICE = 'Wechselrichter' ) AND ( READING IN ('usr_VerbrauchSumme','usr_VerbrauchPV','usr_insHaus','PM_Leistung_Momentan_W','usr_VerbrauchNetz','
usr_ausNetz','WR_String_Effizienz','usr_insNetz','WR_String2_Effizienz','WR_String1_Effizienz','
WR_Energie_Gesamt_kWh','WR_Leistung_EingangSolar_Gesamt_kWh') ) AND TIMESTAMP >= '2025-03-19 01:00:12' AND TIMESTAMP <= '2025-05-04 03:09:59' ;
2025.06.03 03:10:00.527 5: DbRep NASDbRepShortTime_Wechselrichter - Number of deleted rows: 36255

Entferne ich die Zeilenumbrüche im reading-Attribut, tauchen die beschriebenen Probleme nicht auf und es läuft einwandfrei.

Was ich eigentlich versuche zu erklären: Ich glaube, das Parsen des reading-Attributs macht Probleme.....

Code Auswählen Erweitern

list NASDbRepShortTime_Wechselrichter

Internals:
   DATABASE   fhem
   DEF        NASDbLog
   FUUID      66cc838e-f33f-1632-c9eb-662b59f9627187ff
   FVERSION   93_DbRep.pm:v1.1.1-s29390/2024-12-01
   LASTCMD    delEntries
   MODEL      Client
   NAME       NASDbRepShortTime_Wechselrichter
   NOTIFYDEV  global,NASDbRepShortTime_Wechselrichter
   NR         783
   NTFY_ORDER 50-NASDbRepShortTime_Wechselrichter
   ROLE       Client
   STATE      running
   TYPE       DbRep
   eventCount 14
   HELPER:
     DBLOGDEVICE NASDbLog
     GRANTS     ALL PRIVILEGES,USAGE
     IDRETRIES  2
     MINTS      2025-03-19 01:00:12
     PACKAGE    main
     VERSION    8.53.16
     CV:
       aggregation no
       aggsec     1
       destr      2025-05-06
       dsstr      2025-03-19
       epoch_seconds_end 1746538901.17879
       mestr      05
       msstr      03
       testr      15:41:41
       tsstr      01:00:12
       wdadd     
       yestr      2025
       ysstr      2025
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      512
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
     RUNNING_PID:
       abortFn    DbRep_ParseAborted
       bc_pid     134933
       finishFn   DbRep_del_Done
       fn         DbRep_del
       loglevel   5
       pid        DEAD:3875621
       telnet     telnetForBlockingFn_1747305852.16629_127.0.0.1_57992
       terminated 1
       timeout    86400
       abortArg:
       arg:
         device     Wechselrichter
         name       NASDbRepShortTime_Wechselrichter
         opt        delEntries
         prop       
         reading    usr_VerbrauchSumme,usr_VerbrauchPV,usr_insHaus,PM_Leistung_Momentan_W,usr_VerbrauchNetz,
usr_ausNetz,WR_String_Effizienz,usr_insNetz,WR_String2_Effizienz,WR_String1_Effizienz,
WR_Energie_Gesamt_kWh,WR_Leistung_EingangSolar_Gesamt_kWh
         rsf        2025-03-19 01:00:12
         rsn        2025-05-06 15:41:41
         table      history
         ts         no_aggregation#2025-03-19 01:00:12#2025-05-06 15:41:41|
         hash:
   Helper:
     DBLOG:
       BlockingInfo:
         NASDbLog:
           TIME       1748244248.69579
           VALUE      <html><table border=2 bordercolor='darkgreen' cellspacing=0><tr><td style='padding-right:5px;padding-left:5px;font-weight:bold'>PID</td><td style='padding-right:5px;padding-left:5px;font-weight:bold'>FUNCTION</td><td style='padding-right:5px;padding-left:5px;font-weight:bold'>ARGUMENTS</td><td style='padding-right:5px;padding-left:5px;font-weight:bold'>TIMEOUT</td><td style='padding-right:5px;padding-left:5px;font-weight:bold'>CONNECTEDVIA</td></tr><tr><td style='padding-right:5px;padding-left:5px'>1084198</td><td style='padding-right:5px;padding-left:5px'>PRESENCE2_doDaemonUnBlocking</td><td style='padding-right:5px;padding-left:5px'>PsnceDaemon#pres2_AppleTV,pres2_BambuLab,pres2_CCU,pres2_CCU_Host,pres2_Chomecast,pres2_Delock1,pre...</td><td style='padding-right:5px;padding-left:5px'>60</td><td style='padding-right:5px;padding-left:5px'>telnetForBlockingFn_1747305852.16629_127.0.0.1_40068</td></tr></table></html>
       Blocking_Count:
         NASDbLog:
           TIME       1748244248.69579
           VALUE      1
       background_processing_time:
         NASDbLog:
           TIME       1747703410.77686
           VALUE      10.7152
       connectionEncoding:
         NASDbLog:
           TIME       1747703410.77686
           VALUE      utf8mb4
       dbEncoding:
         NASDbLog:
           TIME       1747703410.77686
           VALUE      utf8mb4
       dbModel:
         NASDbLog:
           TIME       1747703410.77686
           VALUE      MARIADB
       errortext:
         NASDbLog:
           TIME       1748011031.22665
           VALUE      Can't use admin credentials for database access, see logfile !
       indexState:
         NASDbLog:
           TIME       1747703410.77686
           VALUE      Index Report_Idx doesn't exist. Please create the index by "set NASDbRepShortTime_Wechselrichter index recreate_Report_Idx" command !
       sql_processing_time:
         NASDbLog:
           TIME       1747703410.77686
           VALUE      10.7133
       state:
         NASDbLog:
           TIME       1748308200.00384
           VALUE      running
       timestamp_oldest_dataset:
         NASDbLog:
           TIME       1747703410.77686
           VALUE      2025-03-19 01:00:12
       userRights:
         NASDbLog:
           TIME       1747703410.77686
           VALUE      ALL PRIVILEGES,USAGE
   OLDREADINGS:
   READINGS:
     2025-06-05 15:41:42   state           running
   hmccu:
Attributes:
   DbLogExclude .*
   devStateIcon done:10px-kreis-gruen .*disconnect:10px-kreis-rot .*connected:10px-kreis-gruen
   device     Wechselrichter
   event-on-change-reading .*
   reading    usr_VerbrauchSumme,usr_VerbrauchPV,usr_insHaus,PM_Leistung_Momentan_W,usr_VerbrauchNetz,
usr_ausNetz,WR_String_Effizienz,usr_insNetz,WR_String2_Effizienz,WR_String1_Effizienz,
WR_Energie_Gesamt_kWh,WR_Leistung_EingangSolar_Gesamt_kWh
   room       DBLog
   showproctime 1
   timeOlderThan d:30
   verbose    5


[DS_Starter]

Hallo Peter,

ist mir bei meinen Reps noch nicht aufgefallen, aber schaue ich mir nach meinem Urlaub gerne mal an.
Ich hätte einen SQL Fehler erwartet wenn der Parse nicht richtig funktionieren würde ... aber wir werden sehen. 

LG,
Heiko

[dennisk]

Hallo @DS_Starter,

mit Perl 5.42 gibt es neue Warnings, die u.a. beim DbRep-Modul an einer Stelle auftreten:

Code Auswählen Erweitern

PERL WARNING: Possible precedence problem between ! and string eq at /usr/share/fhem/FHEM/93_DbRep.pm line 14592, <$fh> line 2345.Das ist bei mir die folgende Zeile (FHEM ist auf aktuellem Stand, sprich das DbRep-Modul entspricht dem Stand im SVN):

Code Auswählen Erweitern

if(!$defs{$name}{TYPE} eq "DbRep") {Laut https://perldoc.perl.org/perldelta#New-Warnings liegt es an der Negation im if. Wenn ich es richtig verstehe, dann müsste nur die folgende kleine Änderung ausreichen, wobei die Bedeutung des Codes nach meinem Verständnis dieselbe bleibt:

Code Auswählen Erweitern

if(!($defs{$name}{TYPE} eq "DbRep")) { oder alternativ

Code Auswählen Erweitern

if($defs{$name}{TYPE} ne "DbRep") {Passt das aus Deiner Sicht auch? Könntest Du die Änderung entsprechend ins SVN übernehmen?

Danke und Grüße

[DS_Starter]

Danke für den Hinweis. Nehme mir DbRep am WE mal vor.

Grüße,
Heiko

[betateilchen]

kleine Änderung ausreichen, wobei die Bedeutung des Codes nach meinem Verständnis dieselbe bleibt:

Code Auswählen Erweitern

if(!($defs{$name}{TYPE} eq "DbRep")) { oder alternativ

Code Auswählen Erweitern

if($defs{$name}{TYPE} ne "DbRep") {

oder als dritte Alternative

Code Auswählen Erweitern

if (not $defs{$name}{TYPE} eq "DbRep")
Müsste ich wählen, nähme ich die Variante mit "ne", das ist am einfachsten zu lesen und zu verstehen.

[DS_Starter]

Hallo zusammen,

ich habe die zwei offenen Dinge erledigt.

1.

Code Auswählen Erweitern

if(!($defs{$name}{TYPE} eq "DbRep")) {

... habe ich in "if($defs{$name}{TYPE} ne "DbRep") {" abgeändert. Ich weiß heute auch nicht mehr wieso ich das damals so völlig untypisch gecodet hatte. Verwendete ich sonst nie in der Art ... seltsam manchmal.

2. @PeterLustig

Was ich eigentlich versuche zu erklären: Ich glaube, das Parsen des reading-Attributs macht Probleme.....

Die Attribute device/reading waren von mir bisher nicht als mehrzeilig definierbar vorgesehen.
Jetzt ist es per default möglich (textField-long).

Version 8.54.19 ist eingecheckt und auch bereits aus meinem contrib ladbar.

Grüße,
Heiko

[PeterLustig]

Die Attribute device/reading waren von mir bisher nicht als mehrzeilig definierbar vorgesehen.
Jetzt ist es per default möglich (textField-long).

Version 8.54.19 ist eingecheckt und auch bereits aus meinem contrib ladbar.

Grüße,
Heiko

Eben getestet und funktioniert.

Super, vielen lieben Dank fürs Fixen!

[dennisk]

1.

Code Auswählen Erweitern

if(!($defs{$name}{TYPE} eq "DbRep")) {

... habe ich in "if($defs{$name}{TYPE} ne "DbRep") {" abgeändert. Ich weiß heute auch nicht mehr wieso ich das damals so völlig untypisch gecodet hatte. Verwendete ich sonst nie in der Art ... seltsam manchmal.

Vielen Dank für die Umsetzung!

[300P]

Hallo Heiko,

nach dem Jahreswechsel habe ich bei einem Report einen mir unerklärlichen "Zählfehler"

Hier ein List des device:

Code Auswählen Erweitern

Internals:
   DATABASE   fhem
   DEF        myDbLog
   FUUID      68dadafc-f33f-11b3-7c89-597145420ca7a720
   FVERSION   93_DbRep.pm:v8.54.19-s30153/2025-07-27
   LASTCMD    diffValue display
   MODEL      Client
   NAME       Rep.MQTT2_WP_Waermemenge.Erzeugung.Vorjahr
   NOTIFYDEV  global,Rep.MQTT2_WP_Waermemenge.Erzeugung.Vorjahr
   NR         1974
   NTFY_ORDER 50-Rep.MQTT2_WP_Waermemenge.Erzeugung.Vorjahr
   ROLE       Client
   STATE      done
   TYPE       DbRep
   UTF8       1
   eventCount 12
   HELPER:
     DBLOGDEVICE myDbLog
     GRANTS     INSERT,SELECT,ALL PRIVILEGES,UPDATE,DELETE
     IDRETRIES  2
     MINTS      1996-03-08 17:23:29
     PACKAGE    main
     VERSION    8.54.19
     CV:
       aggregation no
       aggsec     1
       destr      2025-12-31
       dsstr      2025-01-01
       epoch_seconds_end 1767221999
       mestr      12
       msstr      01
       testr      23:59:59
       tsstr      00:00:00
       wdadd     
       yestr      2025
       ysstr      2025
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      512
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
   Helper:
     DBLOG:
       state:
         myDbLog:
           TIME       1768331811.03616
           VALUE      done
   OLDREADINGS:
   READINGS:
     2026-01-13 20:16:50   2025-12-31_23-59-20__MQTT_EMSwp__boiler_data_nrgtotal__DIFF__no_aggregation 12970.7300
     2026-01-13 20:16:50   background_processing_time 6.4102
     2026-01-13 20:16:50   sql_processing_time 3.7993
     2026-01-13 20:16:50   state           done
Attributes:
   aggregation no
   devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
   device     MQTT_EMSwp
   diffAccept 20000
   disable    0
   event-on-update-reading state
   group      Energy Meter Auswertung
   reading    boiler_data_nrgtotal
   room       Energie
   showproctime 1
   timeout    180
   timestamp_begin previous_year_begin
   timestamp_end previous_year_end
   userExitFn setDumEnergy .*:.*
   verbose    2

Leider stimmt das Ergebnis von 12970.7300 nicht so ganz.
(Den Wert bzw. Zählerstand gibt es im Jahr 2025 leider noch garnicht)

Der erste Wert in der Datenbank am 2025-04-10 beträgt

Code Auswählen Erweitern

2025-04-10 12:00:00    MQTT_EMSwp    MQTT2_DEVICE    boiler_data_nrgtotal: 5.25    boiler_data_nrgtotal    0    NULL

Der letzte Wert für 2025 in der Datenbank beträgt

Code Auswählen Erweitern

2025-12-31 23:59:20    MQTT_EMSwp    MQTT2_DEVICE    boiler_data_nrgtotal: 12761.37    boiler_data_nrgtotal    12761.37    NULL


Hier meine zugehörige extra zum Vergleich direkt in der SQL-Datenbak durchgeführte SQL-Abfrage:

Code Auswählen Erweitern

SELECT
    *
FROM
    `fhem`.`history`
WHERE
    (`DEVICE` = 'MQTT_EMSwp')
    AND (`TIMESTAMP` < '2026-01-01 00:00:00')
    AND (`READING` = 'boiler_data_nrgtotal')
ORDER BY
    CAST(VALUE AS DECIMAL(10, 2)) DESC;



Hier auch die Ergebnisse die dbrep in FHEM findet:

Abfrage "minValue" :

Code Auswählen Erweitern

2025-04-10_12-00-00__MQTT_EMSwp__boiler_data_nrgtotal__MIN__no_aggregation       0.0000   2026-01-13 22:04:27

Abfrage "maxValue" :

Code Auswählen Erweitern

2025-12-31_23-59-20__MQTT_EMSwp__boiler_data_nrgtotal__MAX__no_aggregation   12761.3700    2026-01-13 22:05:12


Wo liegt der Fehler der Differenz begraben zwischen dem

Reportergebnis 12970.7300

maxWert von 12761.3700 in der Datenbank ?


Anlage>>>> Daten 2025 als CSV export aus QSL

[DS_Starter]

Hallo 300P,

das liegt an der expliziten Auswertung jeder einzelnen Datensatzes bzw. der Differenzen zueinander.
Aus der Commandref:

Es wird die Differenz aus den VALUE-Werten der im Aggregationszeitraum (z.B. day) vorhandenen Datensätze gebildet und aufsummiert. Ein Übertragswert aus der Vorperiode (aggregation) zur darauf folgenden Aggregationsperiode wird berücksichtigt, sofern diese Periode einen Value-Wert enhtält.

In der Standardeinstellung wertet die Funktion nur positive Differenzen aus wie sie z.B. bei einem stetig ansteigenden Zählerwert auftreten. Mit dem Attribut diffAccept) kann sowohl die akzeptierte Differenzschwelle als auch die Möglichkeit negative Differenzen auszuwerten eingestellt werden.

Möglicherweise gibt es in der Reihen einen oder mehrere abfallende Werte, die in der Standardeinstellung nicht gewertet werden, aber danach mit einer stärkeren Steigung wieder Beachtung finden.
Mit dem Attr diffAccept kann man Einfluß nehmen oder wie du es getan hast einfach den ersten und letzten Wert nehmen wenn einem die dazwischen liegenden Schwankungen nicht interessieren.

LG,
Heiko

[300P]

Ohje      ich nutze DBREP jetzt schon x Jahre - hab aber daran überhaupt nicht mehr gedacht ........
Asche über mein Haupt  ich werde wohl zu alt......

Jetzt "zählt alles richt"

[DS_Starter]

Geht mir auch so ... muß nach längerer Zeit auch immer genau nachlesen wie etwas gebaut ist. Es gibt einfach zu viele verschiedene Themen um sich alles zu behalten .