Ich habe heute mal den configcheck bei meinem dblog ausgeführt. Coole Sache, allerdings ist mir folgendes aufgefallen. Ausgegeben wurde:
Result of logmode check
Logmode of DbLog-device Logdb_Heizung is: synchronous
Recommendation: Switch Logdb_Heizung to the asynchronous logmode by setting the 'asyncMode' attribute. The advantage of this mode is to log events non-blocking.
There are attributes 'syncInterval' and 'cacheLimit' relevant for this working mode.
Please refer to Commandref attributes for further informations.
Wobei ich schon längst auf asynchron laufe:
Internals:
CFGFN
COLUMNS field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
CONFIGURATION ./db_Heizung.conf
DEF ./db_Heizung.conf (SZ.Fuehler|WZ.NASStat|.*_Clima):(state|desired-temp|measured-temp|ValvePosition|temperature|hdd1_temp|hdd2_temp|humidity).*
MODE synchronous
MODEL MYSQL
NAME Logdb_Heizung
NR 136
NTFY_ORDER 50-Logdb_Heizung
PID 955
REGEXP (SZ.Fuehler|WZ.NASStat|.*_Clima):(state|desired-temp|measured-temp|ValvePosition|temperature|hdd1_temp|hdd2_temp|humidity).*
STATE connected
TYPE DbLog
UTF8 1
VERSION 2.22.3
dbconn mysql:database=xxx;host=xxx;port=xxx
dbuser xxx
HELPER:
COLSET 1
DEVICECOL 64
EVENTCOL 512
READINGCOL 64
TYPECOL 64
UNITCOL 32
VALUECOL 128
READINGS:
2017-09-04 11:27:56 CacheUsage 3
2017-09-04 11:27:11 NextSync 2017-09-04 11:32:11 or if CacheUsage 500 reached
2017-09-04 11:27:12 background_processing_time 0.3651
2017-09-04 11:27:56 notify_processing_time 0.0015
2017-09-04 11:27:12 sql_processing_time 0.2376
2017-09-04 11:27:12 state connected
cache:
index 37855
memcache:
37853 2017-09-04 11:27:49|WZ.NASStat|SYSSTAT|state: 0.25 0.29 0.21|state|0.25 0.29 0.21|
37854 2017-09-04 11:27:49|WZ.NASStat|SYSSTAT|temperature: 46|temperature|46|°C
37855 2017-09-04 11:27:56|Bad.HZ_Clima|CUL_HM|measured-temp: 20.7|measured-temp|20.7|
Attributes:
DbLogType History
asyncMode 1
disable 0
showNotifyTime 1
showproctime 1
shutdownWait 3
syncInterval 300
Und wo wir gerade dabei sind noch eine Sache. Schließt man die db mittels reopen für einige Zeit, wegen Updates etc. und öffnet sie dann wieder manuell, weil man das Zeitintervall von reopen zu lange angesetzt hat, dann werden erst beim erreich von max CacheUsage Daten wieder geschrieben. Das Synintervall wird nicht neu gestartet und bleibt auf dem letzten vergangen Wert stehen.
Der check wertet das Internal MODE aus. Das steht bei dir komischerweise noch auf "synchronous". Ich schau mir das mal an wie das kommen kann.
Auch den anderen Aspekt.
Wie genau öffnest du wieder manuell ? (habe es gerade nicht vor mir)
Gruss
Heiko
Auf das Internal habe ich gar nicht geachtet. Habe jetzt einfach nochmal das Attr auf 1 gesetzt und dann hat das Internal es auch angenommen. Bin mir aber sicher, dass die DB bereits im async Mode gearbeitet hat.
Ich mache folgendes:
set DB reopen 7200
Mach ein Update meiner NAS
set DB reopen
jetzt ist die Verbindung wieder da. Allerdings steht NextSync noch auf der letzten eigentlichen Uhrzeit, wann es wieder dran gewesen wäre. Nun wartet die DB quasi bis CacheUsage auf max ist und schreibt dann. Ab dann geht auch NextSync wieder los. Es sieht danach aus, dass der NextSync Timer bei reopen nicht zurück gesetzt wird.
Edit:
Habe gerade folgendes festgestellt. Sobald man die DEF ändert und speichert, fällt das Internal auf sync Mode. Man muss danach wieder das Attr nochmal neu setzen, damit das Internal auf async wechselt.
Hallo Amenophis,
habe dir eine Version 2..22.5 angehängt.
Mit der Version sollten die von dir beschriebenen Probleme beseitigt sein.
Teste mal bitte mit allen Scenarien die du so einsetzt.
Grüße
Heiko
Werde es die Tage machen, heute komme ich leider nicht mehr dazu. Dank dir.
Der Typ wird wohl richtig erkannt jetzt. Allerdings das reopen Problem bleibt bestehen. Habe die Verbindung um 11:25 Uhr für 7200 Sek mit reopen geschlossen, gewartet bis der NextSyn Timer (11:30) überschritten wurde, mittels reopen neu um 11:31 Uhr geöffnet, aber der Timer für NextSyn bleibt 11:30 Uhr.
Schaue ich mir nochmal an .... wir schaffen das schon ;)
aber sicher doch :)
Habe die Version in #3 nochmal angepasst und auch den Fehler gefunden (hoffe ich :) )
Bitte nochmal testen ...
Grüße
Heiko
Jetzt klappt es
ZitatJetzt klappt es
prima, kommt ins nächste Release.
EDIT: V2.22.5 eingecheckt