[Gelöst] DBLog zerschossen mit addlog ?

Begonnen von Jewe, 13 Januar 2018, 22:41:33

Vorheriges Thema - Nächstes Thema

Jewe

Die DB ist auf der SD-Karte im Raspi.

DS_Starter

ZitatDie DB ist auf der SD-Karte im Raspi.
So wie üblich.
SD-Karten sind allgemein nicht für so viele Schreibzyklen gebaut. Wenn sie ein entsprechendes Alter haben (bzw. genügend viele Schreibzyklen erlebt haben) steigen sie gern mal aus. Habe ich hier im Forum schon oft gelesen.
Das muss bei dir aber nicht der Fall sein, sondern könnte nur einen möglichen Grund darstellen.

Melde dich einfach wieder, falls der Fehler wieder auftritt. Versuch dann einen Zusammenhang zu finden, z.B. ob der Fehler vielleicht auftritt wenn besonders viele Schreibvorgänge in die DB stattfinden sollen. Das Addlog wäre wohl so ein Fall, kann aber auch sonst vorkommen. Dein System kennst nur du und wieviele Events vorkommen/geloggt werden sollen.

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

Jewe

Hallo Heiko,

ich beobachte meine DBLog nun eine weile. Und es funktioniert soweit ganz gut. Will heissen, dass das Backup funktioniert, die Logs geschrieben werden, die Plots funktionieren und der Addlog auch.

Heute wollte ich mir die Datenbankeinträge anschauen und es gibt keine Tabelle History.

.tables und .scheme zeigt nichts an.

vmtl. wieder korrupt ?

Jens

DS_Starter

Hi Jens,

Zitat
.tables und .scheme zeigt nichts an.

vmtl. wieder korrupt ?

sieht so aus. Backup der DB zurückspielen ...  und wahrscheinlich mal an den Austausch der SD-Karte in Erwägung ziehen.

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

Deckoffizier

Hallo Jens,

falls Du einen Raspi 3 hast versuch doch mal ihn mit SD Karte nur zum booten zu betreiben der Rest auf USB Stick, so war es lange Zeit bei mir bevor ich auf einen
"richtigen" Server umgestiegen bin.
Kodi als Mediacenter am Fernseher  läuft bei mir auf einem PI3 komplett ohne SD Karte ob es soweit auch mit FHEM klappt kann ich Dir leider nicht sagen.

Gruß
Hans-Jüergen
FHEM 5.8 auf "yakkaroo Emu A1FL.1" mit CUL 868MHz, SIGNALduino,2 1Wire USB Busmaster, diverse 1 Wire Sensoren,Landroid,Aeotec USB Dongle Z-Wave Plus

Jewe

Zitat von: DS_Starter am 29 Januar 2018, 10:43:28
sieht so aus. Backup der DB zurückspielen ...  und wahrscheinlich mal an den Austausch der SD-Karte in Erwägung ziehen.

Gestern hatte ich das Backup zurückgespielt, aber das ist auch schon korrupt. :-( Habe es ist so eingestellt, dass 3 Backups gib)
Leider habe ich es erst später mitbekommen.
Irgendwie ist das etwas doof, so wie es bei mir ist....

Ja die SD-Karte... Die ist gerade mal ein halbes Jahr alt und ich habe extra eine Hochwertige Karte gekauft. Die alte Karte hatte ich vorsorglich nach ca. 2,5 Jahren ausgetauscht. Ob ich mit einenm USB-Stick wirklich besser dran bin ?

Mit meinen Logfiles hatte ich eigentlich weniger Probleme, ausser dass es langsamer ist .

Jens

DS_Starter

Morgen Jens,

ja,schön ist es nicht und es gibt momentan auch nichts wozu ich dir raten könnte.
Damit wir nochmal auf dem aktuellen Info-Stand sind, mach bitte einen aktuellen "set ... configCheck" und poste es.

Du hast geschrieben, alles funktioniert eigentlich einwandfrei bis zu dem Zeitpunkt an dem du einen Blick in die DB wirfst.
Da auch die Plots bis zu diesem Zeitpunkt funktionieren, klappt auch das Lesen aus der DB bis dahin einwandfrei.
Wie schaust du denn in die DB ? Gibt es da eventuell einen Zusammenhang dass die Korruption durch diesen Vorgang erst verursacht wird ?
Reine Mutmaßung und nur ein Denkanstoß, aber irgendiwe eigentümlich dieser Zusammenhang.

