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

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

Vorheriges Thema - Nächstes Thema

JoeALLb

leider bekome ich beim Backup immer ein timeout. mal nach 200MB, mal nach 400MB, selbst, wenn ich das Timeout auf 9000
setze und die Zeilen reduziere. (nach ca. 2-3 Stunden)

Wenn ich aus mysql heraus direkt eine CSV-Datei schreibe, ist dieses Backup mit 2,8GB nach ca. 15 Minuten beendet.(Aber MySQL blockiert natürlich in dieser Zeit)

Dazu nutze ich im Moment diese beiden Devices, um es auch elegant verwalten zu können.
Im Moment habe ich noch keinen Ansatz zum debuggen, wo genau das Problem herrscht.

defmod mySqlBackup_DI DOIF ([[00:10]])\
({fhem("set dbrepBackup sqlCmd ".AttrVal("dbrepBackup","sqlExport",""))})\


und

defmod dbrepBackup DbRep myDbLogSQL
attr dbrepBackup userattr sqlExport
attr dbrepBackup dumpDir /mnt/usbstick
attr dbrepBackup dumpFilesKeep 5
attr dbrepBackup dumpMemlimit 10000
attr dbrepBackup dumpSpeed 1000
attr dbrepBackup sqlExport SELECT *\
FROM history\
INTO OUTFILE '/mnt/usbstick/fhemDB.bak.csv'\
FIELDS TERMINATED BY ','\
ENCLOSED BY '"'\
LINES TERMINATED BY '\n';;
attr dbrepBackup timeout 5000
attr dbrepBackup widgetOverride sqlExport:textField-long



imLog habe ich nur diesen Eintrag gefunden:

2017.06.06 10:02:01 1: Timeout for mysql_DoDump reached, terminated process 20411


Nachtrag1: in diesem Beispiel aktualisiert dbrepBackup den Status nicht zurück von "running" auf etwas anderem.
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

DS_Starter

Hi Joe,

Der dumpSpeed ist einfach zu gering bzw. dauert zu lange. Ich habe ihn bei mir auf 1000000 gesetzt und dumpMemlimit ebenfalls höher, mindestens 10 x dumpSpeed. Bei mir 100 x dumpSpeed. Damit sind meine 1,5 GB plus Views in 160s durch. Bei dir werden nur 1000 Db-Zeilen pro Select gelesen.

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

JoeALLb

Hallo Heiko,

Du hast halt Monster-Hardware ;-)
Wie gesagt, ich teste (bewußt) auf einem langsamen RPI1.

Da ich auf das Timeout gestoßen bin, habe ich angefangen, die Werte zu reduzieren.
Aktuell, mit den größeren Werten läuft es bisher seit einer Stunde problemlos.

Ich warte noch auf das Endergebnis und melde mich.


sG
Joe
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

JoeALLb

Leider finde ich keine Einstellungen, mit denen das Backup auf dieser Hardware durchläuft.
2 Stunden und 500MB war bisher das maximum.
Ich verstehe aber auch noch nicht ganz, wie es zu dem timeout kommt.
Wenn ich die MySQL-Prozesse beobachte, wird immer schön eine Anfrage nach der anderen an MySQL übergeben, die Antwortzeiten sind dabei sehr schnell.
Leider hatte ich bisher zum Fehlerzeitpunkt noch nie einen Blick in der MySQL-Prozessliste...

Auf etwas schnellerer Hardware konnte ich das Backup jedoch problemlos erstellen!

sG
Joe
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

DS_Starter

Morgen Joe,

Vermutlich muss man als Anwender für eine derartige Applikation eben auch angemessene Hardware einsetzen um akzeptabel damit arbeiten zu können. Wenn es nicht so wäre könnte man ein SAP-System auch auf einem Handy laufen lassen.  ;). Für zu schwache Client-Hardware muss man wahrscheinlich auf einer Server gestützte Variante ausweichen, so wie du es oben gezeigt hast.
Was man noch machen könnte, ist ohne Timeout zu arbeiten. Hatte ich bisher nicht gemacht damit die Prozesse nicht ewig rumliegen. Ich habe die Zeile jetzt nicht vor mir, ist aber am Anfang von DbRep_Main. Dort nur den BlockingCall etwas kürzen. Wie genau, steht im Wiki zu BlockingCall.
Aber wenn es derart lange auf dieser Hardware dauert macht es nicht wirklich Freude.

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

