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

Begonnen von DS_Starter, 19 Mai 2016, 22:52:13

Vorheriges Thema - Nächstes Thema

300P

FHEM 6.3 - Raspberry Pi 3 / Pi 4 - VControl300 mit VITOVALOR 300P - SMAEM - SMAInverter - DbLog/DbRep - MariaDB/QNAP - div. HTTPMOD - div. Modbus ser+TCP - SolarForecast - Tibber + Ladung mit SMA-SBS25

300P

Hab inzwischen meine SQL bereinigt.
??? :o da haben sich in 5 Jahren fast 15.000 Datensätze mit EMPTY-VALUE-Werten aus verschiedensten Modulen angesammelt die jetzt durch eine Bereinigungsaktion bei mir weg sind....

DELETE FROM `fhem`.`history`
WHERE `VALUE` = ''
AND `EVENT` LIKE '%: 0';

Werde mir eine monatliche Routine schreiben damit es nicht wieder so viele bei mir werden.

Gruß
300P


FHEM 6.3 - Raspberry Pi 3 / Pi 4 - VControl300 mit VITOVALOR 300P - SMAEM - SMAInverter - DbLog/DbRep - MariaDB/QNAP - div. HTTPMOD - div. Modbus ser+TCP - SolarForecast - Tibber + Ladung mit SMA-SBS25

DS_Starter

Könnte sein:


define At.Del.Rep at +*XX:XX:XX set <DbRep> sqlCmd DELETE FROM `fhem`.`history` WHERE `VALUE` = '' AND `EVENT` LIKE '%: 0';


ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

dk3572

Hallo Heiko,

ich habe täglich folgende Warnung in meinem Log:

Warnung
2023.02.04 01:17:00.042 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/93_DbRep.pm line 3397.

Log komplett mit Warnung
2023.02.04 00:05:00.006 3: DbRep Rep.SQLite.Backup - ################################################################
2023.02.04 00:05:00.010 3: DbRep Rep.SQLite.Backup - ###                    New SQLite dump                       ###
2023.02.04 00:05:00.010 3: DbRep Rep.SQLite.Backup - ################################################################
2023.02.04 00:05:00.010 3: DbRep Rep.SQLite.Backup - execute command before dump: 'set logdb reopen 3600'
2023.02.04 00:05:00.015 2: DbLog logdb - Connection closed until 01:05:00 (3600 seconds).
2023.02.04 00:05:00.065 3: DbRep Rep.SQLite.Backup - Size of database /opt/fhem.db before optimize (MB): 11901.48 MB
2023.02.04 00:05:00.065 3: DbRep Rep.SQLite.Backup - VACUUM database /opt/fhem.db....
2023.02.04 00:05:00.182 3: DbLog logdb - Database disconnected by request.
2023.02.04 00:17:23.601 3: DbRep Rep.SQLite.Backup - Size of database /opt/fhem.db after optimize (MB): 11900.46 MB
2023.02.04 00:17:23.601 3: DbRep Rep.SQLite.Backup - Starting dump of database 'fhem.db'
2023.02.04 00:19:20.513 3: DbRep Rep.SQLite.Backup - Size of backupfile: 11900.46 MB
2023.02.04 00:19:20.515 3: DbRep Rep.SQLite.Backup - Deleting old dumpfile 'fhem_2023_02_01_00_17.sqlitebkp'
2023.02.04 00:19:20.536 3: DbRep Rep.SQLite.Backup - Finished backup of database fhem - total time used (hh:mm:ss): 00:14:20
2023.02.04 00:19:20.549 3: DbLog logdb - Reopen requested
2023.02.04 00:19:20.565 2: DbRep Rep.SQLite.Backup - command message after dump: "Reopen executed."
2023.02.04 00:19:20.569 3: DbRep Rep.SQLite.Backup - Database dump finished successfully.
2023.02.04 00:19:20.707 3: DbLog logdb - Database disconnected by request.
2023.02.04 00:19:43.749 3: DbLog logdb - SubProcess connected to /opt/fhem.db
2023.02.04 01:15:00.148 3: DbRep Rep.total_pac - number of lines updated in >logdb<: 3
2023.02.04 01:15:00.151 3: DbRep Rep.total_pac - number of lines inserted into >logdb<: 1
2023.02.04 01:16:00.129 3: DbRep Rep.total_pac - number of lines updated in >logdb<: 3
2023.02.04 01:16:00.129 3: DbRep Rep.total_pac - number of lines inserted into >logdb<: 1
2023.02.04 01:17:00.042 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/93_DbRep.pm line 3397.
2023.02.04 01:17:00.065 3: DbRep Rep.total_pac - number of lines updated in >logdb<: 6
2023.02.04 01:17:00.065 3: DbRep Rep.total_pac - number of lines inserted into >logdb<: 0


