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.