JoeALLb

Ich habe auch nicht UNBEDINGT die Notwendigkeit dafür...
Mir stellt sich nur die Frage, ob man meine Systemvariante von oben im Modul unterstützen könnte.
Dann kann man zwar für ca. 15 Minuten nichts in die DB inserten, aber das könnte man ja anderwertig lösen, indem man zB
set SQL reopen 900 (oder ähnliches) absetzt. (und natürlich den asynchronen Modus nutzt).
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

DS_Starter

#426
Na hast du doch schon mit dem Modul gelöst  ;)

Also ich denke man könnte so etwas unterstützen. Ist auch technisch nicht so das Problem.
Ein bisschen schwierig ist es m.M. dem Anwender die unterschiedlichen implementierten Varianten verständlich zu erläutern und voneinander abzugrenzen, welche Attribute nun ziehen usw. Das klappt dann auch nicht mit einer uniformen Recoverylösung an der ich gerade bastele.
Aber ich denk Mal mit darüber nach. Du könntest deine Lösung doch im Wiki zu DbRep Mal hinterlegen als Server seitige Variante, findest du nicht ?   8)

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

DS_Starter

#427
Hi Joe, @all,

jetzt habe ich das Modul V.5.0.3 noch um eine serverseitige Dumpmöglichkeit mit "LOAD INTO FILE ..." ergänzt.
Dadurch ändern sich die Aufrufparameter von dumpMySQL. Wird nichts angegeben, wird "clientSite" ausgeführt.

Hier der Abriß:

dumpMySQL [clientSite | serverSite] - erstellt einen Dump der angeschlossenen MySQL-Datenbank.
Abhängig von der ausgewählten Option wird der Dump auf der Client- bzw. Serverseite erstellt.

clientSite
Der Dump wird durch den Client erstellt und per default im log-Verzeichnis des Clients gespeichert. Das Zielverzeichnis kann mit dem Attribut "dumpDir" verändert werden und muß auf dem Client durch FHEM beschreibbar sein. Vor dem Dump kann eine Tabellenoptimierung optional zugeschaltet werden. Über weitere Attribute kann das Laufzeitverhalten der Funktion beeinflusst werden um eine Optimierung bezüglich Performance und Ressourcenbedarf im zu erreichen.
Die für "dumpMySQL clientSite" relevanten Attribute sind "dumpComment", "dumpDir", "dumpMemlimit", "dumpSpeed ", "dumpFilesKeep" und "optimizeTablesBeforeDump".

Die Namenskonvention des Dumpfiles ist: <dbname>_<date>_<time>.sql

Das erzeugte Dumpfile kann z.B. mit:

    mysql -u <user> -p <dbname> < <filename>.sql

auf dem MySQL-Server ausgeführt werden um die Datenbank aus dem Dump wiederherzustellen.

serverSite
Der Dump wird durch den MySQL-Server erstellt und per default im Home-Verzeichnis des MySQL-Servers gespeichert. Es wird die gesamte history-Tabelle (nicht current-Tabelle) im CSV-Format ohne Einschränkungen exportiert.
Das Zielverzeichnis kann mit dem Attribut "dumpDir" verändert werden. Es muß sich auf dem MySQL-Host gefinden und durch den MySQL-Serverprozess beschreibbar sein.
Der verwendete Datenbankuser benötigt das "FILE"-Privileg.
Die Versionsverwaltung der erzeugten Exportfiles muß der Anwender durch geeignete Maßnahmen selbst übernehmen.

Die Namenskonvention des Dumpfiles ist: <dbname>_<date>_<time>.csv

Mit der serverseitigen Variante ist mein Backup in 42s durch (auf Synology).  :D (Naja, ist nun nur noch die history-Tabelle).
Damit hat man als User eigentlich alle Entscheidungsfreiheiten. Die Varianten unterscheiden sich ja auch hinsichtlich ihres Umfanges/Ergebnisses.

Schau mal ...

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

JoeALLb

Hallo Heiko,

das Backup funktioniert toll, herzlichen dank dafür!

Durch die Integration bekomme ich auch besser mit, wann das Backup fertig ist, was eine tolle Sache ist.