DbLog Device
COLUMNS    field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
   CONFIGURATION ./db.conf
   DEF        ./db.conf .*:.*
   FD         7
   FUUID      5eb961f7-f33f-cd72-b3f6-f6ca8383a8350f4c
   FVERSION   93_DbLog.pm:v5.8.0-s27165/2023-02-01
   MODE       asynchronous
   MODEL      SQLITE
   NAME       logdb
   NR         2
   NTFY_ORDER 50-logdb
   PID        30366
   REGEXP     .*:.*
   SBP_PID    30368
   SBP_STATE  running
   STATE      connected
   TYPE       DbLog
   dbconn     SQLite:dbname=/opt/fhem.db
   dbuser     
   eventCount 1802
   HELPER:
     COLSET     1
     DEVICECOL  64
     EVENTCOL   512
     OLDSTATE   connected
     PACKAGE    main
     READINGCOL 64
     TC         current
     TH         history
     TYPECOL    64
     UNITCOL    32
     VALUECOL   128
     VERSION    5.8.0
   OLDREADINGS:
   READINGS:
     2023-02-04 07:18:55   CacheOverflowLastNum 0
     2023-02-04 00:19:50   CacheOverflowLastState normal
     2023-02-04 07:18:56   CacheUsage      7
     2023-02-04 07:18:55   NextSync        2023-02-04 07:19:25 or when CacheUsage 500 is reached
     2023-02-04 07:18:55   state           connected
Attributes:
   DbLogExclude .*
   DbLogSelectionMode Exclude/Include
   DbLogType  Current/History
   asyncMode  1
   insertMode 1
   valueFn    {
   if ($DEVICE eq "SMA_Wechselrichter") {
     if( ($READING eq "etoday" || $READING eq "etotal") && $VALUE > 4000000 ) {
       Log3 ($DEVICE, 1, "Reading: $READING with Value: $VALUE was ignored and not logged. ");
       $IGNORE = 1;
     }
   }
}
   verbose    3


DbRep Device nach dem die Warung kommt
  DATABASE   /opt/fhem.db
   DEF        logdb
   FUUID      5ec9522c-f33f-cd72-2c67-4a017ef05f4c2b3f
   FVERSION   93_DbRep.pm:v8.51.4-s27164/2023-02-01
   LASTCMD    averageValue writeToDB
   MODEL      Client
   NAME       Rep.total_pac
   NOTIFYDEV  global,Rep.total_pac
   NR         416
   NTFY_ORDER 50-Rep.total_pac
   ROLE       Client
   STATE      done
   TYPE       DbRep
   UTF8       1
   eventCount 14
   HELPER:
     DBLOGDEVICE logdb
     IDRETRIES  2
     MINTS      2020-04-13 21:54:39
     PACKAGE    main
     VERSION    8.51.4
     CV:
       aggregation day
       aggsec     86400
       destr      2023-02-04
       dsstr      2023-02-01
       epoch_seconds_end 1675469820
       mestr      02
       msstr      02
       testr      01:17:00
       tsstr      00:00:00
       wdadd      432000
       yestr      2023
       ysstr      2023
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      512
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
   OLDREADINGS:
   READINGS:
     2023-02-04 01:17:00   2023-02-01__SMA_Wechselrichter__total_pac__AVGAM__2023-02-01 0.5815
     2023-02-04 01:17:00   2023-02-02__SMA_Wechselrichter__total_pac__AVGAM__2023-02-02 0.3833
     2023-02-04 01:17:00   2023-02-03__SMA_Wechselrichter__total_pac__AVGAM__2023-02-03 0.5685
     2023-02-04 01:17:00   2023-02-04__SMA_Wechselrichter__total_pac__AVGAM__2023-02-04 -
     2023-02-04 01:17:00   background_processing_time 0.0421
     2023-02-04 01:17:00   db_lines_processed 6
     2023-02-04 01:17:00   sql_processing_time 0.0222
     2023-02-04 01:17:00   state           done
