Hi,
ich hatte heute einige Ausfälle der Verbindung zu dem host wo die Datenbank läuft...
Damit gibt es dann im DbLog Device state-reading Einträge die direkt aus dem DBI Modul stammen...
Nachdem das Problem einige Zeit gedauert hat, hat das cacheOverflowThreshold zugeschlagen und einen cache-file erzeugt....
soweit alles OK!
Ich habe dann versucht, den cache file mittels importCachefile wieder einzulesen und hab "komische" Fehlermeldungen bekommen:
2022.01.09 18:24:13.092 2: DbLog CL_DbLog -> Error table history - DBD::mysql::st execute failed: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'database=fhem;host=192.168.5.13;port=3306','fhemuser',...) failed: Can't connect' at line 1 at ./FHEM/93_DbLog.pm line 1921.
Die Verbindung zur DB war allerdings zu dem zeitpunkt OK und es wurden auch akutelle Events geloggt.....
Nähere Betrachtung des cache-files ergab dann folgendes:
das ist die Zeile, die den gesamten import verhindert:
2022-01-09 12:47:52|myDbLog|DBLOG|state: DBI connect('database=fhem;host=192.168.5.13;port=3306','fhemuser',...) failed: Can't connect to MySQL server on '192.168.5.13' (110) at ./FHEM/93_DbLog.pm line 2539.
|state|DBI connect('database=fhem;host=192.168.5.13;port=3306','fhemuser',...) failed: Can't connect to MySQL server on '192.168.5.13' |
... offensichtlich ist da ein LF drin!!!
Nach löschen dieser Zeile(n) , funktioniert der import .....
Damit die Sache komplett ist, ein list vom DbLog device:
Internals:
.FhemMetaInternals 1
COLUMNS field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
CONFIGURATION ./fhem_cldb.cfg
DEF ./fhem_cldb.cfg .*:.*
FUUID 5c7ceaf9-f33f-5c4d-3dd8-e4f0c81d772a9ed6
FVERSION 93_DbLog.pm:v4.12.5-s25394/2021-12-31
MODE asynchronous
MODEL MYSQL
NAME myDbLog
NR 25
NTFY_ORDER 50-myDbLog
PID 11369
REGEXP .*:.*
STATE connected
TYPE DbLog
UTF8 1
dbconn mysql:database=fhem;host=192.168.5.13;port=3306
dbuser fhemuser
.attraggr:
.attrminint:
HELPER:
COLSET 1
DEVICECOL 64
EVENTCOL 512
OLDSTATE connected
PACKAGE main
READINGCOL 64
TC current
TH history
TYPECOL 64
UNITCOL 32
VALUECOL 128
VERSION 4.12.5
Helper:
DBLOG:
CacheOverflowLastNum:
myDbLog:
TIME 1641751255.55069
VALUE 0
CacheUsage:
myDbLog:
TIME 1641752096.03646
VALUE 35
background_processing_time:
myDbLog:
TIME 1641752096.45914
VALUE 0.3170
lastCachefile:
myDbLog:
sql_processing_time:
myDbLog:
TIME 1641752096.45914
VALUE 0.1231
state:
myDbLog:
TIME 1641747172.94993
VALUE connected
READINGS:
2022-01-09 19:14:56 CacheOverflowLastNum 0
2022-01-09 14:52:24 CacheOverflowLastState normal
2022-01-09 19:16:18 CacheUsage 12
2022-01-09 19:14:56 NextSync 2022-01-09 19:16:56 or if CacheUsage 200 reached
2022-01-09 19:14:56 background_processing_time 0.3170
2021-08-30 11:55:12 countCurrent 62
2021-08-30 11:55:12 countHistory 19468961
2022-01-09 17:02:24 lastCachefile ./log/cache_myDbLog_2022-01-09_13-48-27 - Error -
2017-03-02 16:39:36 lastRowsDeleted 96882
2019-01-30 10:14:01 reduceLogState DBD::mysql::st execute failed: Error writing file '/tmp/MYMZePMF' (Errcode: 28) at ./FHEM/93_DbLog.pm line 4291.
2022-01-09 19:14:56 sql_processing_time 0.1231
2022-01-09 19:14:56 state connected
helper:
bm:
DbLog_Get:
cnt 1
dmx -1000
dtot 0
dtotcnt 0
mTS 09.01. 18:02:50
max 4.50611114501953e-05
tot 4.50611114501953e-05
mAr:
HASH(myDbLog)
myDbLog
?
DbLog_Log:
cnt 2003
dmx -1000
dtot 0
dtotcnt 0
mTS 09.01. 17:28:51
max 0.0324709415435791
tot 7.84952855110168
mAr:
HASH(myDbLog)
HASH(myAstro)
DbLog_Set:
cnt 316
dmx -1000
dtot 0
dtotcnt 0
mTS 09.01. 18:04:52
max 0.00221109390258789
tot 0.521650791168213
mAr:
HASH(myDbLog)
myDbLog
?
Attributes:
DbLogExclude NextSync,last.*,reduce.*,.*:1800
DbLogSelectionMode Exclude/Include
DbLogType History
addStateEvent 1
asyncMode 1
bulkInsert 1
cacheEvents 2
cacheLimit 200
cacheOverflowThreshold 1000
excludeDevs global
room Global
showNotifyTime 0
showproctime 1
syncInterval 120
timeout 86400
das ist ein sicherlich ein nicht dringendes Problem, evtl. könnte man die Error-msg so umbauen, das kein LF vorkommt....
l.g. erwin
Hallo erwin,
ich versuche es im Hinterkopf zu behalten wenn ich mich mal wieder mit DbLog befasse.
Der LF kommt sehr wahrscheinlich aus dem DBI weil ich ihn nicht hinzufüge im Event.
Ich würde allerdings generell den state des DbLog-Devices selbst nicht mitloggen:
excludeDevs global,myDbLog:state
Bzw. die myDbLog Events generell nicht.
LG,
Heiko
Hallo Heiko,
ZitatIch würde allerdings generell den state des DbLog-Devices selbst nicht mitloggen
stimmt, das würde das problem umgehen... kommt man erst drauf, wenns probleme gibt...
Das ganze ist wie schon geschrieben nicht wirklich dringend/relevant - kommt hoffentlich nicht oft vor!
Danke erwin