Folgendes ist mir aufgefallen:
1. Cancel Dump funktioniert nicht, es läuft einfach weiter (was mich nich tbesonders stört, ist halt aufgefallen).
2. sollte serverSite nicht serverSide heißen?
3.
Die Versionsverwaltung der erzeugten Exportfiles muß der Anwender durch geeignete Maßnahmen selbst übernehmen.
Das finde ich schade... würde hier nicht der selbe code greifen wie beim clientseitigen backup? Aus Speicherplatzgründen muss ich das Backup auf 3 files beschränken.

Einen Wunsch hätte ich nocht: können wir ein Attribut ähnlich wie "execute_before" und "execute_after" erlauben? dann könnte ich darüber
aufräumarbeiten machen und/oder anschließend eine Telegram-Nachricht zur Bestätigung verschicken.
Im Moment mache ich das einfach im aufrufenden DOIF, was auch funktioniert. Ich darf nur den Befehl
set dbRep dumpMySQL  serversite nicht direkt ausführen, da dann meine synology noch nicht gestartet ist (WOL) und das Zielverzeichnis somit noch nicht zur Verfügung steht.

Ein Traum wäre, dumpFilesKeep zu berechnen über den aktuell freien Speicherplatz (am usb-stick) unter zuhilfenahme der größe des letzten Backups plus einem Buffer von xMB's,
aber vermutlich ist das aktuell auch besser in einem aufrufenden Script oder eben in "execute_before" abzudecken...

schöne Grüße
Joe
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

DS_Starter

#429
Hi Joe,

Ja klar, cancelDump funktioniert nicht, weil einmal auf dem Server angstossen läuft es halt los. Muss ich rausnehmen.

Side ist natürlich richtig, das ändere ich ab.

Bezüglich der Versionsverwaltung klappt derselbe Code nur wenn du das Serververzeichnis auf dem Client gemountet hast und der dann auch so wie auf den Server heißt. Sonst braucht es ein weiteres Attribut um das zu steuern. Wie ich sagte ...  es wird immer komplexer.

Das mit den execution before und after ist eine tolle Idee, Versuche ich Mal mit vorzusehen.

Wenn dir / euch bezüglich der Versionsverwaltung auf serverSide etwas brauchbares einfällt gerne als Zuarbeit ....

VG
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

JoeALLb

Zitat von: DS_Starter am 08 Juni 2017, 10:43:42
Ja klar, cancelDump funktioniert nicht, weil einmal auf dem Server angstossen läuft es halt los. Muss ich rausnehmen.
Man könnte den Prozess killen, indem man sich die ProzessID merkt, aber ich denke, darauf kann verzichtet werden.


Zitat von: DS_Starter am 08 Juni 2017, 10:43:42
Wenn dir / euch bezüglich der Versionsverwaltung auf serverSide etwas brauchbares einfällt gerne als Zuarbeit ....

Bei mir ist es am selben Server, weswegen die Bereinigung auch funktionieren würde.
Im Moment finde ich es eher verwirrend, dass es angeboten wird, dann aber nicht funktioniert. Auf die Begründung mit dem externen Server bin ich von selbst nicht gekommen.
Idee: Es einfach zu versuchen, die Datei zu löschen. Wenns sie nicht da ist, eine Fehlermeldung in ein Reading. Dann gibts auch keine Rückfragen über "dumpFilesKeep funktioniert nicht"

sG
Joe
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

DS_Starter

#431
Hallo zusammen,

jetzt hab eich noch einiges in der V5.0.4 geändert.
Auch die Attribute haben sich geändert und erweitert damit nun auch die Versionsverwaltung für servierSide Backups funktioniert.
Es können auch Kommandos vor/nach dem Backup ausgeführt werden.

Bitte lest die geänderte Doku:

dumpMySQL [clientSide | serverSide]
- erstellt einen Dump der angeschlossenen MySQL-Datenbank.
Abhängig von der ausgewählten Option wird der Dump auf der Client- bzw. Serverseite erstellt.
Die Varianten unterscheiden sich hinsichtlich des ausführenden Systems, des Erstellungsortes, der Attributverwendung und des erzielten Ergebnisses.

