DBLog läuft nach update der mariaDB auf Syno NAS nicht mehr.

[der-Lolo]

Ok, das wars...

ein aktueller configCheck:

Code Auswählen Erweitern

Result of DbLog version check

Used DbLog version: 3.13.0
Recommendation: Your running version may be the current one. Please check for updates of DbLog periodically.

Result of configuration read check

Connection parameter store type: file
Connection parameter: Connection -> mysql:database=fhem;host=127.0.0.1;port=3307, User -> fhem, Password -> read o.k.

Result of connection check

Connection to database fhem successfully done.
Recommendation: settings o.k.

Result of encoding check

Encoding used by Client (connection): UTF8
Encoding used by DB fhem: UTF8
Recommendation: settings o.k.

Result of logmode check

Logmode of DbLog-device DbLog is: asynchronous
Recommendation: settings o.k.

Result of shutdown sequence preparation check

Attribute "shutdownWait" is set to:
Recommendation: Due to Reading "background_processing_time" is not available (you may set attribute "showproctime"), there is only a rough estimate to
set attribute "shutdownWait" to 2 seconds.


Result of plot generation method check

WARNING - at least one of your FHEMWEB devices have attribute "plotfork = 1" not set. This may cause blocking situations when creating plots.
WEB: plotfork=1
WEBphone: plotfork=0
WEBtablet: plotfork=0
WEBweatherstation: plotfork=0
Recommendation: You should set attribute "plotfork = 1" in relevant devices

Result of table 'history' check

Column width set in DB fhem.history: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Column width used by DbLog: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: settings o.k.

Result of table 'current' check

Column width set in DB fhem.current: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Column width used by DbLog: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: settings o.k.

Result of check 'Search_Idx' availability

Index 'Search_Idx' exists and contains recommended fields 'DEVICE', 'READING', 'TIMESTAMP'.
Recommendation: settings o.k.

Result of check 'Report_Idx' availability for DbRep-devices

At least one DbRep-device assigned to DbLog is used. Index 'Report_Idx' exists and contains recommended fields 'TIMESTAMP', 'READING'.
Recommendation: settings o.k.

[DS_Starter]

ok. jetzt schauen wir wieder nach eventuell fehlerhaften Sätzen die gemeldet werden ...

[der-Lolo]

Alles klar, nochmals vielen Dank für Deine hilfe...
Vielleicht kannst Du mir noch auf die sprünge helfen mit den Daten grundsätzlich - so eine hohe auflösung wie ich aktuell Logge brauche ich nach 24h eigentlich nicht mehr... Wenn also ein Tag vorbei ist könnte ich auf viele Einträge verzichten - ich denke alle 5 minuten ein Eintrag reicht mir.

Dazu ist ja eigentlich DbRep gedacht, oder? Ich hab DbRep glaube ich noch nicht so richtig verstanden.
Wie kann ich die History "ausdünnen"?

[DS_Starter]

DbRep ist ein Werkzeugkoffer für die verschiedensten Anwendungen, so auch für das Löschen von Daten, zur Auswertung und tabellarischer Zusammenfassung von Werten, Backup und Restore, Datenexport, Infosystem zu DB-Variablen, Datenbanksynchronisation und etliches mehr.
Die Vorgehensweise ist so, dass man sich für sein vorhandenes Problem eine passende Funktion im DbRep sucht und das erstellte Device über die vielen möglichen Attribute nach seinen Bedürfnissen einstellt und die Funktion dann (regelmäßig) laufen lässt.

Für deine Anforderung gibt es verschiedene Möglichkeiten.
Zunächst vorhandene Dubletten löschen. Die hast du wahrscheinlich weil kein PK vorhanden ist.
Wenn du im DbRep die Attr so setzt :

Code Auswählen Erweitern


timeDiffToNow = d:10
timeOlderThan = d:1


werden für die nachfolgenden Kommandos alles was älter als 1 Tag und neuer als 10 Tage ist, betrachtet.

Code Auswählen Erweitern

set ... delDoublets adviceDelete

zeigt dir erstmal wieviel gelöscht werden würde. Mit "set delDoublets delete" wirfst du sie dann weg.

Dann gibt es

Code Auswählen Erweitern

set ... delSeqDoublets ...

Das löscht auf spezielle Art und Weise Daten die noemalerweise logisch nicht benötigt werden, Wie genau das wirkt ist in der commandref ziemlich ausführlich dargestellt. Das können wir uns anschauen wenn du eine konkrete Anforderung hast.

Und es gibt noch das

Code Auswählen Erweitern


set  ... reduceLog


Ohne weiteren Zusatz behältst du immer den ersten Eintrag pro Stunde je Device & Reading.

Edit: Es gibt auch im Wiki etliche Beispiele die ich immer wieder erweitere wenn es meine Zeit erlaubt.

[der-Lolo]

Guten Morgen Heiko,
nach anpassung der Feldgrößen innerhalb der DB verhält sich die Datenbank wieder unauffällig - läuft nun seit etwas mehr als 24Std. ohne weitere fehlereinträge im Log. Tausend Dank für Deine Hilfe!
Ich werde die nächsten Tage dazu nutzen das Logging einzuschränken sodass der Datenwust nicht zu groß wird, sinnvolle Daten aber behalten werden.
Hier komme ich mit Sicherheit noch mit der ein oder anderen frage

[DS_Starter]

Na das hört sich doch gut an. 
Lösche bitte das Attribut commitMode wieder. Das ist für den Support bzw. diesen Fehlerfall gut und hilfreich. Hat aber evtl. Nachteile für den normalen Betrieb.
Hab dich gerne unterstützt und war ja auch ein interessanter Fall.

Grüße,
Heiko