DBLog - Historische Werte ausdünnen

[dancatt]

Hallo zusammen,

seit einigen Wochen habe ich das Problem dass in der Nacht auf Sonntag sich fhem verabschiedet.
Im Mai 3 mal und im Juni auch schon 4 mal.

Folgendes kommt im Log:
Log 13.06.2021

Code Auswählen Erweitern


2021.06.13 04:02:13.859 1: SONOS0: Last Listener seems to be died and process started by fhem... stopping Threads and process...
2021.06.13 04:02:13.885 0: SONOS0: Das Lauschen auf der Schnittstelle wurde beendet. Prozess endet nun auch...
2021.06.13 04:02:13.966 1: SONOS4: Restore-Thread wurde beendet.


Ich vermute es hängt daran dass ich immer Sonntags um 4 Uhr ein

Code Auswählen Erweitern

set dbLog userCommand VACUUM mache.
Im Device dbLog sehe ich im Reading "userCommand" dass ein VACUMM zuletzt am "2021-05-16 04:00:00" ausgeführt wurde und im Reading "userCommandResult" steht no result.

Folgendes DOIF habe ich:

Code Auswählen Erweitern


defmod doif_dbLog DOIF ([02:00])\
(set dbLog reduceLogNbl 30:32 average)\
(configdb reorg 500)\
DOELSEIF ([03:00])\
(set dbLog reduceLogNbl 90:92 average=day)\
DOELSEIF ([04:00|0])\
(set dbLog userCommand VACUUM)
attr doif_dbLog DbLogExclude .*
attr doif_dbLog do always
attr doif_dbLog group Fhem
attr doif_dbLog room 9_09_Einstellungen
attr doif_dbLog wait 0,1800:0


Mache ich hier was falsch? Hat sich hier was geändert? Das lief nun ein paar Jahre ohne Probleme.

Vielen Dank.

Gruß Daniel

[DS_Starter]

Hallo Daniel,

geändert hat sich in DbLog nichts an irgendwelchen Logiken.

Ein Fehlerhinweis diesbezüglich ist ja auch nicht zu sehen.
Führe  VACUUM doch mal direkt im DbLog aus. Achte auch darauf dass auf deiner Festplatte/SD-Karte genügend Freiplatz ist und nicht volläuft.

Grüße,
Heiko

[dancatt]

Hallo Daniel,

geändert hat sich in DbLog nichts an irgendwelchen Logiken.

Ein Fehlerhinweis diesbezüglich ist ja auch nicht zu sehen.
Führe  VACUUM doch mal direkt im DbLog aus. Achte auch darauf dass auf deiner Festplatte/SD-Karte genügend Freiplatz ist und nicht volläuft.

Grüße,
Heiko

Moin Heiko,

habe gestern mal bei dblog das Attribut verbose auf 5 gestellt. Heute Nacht ist fhem wieder runter. Im Log habe ich folgendes:

Code Auswählen Erweitern


2021.06.30 03:25:43.545 4: DbLog dbLog -> Number of cache entries reached cachelimit 500 - start database sync.
2021.06.30 03:25:59.730 4: DbLog dbLog -> Number of cache entries reached cachelimit 500 - start database sync.
2021.06.30 03:26:24.644 4: DbLog dbLog -> Number of cache entries reached cachelimit 500 - start database sync.
2021.06.30 03:26:38.075 1: Cannot fork: Cannot allocate memory
2021.06.30 03:26:38.076 1: Cannot fork: Cannot allocate memory
2021.06.30 03:26:38.156 1: Cannot fork: Cannot allocate memory
2021.06.30 03:26:38.157 1: Cannot fork: Cannot allocate memory
2021.06.30 03:26:40.723 4: DbLog dbLog -> Number of cache entries reached cachelimit 500 - start database sync.
2021.06.30 03:26:50.804 1: SONOS0: Last Listener seems to be died and process started by fhem... stopping Threads and process...
2021.06.30 03:26:50.814 0: SONOS0: Das Lauschen auf der Schnittstelle wurde beendet. Prozess endet nun auch...


[DS_Starter]

Moin Daniel,

