DbLog - Umstellung Betrieb auf SubProcess -> Tester gesucht

[DS_Starter]

Any ideas?

Ja, ist nur eine Warnung und ist schon im Fokus ... siehe Beitrag drüber ...

Ansonsten keine besonderen Voraussetzungen, Version ist funktionskompatibel zur offiziellen Version.

[DS_Starter]

Die $memcount  Warnung sollte nun beseitigt sein.
Update im contrib.

[erwin]

re: patch/Zeilennummern...
der patch besteht aus einer Zeile, in DbLog_Log:

Code Auswählen Erweitern

  if(AttrVal ($name, 'verbose', 3) == 4) {
      if($log4rel) {
          Log3 ($name, 4, "DbLog $name - ################################################################");
          Log3 ($name, 4, "DbLog $name - ###              start of new Logcycle                       ###");
          Log3 ($name, 4, "DbLog $name - ################################################################");
          Log3 ($name, 4, "DbLog $name - number of events received: $max of device: $dev_name");
      }
  }

  my ($event,$reading,$value,$unit,$memcount);
  $memcount = 0;  #<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
  my $err;

[erwin]

Vorschlag zu cacheUsage:
dass passt m.M. auch besser zum wording in der cmd-ref.
gestestet allerdings nur mit cacheEvents 2!

[SusisStrolch]

re: patch/Zeilennummern...
der patch besteht aus einer Zeile, in DbLog_Log:

Danke. Dann kann ich mal mein UTF-8 Problemchen testen...

[DS_Starter]

Danke erwin,

fast getroffen denke ich 
Habe es etwas verändert übernommen.
Gerne wieder aus contrib laden und gegenchecken.

[erwin]

Hallo Heiko,

Ja, das passt!
...auch wenn das readingsupdate ohne EVENT mir nicht ganz verständlich ist...
Aber aus Kompatibilitätsgründen macht das Sinn.

[DS_Starter]

...auch wenn das readingsupdate ohne EVENT mir nicht ganz verständlich ist...

Naja, lt. ComRef und wie es von mir auch gedacht war liegt der Schwerpunkt  auf der Erzeugung von entsprechenden Events dieses Readings. Ursprünglich war die Verwendung den Füllgrad des Caches durch den User loggen/überwachen zu können.
Upgedated werden sollte es unabhängig von der Eventerstellung.

[enno]

Folgende Warnung habe ich im Log:

Code Auswählen Erweitern

2022.12.05 21:41:14.371 1: PERL WARNING: Use of uninitialized value $v2[0] in regexp compilation at ./FHEM/93_DbLog.pm line 1516.


Code Auswählen Erweitern

93_DbLog.pm:v5.2.0-s26750/2022-12-05 Sonst alles unauffällig.

[DS_Starter]

Hallo enno,

ich denke das kommt von einem DbLogInclude Attr bei dem das Reading fehlt/nicht mitkommt.
Das ist eine Stelle die im offiziellen Modul auch so definiert ist.
Ich weiß nicht wie oft die Warnung bei dir kommt, man bekommt es mit einem verbose 5 raus.

verbose 5 schmeißt aber viele Daten. Wenn du keine Idee hast, mache ich für dich eine Version um herauszubekommen
was genau bei dir diese Warnung erzeugt.

[enno]

Ich glaube das lohnt nicht. Ich habe die Meldung das erste Mal gesehen. Wenn das öfter passiert, drehe ich am Verbose. Ich bebachte weiter.

Edit: Ich habe in der SQL-Datenbank um genaue die Uhrzeit zwei Einträge meiner Heizung. Der Fehler kam von meiner Heizung "km200". Das Modul hatte ich heute morgen nach langen Zögern doch aktualisiert. Nun habe ich plötzlich einen ganzen Sack mehr Readings dort. Beim Hinzufügen zum Attr DbLogInclude hat sich das System wohl kurz "verschluckt".

[DS_Starter]

Möglicherweise hilft dir auch das globale stacktrace einzuschalten.

[SusisStrolch]

SQL-Error Handling
Habe extra mal 'nen fehlerhaften Event via "importCache" eingespielt (Fragment im Anhang) und bewusst auf DbLogValueFN verzichtet.
Sobald MariaDB einen Fehler meldet wird der zu Grunde liegende MemCache verworfen und nicht in ein Cache-File gesichert.
Unangenehm wenn man aus Performance-Gründen auf Einzeltransaktionen verzichten muß/will.