clientSide
Der Dump wird durch den Client (FHEM-Rechner) erstellt und per default im log-Verzeichnis des Clients gespeichert. Das Zielverzeichnis kann mit dem Attribut "dumpDirLocal" verändert werden und muß auf dem Client durch FHEM beschreibbar sein.
Vor dem Dump kann eine Tabellenoptimierung ("optimizeTablesBeforeDump") oder ein FHEM-Kommando ("executeBeforeDump") optional zugeschaltet werden .
Nach dem Dump kann ebenfalls ein FHEM-Kommando (siehe "executeAfterDump") ausgeführt werden.
Über weitere Attribute kann das Laufzeitverhalten der Funktion beeinflusst werden um eine Optimierung bezüglich Performance und Ressourcenbedarf zu erreichen.
Die für "dumpMySQL clientSide" relevanten Attribute sind "dumpComment", "dumpDirLocal", "dumpMemlimit", "dumpSpeed ", "dumpFilesKeep", "executeBeforeDump", "executeAfterDump" und "optimizeTablesBeforeDump".
Nach einem erfolgreichen Dump werden alte Dumpfiles gelöscht und nur die Anzahl "dumpFilesKeep" (default: 3) verbleibt im Zielverzeichnis "dumpDirLocal".

Die Namenskonvention der Dumpfiles ist: <dbname>_<date>_<time>.sql

Das erzeugte Dumpfile kann z.B. mit:

    mysql -u <user> -p <dbname> < <filename>.sql

auf dem MySQL-Server ausgeführt werden um die Datenbank aus dem Dump wiederherzustellen.

serverSide
Der Dump wird durch den MySQL-Server erstellt und per default im Home-Verzeichnis des MySQL-Servers gespeichert.
Es wird die gesamte history-Tabelle (nicht current-Tabelle) im CSV-Format ohne Einschränkungen exportiert.
Die für "dumpMySQL serverSide" relevanten Attribute sind "dumpDirRemote", "dumpFilesKeep", "executeBeforeDump", "executeAfterDump" und "dumpDirLocal".
Vor und nach dem Dump kann ein FHEM-Kommando (siehe "executeBeforeDump", "executeAfterDump") ausgeführt werden.

Das Zielverzeichnis kann mit dem Attribut "dumpDirRemote" verändert werden. Es muß sich auf dem MySQL-Host gefinden und durch den MySQL-Serverprozess beschreibbar sein.
Der verwendete Datenbankuser benötigt das "FILE"-Privileg.
Soll die interne Versionsverwaltung des Moduls genutzt werden, ist das Verzeichnis "dumpDirRemote" des MySQL-Servers auf dem Client zu mounten und im Attribut "dumpDirLocal" dem DbRep-Device bekannt zu machen.

    Beispiel:
    attr <DbRep-device> dumpDirRemote /volume1/ApplicationBackup/dumps_FHEM/
    attr <DbRep-device> dumpDirLocal /sds1/backup/dumps_FHEM/
    attr <DbRep-device> dumpFilesKeep 2
    # Der Dump wird remote auf dem MySQL-Server im Verzeichnis '/volume1/ApplicationBackup/dumps_FHEM/' erstellt.
    # Die interne Versionsverwaltung sucht im lokal gemounteten Verzeichnis '/sds1/backup/dumps_FHEM/' vorhandene Dumpfiles und löscht diese bis auf die zwei letzten Versionen.

Wird die interne Versionsverwaltung genutzt, werden nach einem erfolgreichen Dump alte Dumpfiles gelöscht und nur die Anzahl "dumpFilesKeep" (default: 3) verbleibt im Zielverzeichnis "dumpDirRemote". FHEM benötigt in diesem Fall Schreibrechte auf dem Verzeichnis "dumpDirLocal".

Die Namenskonvention der Dumpfiles ist: <dbname>_<date>_<time>.csv

EDIT: hier noch etwas zu den Attributen.

executeAfterDump - Es kann ein FHEM-Kommando angegeben werden welches nach dem Dump ausgeführt werden soll.
Funktionen sind in {} einzuschließen.

    Beispiel:

    attr <DbRep-device> executeAfterDump set og_gz_westfenster off;
    attr <DbRep-device> executeAfterDump {adump ("<DbRep-device>")}
    # "adump" ist eine in 99_myUtils definierte Funktion.