das ist das wesentliche:

Code Auswählen Erweitern


2021.06.30 03:26:38.075 1: Cannot fork: Cannot allocate memory
2021.06.30 03:26:38.076 1: Cannot fork: Cannot allocate memory
2021.06.30 03:26:38.156 1: Cannot fork: Cannot allocate memory
2021.06.30 03:26:38.157 1: Cannot fork: Cannot allocate memory


Dein Hauptspeicher ist aufgebraucht. Hat nicht direkt was mit DbLog zu tun, aber es wird hier eine Kernfunktion von FHEM genutzt um non-blocking zu arbeiten. Dadurch wird aber mehr Hauptspeicher temporär benutzt.
Das kann dir mit anderen Modulen, die diese Funktion nutzen, ebenfalls passieren. Zu "Cannot fork: Cannot allocate memory" gibt es einen eigenen, sehr langen Thread.

Es kommt also darauf an Speicher zu sparen. Möglicherweise reicht es auf eine andere Uhrzeit zu schieben.
Ansonsten könnte helfen das Logging zuvor abzuschalten mit "set <> reopen 3600" und nach dem VACUUM wieder einzuschalten mit "set <> reopen" (nach 1 Stunde wird automatisch weiter geloggt). Während der Zeit bleiben die Daten im Cache und gehen nicht verloren.

LG

[dancatt]

Ja, den Thread habe ich schon gefunden. Ich habe nun auch eine Vermutung woran das liegt. Werde ich mir genauer anschauen.
Seit kurzem habe ich eine neue Heizung und das Modul vitoconnect angebunden. Seit dem habe ich auch die Ausfälle.

Trotzdem vielen Dank für deine Unterstützung.

[dancatt]

Hallo Heiko,

heute Nacht um 4 ist nach 'set dbLog userCommand VACUUM' fhem wieder weg gewesen. Und es gab kein Speicherproblem. Wenn ich in der Befehlszeile von fhem 'set dbLog userCommand VACUUM' direkt ausführe ist fhem auch weg. Da scheint sich irgendwas geändert zu haben. Vor Mai hatte ich da noch keine Probleme.

Wenn ich aber 'set dbRep vacuum' ausführe habe ich keine Probleme.

Vielen Dank.

Gruß Daniel

[DS_Starter]

Wenn ich aber 'set dbRep vacuum' ausführe habe ich keine Probleme.

Dann nimm DbRep dafür. Die userCommand Implementierung in DbLog ist ohnehin rudimentär. Am Liebsten würde ich sie entfernen, aber um nicht unnötig Unruhe zu erzeugen ist der Setter noch drin.

LG

[C0mmanda]

Mahlzeit,

gibt es evtl. die Möglichkeit die Option average=day zu erweitern, z.B. average=month oder average=year, oder ist die Option sogar vorhanden?

Habe die Tagesdurchschnitte (average=day) der Außentemperatur/rH% der letzten 5 Jahre in der Datenbank.
Eigentlich total unnötig, aber jetzt sind die Daten nunmal da und einfach löschen mag ich die auch nicht

Zumindest die Monats- oder Jahresdurchschnittswerte wären noch einigermaßen interessant über die Jahre....

Danke & Gruß

[DS_Starter]

Guten Abend,

gibt es evtl. die Möglichkeit die Option average=day zu erweitern, z.B. average=month oder average=year, oder ist die Option sogar vorhanden?

Im DbLog werde ich diese Funktion nicht weiterentwickeln. Auswertungen und DB-Pflege sind nach DbRep verlagert. Diese und andere Funktion die nichts mit dem eigentlichen Logging zu tun haben sind nur noch aus historischen Gründen enthalten.

Im DbRep gibt es unter Anderem die Funktion averageValue. Damit kannst du dir den Durchschnitt eines beliebigen Zeitraums berechnen lassen und auch mit einem anderen Ergebnisnamen in die DB reinschreiben lassen. Diesen neuen Namen kannst du dann z.B. in Plots oder DbRep-Auswertungen nutzen.
Die ursprünglich gespeicherten Readings kann man dann löschen (delEntries) wenn sie nicht mehr gebraucht werden.

