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

[abc2006]

Ja, ich habe ein notify, welches bei jedem save ein backup erzeugt:

Code Auswählen Erweitern

defmod N_backupCFG notify global:SAVE {\
my $now = strftime "%Y%m%d%H%M%S",localtime();;\
system("cp $attr{global}{configfile} ./backup-cfg/fhem.cfg.$now");;\
system("cp $attr{global}{statefile} ./backup-cfg/fhem.state.$now");;\
return;; \
}
attr N_backupCFG room System->global,_types->notify
https://wiki.fhem.de/wiki/Save

Das sollte aber keine Auswirkungen auf das DbRep-Device haben...
Das Problem ist ja an sich nicht das statefile selbst (das protokolliert ja nur das riesige dbRep-Device. Das zeigt nur die Auswirkung (und warum sich fhem stark verlangsamt, wenn ich dieses Device anklicke)

[300P]

Wenn du nur 1 Zählerstand / Minute speicherst, hast du schon in einem Jahr mehr als :
365 × 24 × 60 = 525.600 Einträge
In der Datenbank. 😉

Und Zusatzfrage:
Warum wird da immer fix der Zeitraum 01.11.2024 bis 01.01.2025 angefasst - da evtl. auch mal hinsehen.

[DS_Starter]

Ja, ich habe ein notify, welches bei jedem save ein backup erzeugt:
...
Das sollte aber keine Auswirkungen auf das DbRep-Device haben...

Ich denke die Fragestellung bzw. die Schlußfolgerung ist nicht richtig formuliert.
Das notify hat keine Auswirkung auf DbRep, sondern die Backup-Dateien werden ja durch dein notify gesteuert geschrieben und zwar dann wenn Konfigurationsänderungen an Devices auftreten.
Bezogen auf DbRep gibt es nur ein Scenario mit automatischen Konfig-Änderungen. Das ist bei der Ausführung von

Code Auswählen Erweitern

set ... multiCmd ...

der Fall. Technisch bedingt müssen die geänderten Attributierungen gesetzt/gesichert werden. Das würde in deinem Fall das notify auslösen.

[abc2006]

Ähm... also erstmal vielen Dank für die Antworten und Vorschläge. Meine ursprüngliche Frage ging aber eigentlich nicht darum, warum mein notify eine fhem.state erzeugt oder wie viele Datensätze ich in der Datenbank habe (Spoiler: 1,2 Mrd, deswegen räume ich gerade auf) oder welcher Zeitraum von dem DbRep angefasst wird(Spoiler: 01.11.2024 bis 01.01.2025 wird angefasst, weil in dem Zeitraum mein Stromzähler durch Tibber ersetzt wurde und ich deswegen versucht habe, die Zählerwerte wiederherzustellen)

Wenn mein Ansatz, ein Backup von den States zu machen, falsch ist, nehm ich das gerne an und ändere das. An meiner ursprünglichen Frage ändert das allerdings noch nix:

Meine ursprüngliche Frage zielte darauf ab, warum das DbRep-Device 3 Millionen Readings besitzt, wenn limit nicht gesetzt ist (default: 1000)

Code Auswählen Erweitern

limit - limits the number of selected datasets by the "fetchrows", or the shown datasets of "delSeqDoublets adviceDelete", "delSeqDoublets adviceRemain" commands (default: 1000). This limitation should prevent the browser session from overload and avoids FHEMWEB from blocking. Please change the attribut according your requirements or change the selection criteria (decrease evaluation period).Ich halte das für einen Fehler, z.B. weil mein Fhem dadurch langsam wird (zumindest dieses Device). Entweder habe ich den ausgelöst habe, weil ich etwas grundlegend falsch gemacht habe oder weil das DbRep-Device etwas anderes gemacht hat als es soll. Ich habe meine  Datenbank reorganisiert - ich habe Doubletten und Sequenzielle Doubletten gelöscht. Imho gibts einen Hinweis, dass die Anzahl der Readings bei einem delSeqDoublets auf 1000 beschränkt ist.


######################################################################
edit:

ich habe gerade mit einem anderen Device den Grund herausgefunden. Ich hatte vermutlich ein "averageValue writeToDBInTime" ausgeführt. Das gibt *alle* Zeilen als Readings zurück - ich schlage vor, die Rückgaben generell auf <limit> zu begrenzen.

Da ich jetzt weiss, woher es kommt, kann ich die Readings löschen, damit hat sich mein Problem erledigt.

Vielen Dank,
Stephan

[DS_Starter]

Ich habe die Version 8.53.20 in mein contrib geladen.
<limit> ist nun in sämtlichen Werte-Returns aktiv die potentiel sehr viele readings erzeugen könnten.

In den Readings wird zusätzlich "number_rows_displayed" generiert. Dadurch ist immer ersichtlich ob alle verfügbaren Daten angezeigt/generiert wurden oder ob es Beschränkungen gibt, z.B.:

Code Auswählen Erweitern

   READINGS:
     2026-03-25 12:28:10   2026-03-01__Einspeisung_Summe_kWh__2026-03-01 13.8437
     2026-03-25 12:28:10   2026-03-02__Einspeisung_Summe_kWh__2026-03-02 23.0676
     2026-03-25 12:28:10   2026-03-03__Einspeisung_Summe_kWh__2026-03-03 22.4015
     2026-03-25 12:28:10   2026-03-04__Einspeisung_Summe_kWh__2026-03-04 17.3292
     2026-03-25 12:28:10   2026-03-05__Einspeisung_Summe_kWh__2026-03-05 21.2124
     2026-03-25 12:28:10   2026-03-06__Einspeisung_Summe_kWh__2026-03-06 23.5137
     2026-03-25 12:28:10   2026-03-07__Einspeisung_Summe_kWh__2026-03-07 22.4863
     2026-03-25 12:28:10   2026-03-08__Einspeisung_Summe_kWh__2026-03-08 17.2125
     2026-03-25 12:28:10   2026-03-09__Einspeisung_Summe_kWh__2026-03-09 11.3721
     2026-03-25 12:28:10   2026-03-10__Einspeisung_Summe_kWh__2026-03-10 11.9741
     2026-03-25 12:28:10   2026-03-11__Einspeisung_Summe_kWh__2026-03-11 11.7882
     2026-03-25 12:28:10   2026-03-12__Einspeisung_Summe_kWh__2026-03-12 22.9276
     2026-03-25 12:28:10   2026-03-13__Einspeisung_Summe_kWh__2026-03-13 23.9819
     2026-03-25 12:28:10   2026-03-14__Einspeisung_Summe_kWh__2026-03-14 1.6448
     2026-03-25 12:28:10   2026-03-15__Einspeisung_Summe_kWh__2026-03-15 0.0445
     2026-03-25 12:28:10   2026-03-16__Einspeisung_Summe_kWh__2026-03-16 0.1703
     2026-03-25 12:28:10   2026-03-17__Einspeisung_Summe_kWh__2026-03-17 0.2787
     2026-03-25 12:28:10   2026-03-18__Einspeisung_Summe_kWh__2026-03-18 23.6597
     2026-03-25 12:28:10   2026-03-19__Einspeisung_Summe_kWh__2026-03-19 25.2747
     2026-03-25 12:28:10   2026-03-20__Einspeisung_Summe_kWh__2026-03-20 1.0654
     2026-03-25 12:28:10   2026-03-21__Einspeisung_Summe_kWh__2026-03-21 1.0605
     2026-03-25 12:28:10   2026-03-22__Einspeisung_Summe_kWh__2026-03-22 21.5367
     2026-03-25 12:28:10   2026-03-23__Einspeisung_Summe_kWh__2026-03-23 22.3587
     2026-03-25 12:28:10   2026-03-24__Einspeisung_Summe_kWh__2026-03-24 4.6650
     2026-03-25 12:28:10   2026-03-25__Einspeisung_Summe_kWh__2026-03-25 0.0755
     2026-03-25 12:28:10   background_processing_time 3.5593
     2026-03-25 12:28:10   number_rows_displayed 25 of 25
     2026-03-25 12:28:10   sql_processing_time 3.5551
     2026-03-25 12:28:10   state           done

Ich lasse die neue V bei mir auch noch bis nach dem WE laufen bevor sie eingecheckt wird.

LG,
Heiko

[cwagner]

[Lösung & Hintergrund am Ende als Edit]

Bin sehr dankbar für die Möglichkeit, über Db.Rep die Grünland-Temperatur-Summe zu beobachten. Nach dem Wiki-Eintrag lasse ich jede nacht ein DB.Rep-Device die Temperatur-Daten eines Fühlers auswerten und die GTS schreiben. Dabei stört mich, dass von jedem Lauf von Jahresbeginn an jeder Tageswert sich wiederholt. Meine Vorstellung war, dass praktisch jeweils der neu hinzukommende Wertz des nächsten Tages in die DB geschrieben wird. irgendwas mache ich da doch wohl falsch? Ich finde nur nicht was. Mit deldoublets kann ich die zwar löschen, doch schön ist das ja nicht.

Dann kam ich auf die Idee,mit

Code Auswählen Erweitern

ALTER TABLE history
ADD PRIMARY KEY (`TIMESTAMP`, `DEVICE`, `READING`) USING BTREE;einen Key zu erstellen, der das Einfügen exakt gleicher Werte mit demselben Timestamp verhindert. Doch - obwohl ich deldoulets mehrfach über die gesamte Datenbank laufen liess, meckert die MariaDB immer noch, dass ich Doubletten habe, die das anlegen eines unique keys verbieten. Gibt es Situationen, wo DB.Rep Doubletten nicht erkennt/erkennen kann?

Das fragliche GTS-Device:

Code Auswählen Erweitern

defmod RP.T.Aussen.GLT DbRep logdb
attr RP.T.Aussen.GLT DbLogInclude reachedGTSthreshold
attr RP.T.Aussen.GLT averageCalcForm avgDailyMeanGWSwithGTS
attr RP.T.Aussen.GLT comment https://www.isip.de/isip/servlet/isip-de/entscheidungshilfen/gruenland\

attr RP.T.Aussen.GLT devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
attr RP.T.Aussen.GLT device T_Aussen
attr RP.T.Aussen.GLT event-on-change-reading state
attr RP.T.Aussen.GLT reading temperature
attr RP.T.Aussen.GLT room Wetter
attr RP.T.Aussen.GLT timestamp_begin current_year_begin
attr RP.T.Aussen.GLT userExitFn saveGTS

Die Log-Datenbank sieht so aus:

Code Auswählen Erweitern

defmod logdb DbLog ./db_mysql.conf .*:.*
attr logdb DbLogSelectionMode Include
attr logdb DbLogType History
attr logdb asyncMode 1
attr logdb devStateIcon connected:10px-kreis-grün .*disconnect:10px-kreis-rot .*done:10px-kreis-gelb
attr logdb event-on-change-reading state
attr logdb room System
attr logdb suppressUndef 1
attr logdb valueFn {if ($VALUE eq ""){$IGNORE=1;;}}

Danke für Hinweise & Ideen schon mal sehr herzlich im Voraus
Christian
-------
Das hier angerissene Thema hat zwei Hintergründe, die mir erst durch die folgende Diskussion klar wurden. Um das Ziel der "Doubletten"-Verhinderung wirksam für die Zukunft umzusetzen, hatte ich ja eine Datenbank-Umstellung auf einen primary Key ins Auge gefasst. Das scheiterte aber daran, dass es Doubletten gab, die Db.Rep nicht als Doubletten erkennt (und das ist auch richtig so!), die Datenbank aber wohl und deswegen das Anlegen des Index verweigerte.

FHEM speichert vom Design her sekundengenaue Timestamps. Auf einem schnellen Rechner können aber in einer solchen Sekunde für ein Device bei realtimenahen-Steuerungs-Aufgaben mehrere Ereignisse passieren, deren Value unterschiedlich ist (die auch bei einer vorgegebenen numerischen Schwelle nicht durch event-on-change-reading abgefangen werden). Dann stimmen zwar timestamp, device, reading überein, nicht aber der value und somit ist es auch aus dbRep-Sicht keine Doublette, was den Ausgangspunkt meines Falles mit dem Erzeugen und Speichern von Gründlandtemperatur-Summen bildet.

Mit einem primary Key auf timestamp, device, reading verhindert man das erneute Speichern eines value in derselben Sekunde in die Datenbank. Es gewinnt also immer der erste Wert. Kommt das GTS-Script nun an einem späteren Tag und will denselben Wert noch einmal schreiben, verweigert es einfach die Datenbank: "Basta."

In nachfolgenden Beitrag #2246 hat Heiko ein Schema beschrieben, mit dem sich eine gewachsene Datenbank von solchen als "Schein-"Doubletten bereinigen lässt, ehe man den primary key setzen kann und es für die Zukunft verhindert.

Das mein Thema auslösende vielfache Schreiben immer wieder derselben Gründlandtemperatur-Summen bei täglicher Aktualisierung mit DbRep nach dem Schema aus dem Wiki lässt sich wie im Beitrag #2243 von 300P beschrieben auch ohne primary Key mit DbRep nachträglich zu entfernen. Spezialisten mögen wahrscheinlich auch einen Weg finden, nur den neuesten Wert in die Datenbank mit saveGTS zu speichern. Wenn also GTS das einzige Doubletten-Thema wäre, wäre das kein Grund für einen primary key.

Userreadings, mit denen zum Beispiel Werte Readings mit zahllosen Nachkommastellen gerundet oder Roh-Werte umgewandelt werden, um sie in genau das Quell-Reading zurückzuschreiben ist ebenfalls ein Quell für "Schein"-Doubletten - zumindest auf schnellen Rechnern, wenn die Rundung oder Umrechnung in der gleichen logischen Sekunde ein paar Millisekunden später stattfindet. Hier würde ein primary Key dann das Speichern verhindern, "ist ja schon einer da". Das lässt sich dann nur mit einem abgewandelten Readingnamen verhindern.

Soweit wie ich es jetzt verstanden habe, könnten selbst Kleinstrechner wie ein PI durchaus auch die Sekunde noch in Milli- oder kleinere Sekundenbruchteile auflösen, Perl würde  solche fraktionale Sekunden verarbeiten könne FHEM. FHEM arbeitet per Design auf Sekunden-Basis, was in den allermeisten Fällen auch absolut ausreichend ist.

[DS_Starter]

Hallo Christian,

Dubletten werden schon erkannt, aber es muß ja die ganze DB bezüglich jeder Kombi aus `TIMESTAMP`, `DEVICE`, `READING` geprüft werden und nicht nur die du in den Attributen angegeben hast.

Um eine Liste der Dubletten zu bekommen kannst du in sqlCmd ausführen:

Code Auswählen Erweitern

SELECT `TIMESTAMP`, `DEVICE`, `READING`, COUNT(*) as anzahl FROM history GROUP BY `TIMESTAMP`, `DEVICE`, `READING` HAVING COUNT(*) > 1;

Wenn es nur vereinzelte sind, kann man sie gezielt manuell löschen.
Wenn allerdings Massen von Dubletten vorkommen müßte ich auch erst googeln wie man das am Besten bereinigt bekommt.
Vllt. können SQL-Experten hier unterstützen.

VG,
Heiko

[cwagner]

Dubletten werden schon erkannt, aber es muß ja die ganze DB bezüglich jeder Kombi aus `TIMESTAMP`, `DEVICE`, `READING` geprüft werden und nicht nur die du in den Attributen angegeben hast.

Vielen Dank, Heiko, für den Ansatz, der mich auf jeden Fall auf einen Irrweg meinerseits aufmerksam machte: Tatsächlich habe ich, als ich bei spezifischen deldoublet-Versuchen falsch herum gedacht und durch weglassen von Attribut Device und/oder Reading gedanklich die Schrotflinte aufgemacht habe, um möglichst alle Doubletten zu erwischen.

Tatsächlich hatte ich aber auch schon vorher spezifisch gesucht und mir ein "number_rows_to_delete  0" geholt zum Beispiel für diese Einstellung:

Code Auswählen Erweitern

defmod DBRep.Arbeit DbRep logdb
attr DBRep.Arbeit countEntriesDetail 1
attr DBRep.Arbeit device T_Aussen
attr DBRep.Arbeit reading GrasslandTemperatureSum
attr DBRep.Arbeit room System
attr DBRep.Arbeit widgetOverride device:textField,175
Frage ich mit Deinem SQL-Vorschlag (und auch eigenen in HeidiSQL) die Datenbank ab, kriege ich (Auszug) zum Beispiel dies:

Code Auswählen Erweitern

TIMESTAMP;DEVICE;READING;anzahl
2025-04-13 12:00:00;T_Aussen;GrasslandTemperatureSum;2
2025-04-14 12:00:00;T_Aussen;GrasslandTemperatureSum;2
2025-04-15 12:00:00;T_Aussen;GrasslandTemperatureSum;2
2025-04-16 12:00:00;T_Aussen;GrasslandTemperatureSum;2
2025-04-18 12:00:00;T_Aussen;GrasslandTemperatureSum;2
2025-04-19 13:48:35;Steller_Zuluft;Stufe;2
2025-04-19 13:48:35;Steller_Zuluft;gpio;2
2025-04-20 12:00:00;T_Aussen;GrasslandTemperatureSum;2
2025-04-21 12:00:00;T_Aussen;GrasslandTemperatureSum;2
2025-04-22 12:00:00;T_Aussen;GrasslandTemperatureSum;2
2025-04-23 12:00:00;T_Aussen;GrasslandTemperatureSum;2
Auch bei Steller_Zuluft hatte ich Db.Rep mit dem Device und dem Reading Stufe,gpio auf Doubletten-Jagd gesandt.

Offenbar mache ich etwas bei Doubletten-Suchen (advice wie delete) grundfalsch?

Christian

[300P]

Ich lösche meine Doubletten wie folgt: 

Code Auswählen Erweitern

defmod at.deldoubletsLast10Days.Rep at *02:00:00 set DoMySQLcmdInRangeLast10Day.DbRepMySQL delDoublets delete
attr at.deldoubletsLast10Days.Rep group 002_DoMySQLcmd
attr at.deldoubletsLast10Days.Rep room 000_Datenbank
und mit diesem zugehörig .....

Code Auswählen Erweitern

defmod DoMySQLcmdInRangeLast10Day.DbRepMySQL DbRep myDbLog
attr DoMySQLcmdInRangeLast10Day.DbRepMySQL comment da es nach Mitternacht passiert 2te - 11te Tag
attr DoMySQLcmdInRangeLast10Day.DbRepMySQL group 002_DoMySQLcmd
attr DoMySQLcmdInRangeLast10Day.DbRepMySQL room 000_Datenbank
attr DoMySQLcmdInRangeLast10Day.DbRepMySQL timeDiffToNow d:11 FullDay
attr DoMySQLcmdInRangeLast10Day.DbRepMySQL timeOlderThan d:2 FullDay
attr DoMySQLcmdInRangeLast10Day.DbRepMySQL verbose 2

Am Anfang hab ich das natürlich manuell geändert und damit in den "älteren" und gröberen Zeiträumen gemacht....bis das alles sauber war. 
Aber auch nicht zu groß wählen - dauert sonst laaaaaannnnnnggggeeeee.

Aber dafür din ich jetzt immer (hoffentlich) "clean".

[cwagner]

Ich lösche meine Doubletten wie folgt: 

Auch Dir Danke für die Vorstellung Deines Konzeptes - mein Ausgangspunkt war, Doubletten grundsätzlich über einen Primärkey zu verhindern. Doch da stieß ich auf die auch mit Heikos sql-Statement sofort bestätigte Behauptung der Datenbank, da gäbe es Doubletten, was DbReg anders "sieht".

Mal sehen, ob ich da noch irgendeinen Zusammenhang erkenne, ingesamt sind es über 700 Fundstellen, zuviel für händisches Löschen, genug um ein Schema zu erkennen (über das im ersten Post beschriebene Thema der Gründlandsumme, die eben bei Aufrufen für die Periode immer neu vollständig kalkuliert wird und in die Datenbank reingetackert wird.

Christian

[DS_Starter]

Moin,

ich habe eine Vorgehensweise zusammengestellt wie Lösungen des Problems aussehen könnten.
Vorher immer ein valides Backup erstellen bzw. haben!

LG,
Heiko

----------------------------------------------------------

Primary Key bei vorhandenen Duplikaten anlegen Das Problem ist, dass ein Primary Key eindeutig sein muss – Duplikate (Dubletten) müssen zuerst bereinigt werden. Hier sind die Optionen:

1. Duplikate identifizieren

Zuerst schauen, welche Datensätze mehrfach vorkommen:

Code Auswählen Erweitern

SELECT `TIMESTAMP`, `DEVICE`, `READING`, COUNT(*) as anzahl
 FROM history
 GROUP BY `TIMESTAMP`, `DEVICE`, `READING`
 HAVING COUNT(*) > 1;
2. Duplikate entfernen

Option A – Duplikate löschen, neuesten Datensatz behalten (empfohlen)

Code Auswählen Erweitern

DELETE t1 FROM history t1
 INNER JOIN history t2
 WHERE
    t1.id > t2.id AND  -- falls eine AUTO_INCREMENT-Spalte existiert
    t1.TIMESTAMP = t2.TIMESTAMP AND
    t1.DEVICE    = t2.DEVICE AND
    t1.READING   = t2.READING;
Falls keine id-Spalte existiert, zuerst eine temporäre hinzufügen (siehe Option C).

Option B – Saubere Tabelle über INSERT INTO ... SELECT DISTINCT

 

Code Auswählen Erweitern

CREATE TABLE history_clean LIKE history;
 INSERT INTO history_clean SELECT DISTINCT * FROM history;
 RENAME TABLE history TO history_old, history_clean TO history;
Danach den Primary Key auf der neuen Tabelle anlegen und history_old löschen.

Option C – Temporäre ID-Spalte zum gezielten Löschen

Code Auswählen Erweitern

-- Temporäre Hilfsspalte hinzufügen
ALTER TABLE history ADD COLUMN tmp_id INT AUTO_INCREMENT PRIMARY KEY;

-- Duplikate löschen (nur niedrigste tmp_id behalten)
DELETE FROM history
WHERE tmp_id NOT IN (
    SELECT min_id FROM (
        SELECT MIN(tmp_id) AS min_id
        FROM history
        GROUP BY `TIMESTAMP`, `DEVICE`, `READING`
    ) AS t
);

-- Hilfsspalte wieder entfernen
ALTER TABLE history DROP COLUMN tmp_id;

3. Primary Key anlegen

Nachdem die Duplikate entfernt wurden:

 

Code Auswählen Erweitern

ALTER TABLE history ADD PRIMARY KEY (`TIMESTAMP`, `DEVICE`, `READING`) USING BTREE;

[cwagner]

Lieber Heiko,

vielen Dank für die grandiose Bereitschaft zur Hilfe. Das schreibe ich, während die ersten Schritte Deines  überzeugenden "Fahrplans" laufen. Ich werde den Thread später als gelöst kennzeichnen und im Ausgangspunkt auch noch einmal grundsätzliche Learnings aus dem Beispiel aufzeigen. Grund-Ursache ist ja die Desgin-Entscheidung, dass FHEM timestamps nur mit vollen Sekunden schreibt. Somit ist ein gleicher Timestamp bei sehr schnell geschriebenen Events nur optisch "gleichzeitig". Und DbRep kann natürlich nur auf dieser Sekundenbasis zwei in der "gleichen" Sekunde entstandene, im Value sich dann unterscheidende Events nicht als Doublette erkennen.

Christian

[DS_Starter]

Morgen Christian,

Grund-Ursache ist ja die Desgin-Entscheidung, dass FHEM timestamps nur mit vollen Sekunden schreibt. Somit ist ein gleicher Timestamp bei sehr schnell geschriebenen Events nur optisch "gleichzeitig".

Ja, absolut richtig.
FHEM kennt "eigentlich" auch ms über das global Attr mseclog. Das zieht aber nur für FileLog.
Als ich DbLog vor Jahren übernommen hatte, war der Stand des Loggings auf Sekunden-Basis. Das habe ich bis heute so belassen weil es m.M. nach auch keine Veranlassung gibt für unsere
Belange mit einer höheren Auflösung zu loggen. Hat aber den bschriebenen Nachteil.
Ich könnte auch nicht unmittelbar sagen, welchen Aufwand es bedeuten würde die Einstellung des globalen Attr in DbLog/DbRep abzubilden. Meine "Haupttätigkeit" liegt aktuell bei SolarForecast.

LG und schönes WE,
Heiko