Attributes:
   DbLogExclude .*
   aggregation day
   allowDeletion 1
   devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
   device     SMA_Wechselrichter
   event-on-update-reading state
   reading    total_pac
   room       Photovoltaik
   showproctime 1
   timestamp_begin current_month_begin
   verbose    3


Kannst du mir hier weiter helfen?

Danke und ein schönes Wochenende.
VG Dieter

DS_Starter

Morgen Dieter,

es fehlt ein Wert im Write Back. Unklar ist momentan welcher genau.
Deswegen habe ich dir eine Testversion in mein contrib gestellt.
Damit kommen mit verbose 3 solche Meldungen im Log:


2023.02.04 08:53:50.438 3: DbRep Rep.CPU - Write Back String: 2023-01-05#163.18804664723#2023-01-05_11:12:08#2023-01-05_23:21:16|
2023.02.04 08:53:50.456 3: DbRep Rep.CPU - number of lines updated in >LogDB<: 2
2023.02.04 08:53:50.456 3: DbRep Rep.CPU - number of lines inserted into >LogDB<: 0


Im "Write Back String" sollte dann der fehlende Wert erkennbar sein.

Grüße,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

dk3572

Danke für die schnelle Unterstützung.

Hier das Ergebnis, mit dem ich allerdings nicht viel anfangen kann  ???
2023.02.04 09:32:59.903 3: DbRep Rep.total_pac - number of lines updated in >logdb<: 3
2023.02.04 09:32:59.903 3: DbRep Rep.total_pac - number of lines inserted into >logdb<: 1
2023.02.04 09:33:18.864 3: DbRep Rep.total_pac - number of lines updated in >logdb<: 4
2023.02.04 09:33:18.864 3: DbRep Rep.total_pac - number of lines inserted into >logdb<: 0
2023.02.04 09:33:27.700 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/93_DbRep.pm line 3400.
2023.02.04 09:33:27.700 3: DbRep Rep.total_pac - Write Back String: 2023-02-01#0.581517816527674#2023-02-01_00:00:00#2023-02-02_|
2023.02.04 09:33:27.700 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/93_DbRep.pm line 3402.
2023.02.04 09:33:27.703 3: DbRep Rep.total_pac - Write Back String: 2023-02-02#0.383271541686074#2023-02-02_#2023-02-03_|
2023.02.04 09:33:27.707 3: DbRep Rep.total_pac - Write Back String: 2023-02-03#0.568531518624643#2023-02-03_#2023-02-04_|
2023.02.04 09:33:27.707 3: DbRep Rep.total_pac - Write Back String: 2023-02-04#0.399760162601626#2023-02-04_#2023-02-04_09:33:27|
2023.02.04 09:33:27.721 3: DbRep Rep.total_pac - number of lines updated in >logdb<: 8
2023.02.04 09:33:27.721 3: DbRep Rep.total_pac - number of lines inserted into >logdb<: 0

DS_Starter

Danke Dieter. Ich sehe es.
Es fehlt teilweise ein Stringteil 2023-02-03_....

Konnte es bei mir jetzt nachstellen und melde mich wieder mit einer Lösung.

LG
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

Hallo Dieter, @all,

ich habe das von dir gemeldete Problem gelöst, getestet und eingecheckt.
Neue V ist morgen früh im Update enthalten.

LG,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

dk3572

Guten Morgen Heiko,

Meldung taucht nicht mehr auf.

Wie immer, toller support.
Vielen Dank und eine schöne Woche.

VG Dieter

h0nIg

Hallo zusammen,

ich aggregiere aktuell mit diffValue und erhalte komischerweise falsche StartDaten für die Wochenaggregation.

2022-05-01_00:00:15 0.0000
2022-05-07_20:03:36 30.3000
2022-05-14_20:04:30 21.4120
2022-05-21_20:04:25 21.1900
2022-05-28_20:03:20 19.0250


Wobei ich für andere readings des gleichen phyischen Devices die richtige Wochen-Startzeit kriege:

2022-04-18_23:59:58 0.0000
2022-05-01_23:57:14 9.1330
2022-05-08_23:57:35 21.5490
2022-05-15_23:59:29 10.8130
2022-05-22_23:57:24 7.3580
2022-05-29_23:58:19 11.6910


Woran wird es den festgemacht, welche Startzeit genommen wird? Für beide Readings beginnen die Daten zur gleichen Zeit?

Die Konfiguration sieht gleich aus:

define logdb.weekly.Strom.WP.HT DbRep logdb
attr logdb.weekly.Strom.WP.HT aggregation week
attr logdb.weekly.Strom.WP.HT device MQTT2_Z_WP
attr logdb.weekly.Strom.WP.HT reading MT681_Total_in_HT
attr logdb.weekly.Strom.WP.HT showproctime 1
attr logdb.weekly.Strom.WP.HT timestamp_begin previous_year_begin
attr logdb.weekly.Strom.WP.HT timestamp_end previous_week_end
attr logdb.weekly.Strom.WP.HT readingNameMap agg_HT

define logdb.weekly.Strom.WP.NT DbRep logdb
attr logdb.weekly.Strom.WP.NT aggregation week
attr logdb.weekly.Strom.WP.NT device MQTT2_Z_WP
attr logdb.weekly.Strom.WP.NT reading MT681_Total_in_NT
attr logdb.weekly.Strom.WP.NT showproctime 1
attr logdb.weekly.Strom.WP.NT timestamp_begin previous_year_begin
attr logdb.weekly.Strom.WP.NT timestamp_end previous_week_end
attr logdb.weekly.Strom.WP.NT readingNameMap agg_NT


Grüße

sinemeter

Hallo zusammen,

ich habe mal eine Frage zur Dauer des DbRep Dumps:

Raspberry Pi4 mit 4 GB RAM:
sandisc extreme pro SD Karte: 64 GB 
DB Größe: ca. 2,4 GB (Log läuft seit 2018)
Größe der SQL Datei nach dem Dump ca. 1,3 GB
Fhem und MariaDB laufen in separaten Docker Containern

Der Dump läuft beri mir gute 4 Stunden was mir trotz der Größe ziemlich langsam vorkommt.
Attribut Dumpspeed habe ich noch nicht verändert.

Ist der Wert realistisch oder meint ihr das da mehr rauszuholen wäre? Die SD Karte ist ansonsten beim kopieren von Dateien ja recht flott.
Hier mein Top des Hosts während der Dump läuft:


top - 13:54:51 up 11 days, 23:30,  3 users,  load average: 1,17, 1,30, 1,46
Tasks: 307 total,   2 running, 303 sleeping,   0 stopped,   2 zombie
%CPU0  : 11,0 us,  7,6 sy,  0,0 ni, 54,5 id, 26,6 wa,  0,0 hi,  0,3 si,  0,0 st
%CPU1  :  7,6 us,  1,3 sy,  0,0 ni, 89,0 id,  2,0 wa,  0,0 hi,  0,0 si,  0,0 st
%CPU2  :  7,7 us,  5,4 sy,  0,0 ni, 65,7 id, 21,2 wa,  0,0 hi,  0,0 si,  0,0 st
%CPU3  :  5,3 us,  5,6 sy,  0,0 ni, 72,5 id, 16,6 wa,  0,0 hi,  0,0 si,  0,0 st
MiB Spch:   3794,4 total,    625,8 free,   2005,9 used,   1162,6 buff/cache
MiB Swap:    100,0 total,     45,2 free,     54,8 used.   1623,4 avail Spch

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     ZEIT+ BEFEHL
   2099 999       20   0 2350468 409700   7464 S  27,5  10,5 332:20.75 mariadbd
2563985 6061      20   0  293792 214308  14536 R   5,6   5,5  96:11.22 perl
4001830 root       0 -20       0      0      0 I   4,3   0,0   0:38.01 kworker/0:2+
   2275 pi        20   0 1595912  56132  18032 S   3,6   1,4 572:36.74 deCONZ