Grüße,
Heiko

[C0mmanda]

Danke für den Hinweis, werde ich mir anschauen!

Gruss

[Jamo]

Beim löschen meiner Daten aus der SQLite db, älter als 6 Tage mit "set myDbLog deleteOldDays 6" erhalte ich folgende Fehlermeldung, dieses 'delEntries' cmd gibt es aber nicht:

Code Auswählen Erweitern

DbLog myDbLog - WARNING - "deleteOldDays" is deprecated. Please use DbRep "set <Name> delEntries" instead.
Ein 'set myDbLog delEntries 6' liefert

Code Auswählen Erweitern

Unknown argument, choose one of reduceLog reduceLogNbl reopen rereadcfg count configCheck countNbl deleteOldDays deleteOldDaysNbl userCommand clearReadings eraseReadings addLog listCache addCacheLine purgeCache commitCache exportCache importCachefile
Meine db ist wie folgt definiert:

Code Auswählen Erweitern

Internals:
   COLUMNS    field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
   CONFIGURATION ./db.conf
   DEF        ./db.conf myAstroHome:(RelativerDachwinkel.*|SunAlt|SunAz):.*
   FUUID      5c42ee3d-f33f-97bf-1c6f-e923873a5f26a5c8
   FVERSION   93_DbLog.pm:v4.12.5-s25394/2021-12-31
   MODE       asynchronous
   MODEL      SQLITE
   NAME       myDbLog
   NR         8
   NTFY_ORDER 50-myDbLog
   PID        14397
   REGEXP     myAstroHome:(RelativerDachwinkel.*|SunAlt|SunAz):.*
   SQLITECACHESIZE 4000
   SQLITEWALMODE on
   STATE      connected
   TYPE       DbLog
   dbconn     SQLite:dbname=/opt/fhem/fhem.db
   dbuser     
   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
   READINGS:
     2022-01-03 11:42:10   CacheOverflowLastNum 0
     2021-03-08 11:15:27   CacheOverflowLastState normal
     2022-01-03 11:42:45   CacheUsage      4
     2022-01-03 11:42:10   NextSync        2022-01-03 11:44:10 or if CacheUsage 500 reached
     2021-02-21 20:07:36   countCurrent    162
     2021-02-21 20:07:36   countHistory    69462
     2022-01-03 03:30:00   lastRowsDeleted 0
     2022-01-03 11:42:10   state           connected
Attributes:
   DbLogType  Current/History
   asyncMode  1
   bulkInsert 1
   comment    SQLite:dbname=/media/usb0/fhem.db
   event-on-change-reading none
   group      SERVER
   room       Favourites
   stateFormat {my $state = ReadingsVal($name,'state','nA'); if ($state ne 'connected') {return '<font color="red"><b>'. $state .'</b></font>'} else {return $state}}
   syncInterval 120
   userReadings DbFileSize:reduceLogState.* { (split(' ',`du -m fhem.db`))[0] }
   verbose    2

Was ist falsch?

[DS_Starter]

DbLog myDbLog - WARNING - "deleteOldDays" is deprecated. Please use DbRep "set <Name> delEntries" instead.

In einem DbRep Device ausführen.

LG

[Jamo]

Hallo DS_Starter, danke, manchmal sieht man den Wald ja gar nicht.
Ich habe kein DbRep device, werde es also einfach erstmal bei ''set myDbLog delEntries 6'' belassen.
Danke und nachträglich ein frohes Neues auch noch!

[DS_Starter]

Danke und ebenso 

[betateilchen]

In einem DbRep Device ausführen.

Muss man denn wirklich jede Zusatzfunktion in ein separates device packen?

Seit 7 oder 8 Jahren funktioniert deleteOldDays bei mir in vielen FHEM Installationen völlig problemlos.
DbRep habe ich bis heute kein einziges Mal gebraucht, deshalb existiert so ein device bei mir nicht.

Warum werde ich jetzt - gefühlt - völlig willkürlich dazu gezwungen, noch ein zusätzliches device in meine Installation zu bringen, nur um die Log-Datenbank klein zu halten?