Mit meinen Logfiles hatte ich eigentlich weniger Probleme, ausser dass es langsamer ist .
Eine DB ist kein Allheilmittel. Ich würde das nehmen mit dem ich mich wohler fühle und was mir bei der Erfüllung meiner Ziele hilft.  ;)

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

Jewe

Hallo Heiko,

naja ich mache eine Verbingung mit Putty und öffne dann die Datenbank
sudo sqlite3 fhem.db

Hier das Ergebnis des ConfigCheck
Result of configuration read check

Connection parameter store type: file
Connection parameter: Connection -> SQLite:dbname=/opt/fhem/fhem.db, User -> , Password -> read o.k.

Result of connection check

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

Result of encoding check

Encoding used by DB /opt/fhem/fhem.db: UTF-8
Recommendation: This is only an information about text encoding used by the main database.

Result of logmode check

Logmode of DbLog-device myDbLog 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 table 'history' check

Column width set in DB /opt/fhem/fhem.db.history: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Column width used by myDbLog: '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 /opt/fhem/fhem.db.current: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Column width used by myDbLog: '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

The index 'Report_Idx' is missing.
Recommendation: You can create the index by executing statement 'CREATE INDEX Report_Idx ON `history` (TIMESTAMP, READING)'
Depending on your database size this command may running a long time.
Please make sure the device 'myDbLog' is operating in asynchronous mode to avoid FHEM from blocking when creating the index.
Note: If you have just created another index which covers the same fields and order as suggested (e.g. a primary key) you don't need to create the 'Search_Idx' as well !



DS_Starter

Hallo Jens,

der check ist ok. Wollte nur nochmal einen aktuellen Überblick.

Kannst du denn den Zusammenhang den ich gemutmaßt habe nachvollziehen ? Soll heißen, solange du nicht versuchst reinzuschauen klappt das alles so wie von die beschrieben, logging, plots und addlog ?

Du kannst den Hinweis von Deckoffizier ruhig mal umsetzen, tut ja nicht weh.

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

Jewe

Ich habe das Problem gefunden. Es sitzt vor dem PC :-)

Ich habe, warum auch immer im Ordner PI eine Datenbank, und die habe ich immer geöffnet. Die richtige Datei liegt natürlich
im Ordner /opt/fhem !

Oh man ich habe DIr  / euch richtig Arbeit gemacht für nichts. Es ist alles in Ordung mit der Datenbank.
Sorry.

Jens

DS_Starter

Ein schöner Single Malt versöhnt  ;)

Du hast doch schon DbRep installiert. Wenn du "set ... fetchrows .." benutzt, kannst du in die DB schauen und erwischt mit Sicherheit auch die richtige  8)

Kannst ja noch "gelöst" in den Titel schreiben.

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

Jewe

Hallo Heiko,

jetzt habe ich doch nochmal ein kleines Problem. Seit dem Abend bevor ich das Problem hatte, dass ich die "falsche" DBLog geöffnet zu habe. werden die Werte meiner LaCrosse Temperaturfühler nicht mehr geloggt. letztes Logging 2018-01-28 20:13:20.
Die Addlogs werden regelmässig geloggt. Habe alles gurchgeschaut, kann den Fehler aber nicht finden.
An der Definition habe ich nichts geändert !?

Help, Jens

