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