executeBeforeDump - Es kann ein FHEM-Kommando angegeben werden welches vor dem Dump ausgeführt werden soll.
Funktionen sind in {} einzuschließen.

    Beispiel:

    attr <DbRep-device> executeBeforeDump set og_gz_westfenster on;
    attr <DbRep-device> executeBeforeDump {bdump ("<DbRep-device>")}
    # "bdump" ist eine in 99_myUtils definierte Funktion.

dumpDirLocal - Zielverzeichnis für die Erstellung von Dumps mit "dumpMySQL clientSide". default: "{global}{modpath}/log/" auf dem FHEM-Server.

dumpDirRemote - Zielverzeichnis für die Erstellung von Dumps mit "dumpMySQL serverSide". default: das Home-Dir des MySQL-Servers auf dem MySQL-Host
--------------

Probierts mal bitte wieder aus und Feedback wie immer gerne.

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

DS_Starter

#432
Noch ein kleiner Tipp.
Für die Benachrichtigung nach einem Backup eignet sich die userExitFn besser als eine Funktion mit "executeAfterDump".
Der Grund liegt darin, dass man den mit der userExitFn auch den Status der ausgeführten "executeAfterDump"-Funktion mit erhält.

Es ist einfach zu realisieren. Einfach in dem DbRep-Device, welches man für das Backup benutzt das Attribut:

attr <Device > userExitFn doafterdump

setzen. "doafterdump" ist eine Funktion die man in der 99_myUtils.pm definiert hat.
Beispielsweise so:


############################################################################################################
########       Aktion nach einem Backup     
############################################################################################################
sub doafterdump {
my ($name,$reading,$value) = @_;
my $hash   = $defs{$name};
my $dbname = $hash->{DATABASE};

if ($name =~ m/Rep.Fhem.*Dump/) {
   if ($reading = "state" && ReadingsVal($name,"state",'') =~ m/Database.*backup.*finished/) {
        my $dev = 'Device: '.$name.'\n';
        my $dfc = 'DumpFileCreated: '.ReadingsVal($name, "DumpFileCreated", '').'\n';
        my $dfd = 'DumpFilesDeleted: '.ReadingsVal($name, "DumpFilesDeleted", '').'\n';
my $rc  = 'DumpRowsCurrrent: '.ReadingsVal($name, "DumpRowsCurrrent", '').'\n';
my $rh  = 'DumpRowsHistory: '.ReadingsVal($name, "DumpRowsHistory", '').'\n';
my $bt  = 'Laufzeit: '.sprintf("%.0f",ReadingsVal($name, "background_processing_time", '')).' Sekunden\n';
        my $dfs = 'Status: '.ReadingsVal($name, "state", '').'\n';

        DebianMailnbl('<Empfänger>',
        'Dump '.$dbname.' beendet', 'Datenbank Dump ist beendet:\n\n'.$dev.$dfc.$dfd.$rc.$rh.$bt.$dfs.'\n\\nFHEM-Server' );
   }
}

return;
}


DebianMailnbl ist wiederum eine selbst definierte Funktion die einen Mailversand non-blocking vornimmt. Aber das Ganze soll nur als Anregung und Beispiel dienen. Man kann dort natürlich beliebige Funktionen hinterlegen.
Der Regex "$name =~ m/Rep.Fhem.*Dump/" filtert die Funktion für Nur-Dump-DbRep-Devices. Kann auch entfallen sofern die userExitFn ohnehin nur in diesen DbRep-Devs aktiviert ist.

Die empfangene Email sieht dann so aus wie im Anhang.

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

JoeALLb

Hallo Heiko,

kannst Du etwas aus dieser Fehlermeldung lesen?
Too many arguments for main::deldumpfiles at ./FHEM/93_DbRep.pm line 4500, near "$bfile)"
BEGIN not safe after errors--compilation aborted at ./FHEM/93_DbRep.pm line 4876.

Ich würde davon ausgehen, dass ich irgendein Attribut löschen sollte, aber welches?

Auch bei einem neuen (leeren) Device bekomme ich diesen Fehler.

sG
Joe
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

DS_Starter

Morgen Joe,

da hat sich etwas in der Struktur des Codes geändert. Wenn du so etwas liest, egal welches Modul -> immer restart. Das sollte dieses Problem lösen.

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