4021557 pi        20   0   10572   3628   2856 R   1,3   0,1   0:00.19 top
2559176 root      20   0   14532   4108   3072 S   1,0   0,1  12:42.80 entry.sh
3987435 root       0 -20       0      0      0 I   1,0   0,0   0:18.37 kworker/2:1+
3988948 root       0 -20       0      0      0 I   1,0   0,0   0:15.40 kworker/3:1+
     14 root      20   0       0      0      0 S   0,7   0,0   6:53.52 ksoftirqd/0
   1997 root      20   0  711676   3964   1752 S   0,7   0,1   1:38.66 containerd-+
     15 root      20   0       0      0      0 I   0,3   0,0  18:08.49 rcu_preempt
   1662 root      20   0 1443640   3452   1752 S   0,3   0,1   5:39.14 docker-proxy
   1834 root      20   0  712188   4632   2276 S   0,3   0,1   1:54.80 containerd-+
   5493 _rpc      20   0    7380   1276    516 S   0,3   0,0  26:39.94 avahi-daemon



Ich frage mich ob ich hier noch mehr Geschwindigkeit rauszuholen ist, oder erwarte ich zuviel?

Hier meine Devices:

defmod DBLogging DbLog /opt/fhem/db.conf .*:.*
attr DBLogging DbLogSelectionMode Include
attr DBLogging alias Datenbank Logging
attr DBLogging asyncMode 1
attr DBLogging group Logging
attr DBLogging icon audio_playlist
attr DBLogging insertMode 1
attr DBLogging room Log



defmod DBLogging_DbRep DbRep DBLogging
attr DBLogging_DbRep DbLogExclude .*
attr DBLogging_DbRep DbLogInclude state,DumpFileCreatedSize,DumpRowsHistory,background_processing_time
attr DBLogging_DbRep alias Datenbank Logging DbRep
attr DBLogging_DbRep comment x\
{backupSqlFiles("DBLogging_DbRep")}\

attr DBLogging_DbRep dumpFilesKeep 1
attr DBLogging_DbRep event-on-change-reading state,DumpFileCreatedSize,DumpRowsHistory,background_processing_time,DumpFileCreated
attr DBLogging_DbRep executeAfterProc set Pibot _msg Dunp beendet
attr DBLogging_DbRep executeBeforeProc set Pibot _msg SQL Dump beginnt
attr DBLogging_DbRep group Logging
attr DBLogging_DbRep icon file_pod
attr DBLogging_DbRep optimizeTablesBeforeDump 1
attr DBLogging_DbRep room Log


P.S.: Das Kommando {backupSqlFiles("DBLogging_DbRep")} nach M. Kleines Anleitung zur Kopie aufs Nas ist hier nur als Kommentar hinterlegt da ich damit noch experimentiere.

DS_Starter

@sinemeter,

ich denke du könntest die Geschwindigkeit erhöhen wenn du die Attr wie folgt setzt:


dumpMemlimit 1000000
dumpSpeed     100000


Du kannst sicherlich weiter erhöhen sofern der RAM ausreicht und dein Server nicht in den Swap läuft.
Das musst du ein bisschen beobachten.
Wichtig ist auch auch dass die Datenbank indiziert ist (DbLog configCheck ausführen).

Zum Vergleich ... bei mir läuft der dumpMySQL clientSide einer 3,5 GB MariaDB rund 1500 Sekunden, also knapp 0,5 h.
Allerdings als VM auf einem NUC.

Deutlich schneller ist dumpMySQL serverSide der gleichen Datenbank. Er braucht nur 80 Sekunden.

Die beiden Verfahren haben als Ergebnis aber unterschiedliche Daten (SQL vs. CSV) und arbeiten verschieden.
Das ist aber in der Commandref beschrieben denke ich. 
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

@h0nIg,

die Startzeit für die Datenselektion erfolgt immer (in deinem Setup!) durch die Festlegung im Attr timestamp_begin.
Das sieht man deutlich im Log mit verbose 4.

Die Ergebnisreadings sind davon abhängig, wann im Zeitraum bzw. der Aggregation der erste auswertbare Wert in der DB gefunden wird.

Vergleiche die Commandref:

Zitat
....
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. Deswegen wird eine Warnung im "state" und das Reading "less_data_in_period" mit einer Liste der betroffenen Perioden wird erzeugt.

    Hinweis:
    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.

Nähere Informationen zum Ablauf sieht man ebenfalls mir verbose 4 im Log.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