myDBLog:
Internals:
   COLUMNS    field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
   CONFIGURATION /opt/fhem/db.conf
   DEF        /opt/fhem/db.conf .*:(temperature|measured-temp|desired-temp|actuator|valveposition|humidity|pressure).*
   MODE       asynchronous
   MODEL      SQLITE
   NAME       myDbLog
   NR         439
   NTFY_ORDER 50-myDbLog
   PID        3879
   REGEXP     .*:(temperature|measured-temp|desired-temp|actuator|valveposition|humidity|pressure).*
   STATE      connected
   TYPE       DbLog
   VERSION    3.8.1
   dbconn     SQLite:dbname=/opt/fhem/fhem.db
   dbuser     
   HELPER:
     COLSET     1
     DEVICECOL  64
     EVENTCOL   512
     OLDSTATE   connected
     READINGCOL 64
     TYPECOL    64
     UNITCOL    32
     VALUECOL   128
   READINGS:
     2018-02-03 11:03:41   CacheUsage      13
     2018-01-17 00:54:45   DbFileSize      66
     2018-02-03 11:03:31   NextSync        2018-02-03 11:04:01 or if CacheUsage 500 reached
     2018-01-14 02:55:00   countCurrent    0
     2018-01-17 00:55:15   countHistory    441323
     2018-01-16 21:52:53   lastCachefile   ./log/cache_myDbLog_2018-01-16_21-52-53 (7 cache rows exported)
     2018-02-01 11:26:46   lastRowsDeleted 460680
     2018-01-17 00:54:45   reduceLogState  reduceLogNbl finished. Rows processed: 19941, deleted: 0, time: 4.92sec
     2018-02-03 11:03:31   state           connected
   cache:
     index      20775
Attributes:
   asyncMode  1
   room       DbLog
   userReadings DbFileSize:reduceLogState.* { (split(' ',`du -m fhem.db`))[0] }


Temperaturfühler :
Internals:
   CHANGED   
   DEF        23
   IODev      myLaCrosseGateway
   LASTInputDev myLaCrosseGateway
   LaCrosse_lastRcv 2018-02-03 11:01:21
   MSGCNT     18978
   NAME       Temp_Wohnen
   NR         513
   STATE      Temperatur: 21.0 °C - Feuchte: 37 %
   TYPE       LaCrosse
   addr       23
   battery_new 0
   corr1      0
   corr2      0
   myLaCrosseGateway_MSGCNT 18996
   myLaCrosseGateway_TIME 2018-02-03 11:01:21
   previousH  37
   previousT  21
   sensorType 0=T(H)
   Helper:
     DBLOG:
       humidity:
         myDbLog:
           TIME       1517612400.01718
           VALUE      36
       temperature:
         myDbLog:
           TIME       1517612400.01718
           VALUE      21.3
   READINGS:
     2018-02-03 11:01:21   battery         ok
     2018-02-03 11:01:21   humidity        37
     2018-02-03 11:01:21   state           T: 21 H: 37
     2018-02-03 11:01:21   temperature     21
Attributes:
   DbLogExclude .*
   IODev      myLaCrosseGateway
   event-aggregator (temperature|humidity):600:linear:mean
   event-on-change-reading .*
   fp_1.OG    90,649,4, ,Wohnen.Temp
   fp_KWL     501,522,4, ,Wohnen.Temp
   group      Temp
   icon       temperature_humidity
   room       Temperaturen
   stateFormat {sprintf("Temperatur: %.1f °C - Feuchte: %d %%", ReadingsVal($name,"temperature",1), ReadingsVal($name,"humidity",1))}

DS_Starter

Hallo Jens,

auf den ersten Blick kann ich auch keinen Fehler in der Konfiguration feststellen.
Da muss man mal einen Blick ins Log werfen.

Setze dir mal Attribute im DbLog:


verbose4Devs Temp_Wohnen
verbose 5


Achte dann auf folgende Log-Einträge:


2018.02.03 12:14:34.001 4: DbLog LogDB -> ################################################################
2018.02.03 12:14:34.003 4: DbLog LogDB -> ###              start of new Logcycle                       ###
2018.02.03 12:14:34.004 4: DbLog LogDB -> ################################################################
2018.02.03 12:14:34.005 4: DbLog LogDB -> number of events received: 5 for device: MySTP_5000
2018.02.03 12:14:34.009 4: DbLog LogDB -> check Device: MySTP_5000 , Event: modulstate: normal
2018.02.03 12:14:34.010 5: DbLog LogDB -> parsed Event: MySTP_5000 , Event: modulstate: normal
2018.02.03 12:14:34.011 4: DbLog LogDB -> check Device: MySTP_5000 , Event: etotal: 18627.84
2018.02.03 12:14:34.012 5: DbLog LogDB -> parsed Event: MySTP_5000 , Event: etotal: 18627.84
2018.02.03 12:14:34.013 4: DbLog LogDB -> added event - Timestamp: 2018-02-03 12:14:34, Device: MySTP_5000, Type: SMAINVERTER, Event: etotal: 18627.84, Reading: etotal, Value: 18627.84, Unit:
2018.02.03 12:14:34.014 4: DbLog LogDB -> check Device: MySTP_5000 , Event: etoday: 3.747
2018.02.03 12:14:34.015 5: DbLog LogDB -> parsed Event: MySTP_5000 , Event: etoday: 3.747
2018.02.03 12:14:34.016 4: DbLog LogDB -> added event - Timestamp: 2018-02-03 12:14:34, Device: MySTP_5000, Type: SMAINVERTER, Event: etoday: 3.747, Reading: etoday, Value: 3.747, Unit:
2018.02.03 12:14:34.016 4: DbLog LogDB -> check Device: MySTP_5000 , Event: total_pac: 0.518
2018.02.03 12:14:34.017 5: DbLog LogDB -> parsed Event: MySTP_5000 , Event: total_pac: 0.518
2018.02.03 12:14:34.018 4: DbLog LogDB -> added event - Timestamp: 2018-02-03 12:14:34, Device: MySTP_5000, Type: SMAINVERTER, Event: total_pac: 0.518, Reading: total_pac, Value: 0.518, Unit:
2018.02.03 12:14:34.019 4: DbLog LogDB -> check Device: MySTP_5000 , Event: 0.518
2018.02.03 12:14:34.020 5: DbLog LogDB -> parsed Event: MySTP_5000 , Event: 0.518
2018.02.03 12:14:34.021 4: DbLog LogDB -> added event - Timestamp: 2018-02-03 12:14:34, Device: MySTP_5000, Type: SMAINVERTER, Event: 0.518, Reading: state, Value: 0.518, Unit:


Das Beispiel ist für Device "MySTP_5000". Deine interressierenden Lacrosse-Events müsen hier auftauchen (parsed Event) und verarbeitet werden (added event).

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

Jewe

Hallo Heiko,

habe die attribute eingetragen. Die Temperaturen kommen an, werden aber nicht geadded.

2018.02.03 16:48:04 4: DbLog myDbLog -> ################################################################
2018.02.03 16:48:04 4: DbLog myDbLog -> ###              start of new Logcycle                       ###
2018.02.03 16:48:04 4: DbLog myDbLog -> ################################################################
2018.02.03 16:48:04 4: DbLog myDbLog -> number of events received: 1 for device: Temp_Wohnen
2018.02.03 16:48:04 4: DbLog myDbLog -> check Device: Temp_Wohnen , Event: state: T: 21.1 H: 37
2018.02.03 16:48:08 4: DbLog myDbLog -> ################################################################
2018.02.03 16:48:08 4: DbLog myDbLog -> ###              start of new Logcycle                       ###
2018.02.03 16:48:08 4: DbLog myDbLog -> ################################################################
2018.02.03 16:48:08 4: DbLog myDbLog -> number of events received: 2 for device: Temp_Wohnen
2018.02.03 16:48:08 4: DbLog myDbLog -> check Device: Temp_Wohnen , Event: temperature: 21.1496426492943
2018.02.03 16:48:08 5: DbLog myDbLog -> parsed Event: Temp_Wohnen , Event: temperature: 21.1496426492943
2018.02.03 16:48:08 4: DbLog myDbLog -> check Device: Temp_Wohnen , Event: state: T: 21.2 H: 37
2018.02.03 16:48:12 4: DbLog myDbLog -> ################################################################
2018.02.03 16:48:12 4: DbLog myDbLog -> ###              start of new Logcycle                       ###
2018.02.03 16:48:12 4: DbLog myDbLog -> ################################################################
2018.02.03 16:48:12 4: DbLog myDbLog -> number of events received: 1 for device: Temp_Wohnen
2018.02.03 16:48:12 4: DbLog myDbLog -> check Device: Temp_Wohnen , Event: state: T: 21.1 H: 37

DS_Starter

Hallo Jens,

wenn die Meldung "parsed Event" kommt, ist der Event schon durch den Regex-Filter durch.
Jetzt habe ich nochmal genauer geschaut. Du hast ja beim Device Temp_Wohnen alles ausgeschlosen -> DbLogExclude = .* !
Da kann ja nichts durchkommen.

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