Code Auswählen Erweitern

2022.12.05 15:34:37.310 4: DbLog logdb - 40 of 40 events inserted into table history
2022.12.05 15:34:37.998 2: DbLog logdb - Error table history - DBD::mysql::st execute_array failed: executing 33 generated 1 errors at ./FHEM/93_DbLog.pm line 2428.

2022.12.05 15:34:38.319 4: DbLog logdb - commit inserted data table history
2022.12.05 15:34:38.323 4: DbLog logdb - begin transaction
2022.12.05 15:34:38.881 4: DbLog logdb - insert history rolled back
2022.12.05 15:34:38.924 5: DbLog logdb - DbLog_Push Returncode: DBD::mysql::st execute_array failed: executing 33 generated 1 errors at ./FHEM/93_DbLog.pm line 2428.



Der Vollständigkeit halber hier das DbLog Device:

Code Auswählen Erweitern

defmod logdb DbLog ./contrib/dblog/MariaDB10.conf .*:.*
attr logdb DbLogExclude .*
attr logdb DbLogSelectionMode Exclude/Include
attr logdb DbLogType Current/History
attr logdb asyncMode 1
attr logdb bulkInsert 0
attr logdb cacheEvents 2
attr logdb cacheOverflowThreshold 750
attr logdb colEvent 512
attr logdb colReading 64
attr logdb colValue 128
attr logdb disable 0
attr logdb event-on-change-reading CacheUsage,background_processing_time
attr logdb icon security
attr logdb room DbLog
attr logdb showNotifyTime 1
attr logdb showproctime 1
attr logdb timeout 86400
attr logdb verbose 5

[DS_Starter]

Moin,

im asynch Mode und mit Transaktion (default) wird der übergebene Datenstack wieder an den Cache zurück gegeben.
Das sollte klappen.

Ich habe gerade eben die nächste V ins contrib geladen. Mit verbose 5 sieht man die zurück gegebenen Daten im Log:

  Log3 ($name, 5, "DbLog $name - rowlback to Cache: $key -> ".$rowlback->{$key});

Weiterhin habe ich noch den CPU-Verbrauch der/des SubProcesses deutlich reduzieren können.
Probiers mal aus.

[SusisStrolch]

Hmm, hat nicht so geklappt wie ich das erwartet habe.
Vorgehensweise:
Cache-File (1000 Zeilen) mit dem UTF-8 Fehler importiert.
Commit wurde abgebrochen. Ich hätte jetzt erwartet das die Cachegröße > 1000 ist und die Daten weiterhin im Cache stehen. Dies ist jedoch nicht der Fall.

Code Auswählen Erweitern

defmod logdb DbLog ./contrib/dblog/MariaDB10.conf .*:.*
attr logdb DbLogExclude .*
attr logdb DbLogSelectionMode Exclude/Include
attr logdb DbLogType Current/History
attr logdb asyncMode 1
attr logdb bulkInsert 0
attr logdb cacheEvents 2
attr logdb cacheOverflowThreshold 750
attr logdb colEvent 512
attr logdb colReading 64
attr logdb colValue 128
attr logdb disable 0
attr logdb event-on-change-reading CacheUsage,background_processing_time
attr logdb icon security
attr logdb room DbLog
attr logdb showNotifyTime 1
attr logdb showproctime 1
attr logdb timeout 86400
attr logdb verbose 5

setstate logdb connected
setstate logdb 2022-12-06 10:36:44 CacheOverflowLastNum 0
setstate logdb 2022-12-03 15:42:58 CacheOverflowLastState normal
setstate logdb 2022-12-06 10:36:44 CacheUsage 19
setstate logdb 2022-12-06 10:36:44 NextSync 2022-12-06 10:37:14 or when CacheUsage 500 is reached
setstate logdb 2022-12-06 10:36:45 background_processing_time 0.2823
setstate logdb 2022-12-06 10:28:14 lastCachefile ./log/cache_logdb_2022-12-02-n1000 - Error - Resource temporarily unavailable
setstate logdb 2022-12-06 10:36:53 notify_processing_time 0.0048
setstate logdb 2022-12-06 10:36:45 sql_processing_time 0.2688
setstate logdb 2022-12-06 10:36:45 state connected



Im Filesystem ist auch keine neue Datei aufgetaucht, obwohl cacheOverflowThreshold auf 750 gesetzt ist.
Ich habe den entsprechenden Logfile-Auszug angehängt...