sinemeter

Zitat von: DS_Starter am 07 Februar 2023, 15:01:51
@sinemeter,

ich denke du könntest die Geschwindigkeit erhöhen wenn du die Attr wie folgt setzt:


dumpMemlimit 1000000
dumpSpeed     100000



Vielen Dank!! Hat gewirkt. Zeit jetzt <45 Min.

Leider noch eine Frage:

Das

attr DBLogging_DbRep executeAfterProc {backupSqlFiles("DBLogging_DbRep")}


führt er garnicht aus.

Dagegen das fhem Kommando zum Telegram Note was ich vorher drin hatte führt er aber normal aus.
Device:

defmod DBLogging_DbRep DbRep DBLogging
attr DBLogging_DbRep DbLogExclude .*
attr DBLogging_DbRep DbLogInclude state,DumpFileCreatedSize,DumpRowsHistory,background_processing_time
attr DBLogging_DbRep alias Datenbank Logging DbRep
attr DBLogging_DbRep dumpFilesKeep 1
attr DBLogging_DbRep dumpMemlimit 1000000
attr DBLogging_DbRep dumpSpeed 100000
attr DBLogging_DbRep event-on-change-reading state,DumpFileCreatedSize,DumpRowsHistory,background_processing_time,DumpFileCreated
attr DBLogging_DbRep executeAfterProc {backupSqlFiles("DBLogging_DbRep")}
attr DBLogging_DbRep executeBeforeProc set Pibot _msg SQL Dump beginnt
attr DBLogging_DbRep group Logging
attr DBLogging_DbRep icon file_pod
attr DBLogging_DbRep optimizeTablesBeforeDump 1
attr DBLogging_DbRep room Log

setstate DBLogging_DbRep Database backup finished
setstate DBLogging_DbRep 2023-02-08 10:26:41 DumpFileCreated ./log/fhem_2023_02_08_09_40.sql
setstate DBLogging_DbRep 2023-02-08 10:26:41 DumpFileCreatedSize 1376.80 MB
setstate DBLogging_DbRep 2023-02-08 10:26:41 DumpFilesDeleted fhem_2023_02_08_01_00.sql
setstate DBLogging_DbRep 2023-02-08 10:26:41 DumpRowsCurrent 0
setstate DBLogging_DbRep 2023-02-08 10:26:41 DumpRowsHistory 6415032
setstate DBLogging_DbRep 2023-02-08 10:26:41 background_processing_time 2786.7522
setstate DBLogging_DbRep 2023-02-08 10:26:41 state Database backup finished


Führe ich
{backupSqlFiles("DBLogging_DbRep")}
über die Befehlszeile aus läuft das Kommando durch und returned 1.
In 99_myUtils.pm habe ich sonst nix drin:


##############################################
# $Id: myUtilsTemplate.pm 21509 2020-03-25 11:20:51Z rudolfkoenig $
#
# Save this file as 99_myUtils.pm, and create your own functions in the new
# file. They are then available in every Perl expression.

package main;

use strict;
use warnings;

sub
myUtils_Initialize($$)
{
  my ($hash) = @_;
}

# Enter you functions below _this_ line.
sub backupSqlFiles($) {
my ($devspec) = @_;

my $file = ReadingsVal($devspec, "DumpFileCreated", "");
if ($file ne "") {
system("scp $file fhem\@qnas.fritz.box:/share/homes/fhem/backups/ &");
fhem("set Pibot _msg 'mySQL' 'Der Dump wurde erfolgreich erstellt ($file)'");

return 1;
}

return 0;
}




1;


Hat jemand eine Idee?

DS_Starter

#1904
Schalte dir mal verbose 4 im Device ein.
Im Log siehst du dann was ausgeführt werden soll(te):

2023.02.08 11:39:31.074 4: DbRep Rep.CPU - execute command after averageValue: '{afterdump ('Rep.CPU')}'
2023.02.08 11:39:31.074 3: DbRep Rep.CPU -> Dump beendet

In meiner 99_myUtils.pm steht zum Test:


######################################################
########    Nach Dump 
######################################################
sub afterdump {
my ($name) = @_;
my $hash = $defs{$name};

  Log3($name, 3, "DbRep $name -> Dump beendet");

return;
}
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter