93_DbLog - Umstellung Log-Funktion auf non-blocking

[ioT4db]

Hallo friesenjung,

sorry, deine Frage hatte ich fast vergessen.

...

Hallo Heiko, hört sich gut an. Ich warte gespannt. VG...

[JoeALLb]

Als ersten Schritt würde ich die von betateilchen vorgeschlagene Übersteuerung der Default-Feldlängen im Modul mittels Einträgen im DbLog-Configfile (db.conf) realisieren.
Der zweite (weil umfänglichere) Schritt wäre die Abfrage der Feldlängen aus der DB wie Joe vorgeschlagen hat, die dann ihrerseits die Uservariablen im Configfile sowie die Default-Einstellungen in dem Modul übersteuern.

Wäre es nicht einfacher/übersichtllicher/besser, das nicht über db.conf, sondern über Atribute machen?
Dann wäre die Reihenfolge so:  Attribut > Default .
Später könnte man dann die Internals einfach noch mit einbinden: Die neue Reihenfolge wäre dann: Attribut > ausgelesenes Internal > Default.
Ich denke das wäre lesbarer und auch für die Zukunft einfacher zu handhaben. Und direkt beim initialisieren der DB-Verbinmdung wird
die Feldlänge ja noch nicht benötigt.

Mir gefällt es besser, die Config "zentral" in FHEM zu haben und nicht allzuviele externe Stellen mit einbeziehen (die die db.conf).
Zusätzlich kann man Attribute besser in Scripten auslesen und dort ebenfalls verwenden.... just my 5 cents

[DS_Starter]

Hi Joe,

Wäre es nicht einfacher/übersichtllicher/besser, das nicht über db.conf, sondern über Atribute machen?

Also ich bin da offen. Für Attribute spricht, dass ich hier auch eine Prüfroutine für die Verwendung von Ziffern einbauen die gleich einen Popup erzeugen falls man danebenhaut.
Das Configfile ist allerdings auch sehr einfach zu handhaben und ist den Usern ja bekannt.

Vielleicht gibt es diebezüglich noch ein paar Meinungen.

Schönen Abend !

LG
Heiko

[ioT4db]

Ich wäre auch für Attribute, da es schon Sinn macht alles aus Fhem heraus im Blick zu haben.
VG

[Christian Uhlmann]

Vielen Dank für das tolle Modul und deren Weiterentwicklung.
Bin auch für Attribute, ich glaube das wurde wie configDB gelöst und da braucht man es in einem extra file.

[Benni]

Bin auch für Attribute, ich glaube das wurde wie configDB gelöst und da braucht man es in einem extra file.

Ich hab' den Satz jetzt ungefähr 10 mal gelesen und werde einfach nicht schlau draus 

Grundsätzlich finde ich auch, dass das Verhalten über Attribute (über-)steuerbar sein sollte. Das Vorgehen an sich kann aber gerne, wie ursprünglich angedacht bleiben. Sprich lesen der Feldlängen aus der DB (falls nicht per Attribut anders definiert) -> Feldlängen aus Config-File (falls dort welche definiert sind und nicht aus DB gelesen, entweder weil nicht gewünscht oder nicht möglich) -> Defaults, wie bisher

Per Attribut dann nur noch steuern, ob die Option "Lesen der Feldlängen aus DB" überhaupt wahrgenommen werden soll, der Rest ergibt sich dann ja von selbst.

[gima84]

Hi, ich habe heute ein komplettes Update von FHEM vorgenommen. Leider startet FHEM danach nicht mehr aufgrund der 93_DbLog.

Fehler:

Code Auswählen Erweitern

2017.01.21 18:12:30 5: Triggering myDBLog (2 changes)
DBD::SQLite::db prepare failed: attempt to prepare on inactive database handle at ./FHEM/93_DbLog.pm line 955.

Anschließend hab ich die ältere Version wiederhergestellt ($Id: 93_DbLog.pm 11825 2016-07-21 05:40:59Z) -> FHEM startet wieder. Debian und CPAN wurden ebenfalls mit aktualisiert.

Code Auswählen Erweitern

Internals:
   CONFIGURATION /opt/fhem/db.conf
   DBMODEL    SQLITE
   DEF        /opt/fhem/db.conf .*:.*
   NAME       myDBLog
   NR         20
   NTFY_ORDER 50-myDBLog
   PID        5307
   REGEXP     .*:.*
   STATE      connected
   TYPE       DbLog
   dbconn     SQLite:dbname=/opt/db_fhem/fhem-db
   dbuser
   Helper:
     Dblog:
       State:
         Mydblog:
           TIME       1485020572.97598
           VALUE      connected
   Readings:
     2017-01-21 18:42:52   state           connected
Attributes:
   DbLogType  Current/History
   verbose    1

Habe ich bei der Umstellung etwas übersehen?

Viele Grüße
Martin

[DS_Starter]

Hallo Martin,

soweit ich sehe sollte alles passen, außer dass in dem Fall wohl keine Verbindung zur DB aufgebaut werden konnte.
In dem Fall gäbe es aber noch mehr Einträge im Log.
Nimm am Besten gleich die V2.10.3 aus  #384 , restarte FHEM und berichte bitte ob du damit noch dieses beschriebene Problem hast.

Grüße
Heiko

[Jorge3711]

Hallo zusammen,

nachdem ich heute meine FHEM Instanz von Wheezy auf eine Jessie-lite Neuinstallation und neue SD-Karte (Raspi 2) umgezogen habe ist mir folgendes aufgefallen. Bei jedem Zugriff auf die DB erhalte ich folgende Meldungen im fhem.log:

Code Auswählen Erweitern


2017.01.21 21:39:36 3: Connecting to database mysql:database=fhem;host=localhost;port=3306 with user fhemsql
2017.01.21 21:39:36 3: Connection to db mysql:database=fhem;host=localhost;port=3306 established for pid 1250
2017.01.21 21:41:37 3: Connecting to database mysql:database=fhem;host=localhost;port=3306 with user fhemsql
2017.01.21 21:41:37 3: Connection to db mysql:database=fhem;host=localhost;port=3306 established for pid 1288
2017.01.21 21:41:37 3: Connecting to database mysql:database=fhem;host=localhost;port=3306 with user fhemsql
2017.01.21 21:41:37 3: Connection to db mysql:database=fhem;host=localhost;port=3306 established for pid 1288
Waiting for data... (interrupt to abort)


Was meine ich mit DB Zugriff: wenn ich im FHEMWEB ein Plot anzeigen lasse, welches sich die Daten aus der DB holt, tauchen obige Meldungen im fhem.log auf. Ist das Absicht? Kann man das abstellen?

Hier ein List meiner DBlog:

Code Auswählen Erweitern


Internals:
   CONFIGURATION ./db.conf
   DBMODEL    MYSQL
   DEF        ./db.conf .*:.*
   MODE       asynchronous
   NAME       logDB
   NR         33
   NTFY_ORDER 50-logDB
   PID        517
   REGEXP     .*:.*
   STATE      connected
   TYPE       DbLog
   VERSION    2.9.2
   dbconn     mysql:database=fhem;host=localhost;port=3306
   dbuser     fhemsql
   Helper:
   Readings:
     2017-01-21 21:48:57   CacheUsage      10
     2017-01-21 21:44:45   NextSync        2017-01-21 21:54:45
     2017-01-21 21:44:45   background_processing_time 0.1644
     2017-01-21 21:02:04   countCurrent    37
     2017-01-21 21:02:04   countHistory    322
     2017-01-21 21:44:45   sql_processing_time 0.1480
     2017-01-21 21:44:45   state           connected
   Cache:
     index      52
     Memcache:
       43         2017-01-21 21:45:37|temp.dg.diffmessure.t2|CUL_HM|temperature: 22.5|temperature|22.5|°C
       44         2017-01-21 21:45:57|Buderus|BDKM|PowerModulation: 61|PowerModulation|61|
       45         2017-01-21 21:45:57|Buderus|BDKM|HC1InputTemp: 40.3125|HC1InputTemp|40.3125|
       46         2017-01-21 21:45:57|Buderus|BDKM|HC1ReturnTemp: 35.9375|HC1ReturnTemp|35.9375|
       47         2017-01-21 21:48:28|energie_strom_waschmaschine_Pwr|CUL_HM|energy: 25849.7|energy|25849.7|
       48         2017-01-21 21:48:34|temp.dg.diffmessure.t2|CUL_HM|temperature: 22.5|temperature|22.5|°C
       49         2017-01-21 21:48:57|Buderus|BDKM|PowerModulation: 61|PowerModulation|61|
       50         2017-01-21 21:48:57|Buderus|BDKM|OutdoorTemp: -10.4|OutdoorTemp|-10.4|
       51         2017-01-21 21:48:57|Buderus|BDKM|HC1InputTemp: 40.4375|HC1InputTemp|40.4375|
       52         2017-01-21 21:48:57|Buderus|BDKM|HC1ReturnTemp: 35.9375|HC1ReturnTemp|35.9375|
Attributes:
   DbLogSelectionMode Include
   DbLogType  Current/History
   asyncMode  1
   room       Zentrale
   showproctime 1
   shutdownWait 2
   syncInterval 600
   webCmd     listCache

Die DB ist eine MariaDB 10.0.28, welche lokal auf dem Raspi mit FHEM läuft.

Danke und Gruß

[DS_Starter]

Hallo Jorge3711,

Ist das Absicht? Kann man das abstellen?

Das sind Informationen dass eine Verbindung zur DB neu aufgebaut/refreshed wurde. Abstellen kannst du es mit verbose=2.

Allgemein entwickeln wir zur Zeit beständig weiter. Nutze bitte gleich die  V2.10.3 aus  #384.

viele Grüße

[Jorge3711]

OK, danke für die Rückinfo. Ich verfolge den Thread als stiller Mitleser sehr interessiert. Nachdem ich wegen HW Problemen inkl. DB Problemen auf der alten FHEM Installation die Neuinstallation durchführte, war ich etwas erschrocken und dachte die DB hat schon wieder einen Hau weg.

[DS_Starter]

Hallo zusammen,

es hat sich eine Mehrheit dafür ausgesprochen die Feldlängenanpassung im Modul über Attribute vorzunehmen.
Das habe ich so umgesetzt und die Feldlängen von EVENT, READING, VALUE mit der angehängten V2.10.4 anpassbar gemacht.

Dazu gibt es die neuen Attribute colEvent, colReading, colValue.

Im Internal "COLUMNS" findet man eine Zusammenfassung der Feldlängen die das DbLog-Device aktuell benutzt:

Code Auswählen Erweitern

field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32

FHEM Restart ist nötig.

Bitte testet diese Version bei euch auch unter anderen Gesichtspunkten wie Plot, Vorschlagswerte mit Current/History, usw. mit euren DB-Typen.
Ich würde diese Version gern einchecken bzw. Tobias bitten es zu tun. Seit der letzten eingecheckten Version ist doch schon so Einiges weiterentwickelt/angepasst worden.

@Benni ... für deine Eventgeschichte habe ich noch keine gute Lösung gefunden. Habe es mit direktem Setzen von $defs{$name}{READINGS}{CacheUsage} probiert, aber das ist nicht gut. Vielleicht hast du noch eine zündende Idee wie man den Mechanismus abändern könnte. Ich denke auch
noch weiter darüber nach.

viele Grüße
Heiko

[Benni]

Hallo Heiko,

@Benni ... für deine Eventgeschichte habe ich noch keine gute Lösung gefunden. Habe es mit direktem Setzen von $defs{$name}{READINGS}{CacheUsage} probiert, aber das ist nicht gut. Vielleicht hast du noch eine zündende Idee wie man den Mechanismus abändern könnte.

Nun, man könnte ja auch argumentieren, dass ein setzen von CachUsage ohne Event sowieso keinen Sinn macht, weil es dann ja auch keiner mitbekommt. (frei nach Schrödinger )

So gesehen könnte man den else-Zweig in DbLog_Log an der kritischen stelle auch tatsächlich einfach weglassen, zumindest dann, wenn im Asynch-Modus für cacheEvents 2 gewählt ist. Das ist ja "nur" die Stelle, an der der Wert für CacheUsage ganz allgemein bei jedem Log gesetzt wird, das ist in diesem Fall aber eher uninteressant.
Beim setzen von CacheUsage in DbLog_execmemcache wird der Wert ($memcount) vor dem setzen des Readings dort ja sowieso nochmal neu ermittelt, so dass für das Event dann auch dort der korrekte Wert geliefert wird.

VG Benni.

[DS_Starter]

Hallo Benni,

habe das mal probiert. Hatte den Nachteil dass CacheUsage dann u.U. keinen Wert anzeigt obwohl listCache einen Inhalt listet.
Das führt stiftet dann wieder Verwirrung und Fragen ....

Aber dein Satz:

So gesehen könnte man den else-Zweig in DbLog_Log an der kritischen stelle auch tatsächlich einfach weglassen, zumindest dann, wenn ...

hat mich inspieriert und vielleicht zur Lösung gebracht 
Ich habe mir über den HELPER ein Sperrbit gesetzt wenn execmemcache den Event setzen will. Der relevante Else-Zweig im DbLog_Log wird dann an der Ausführung gehindert (für diesen kurzen Moment). Passiert ja nur alle x-Sekunden wenn der Db-Sync läuft.
Probier mal die angehängte V2.10.5 bei dir ob das so zieht wie beabsichtigt. Ich merke keinen Unterschied zu vorher.

viele Grüße
Heiko

[gima84]

Hallo Heiko,

danke, hat funktioniert.

Gruß Martin

Hallo Martin,

soweit ich sehe sollte alles passen, außer dass in dem Fall wohl keine Verbindung zur DB aufgebaut werden konnte.
In dem Fall gäbe es aber noch mehr Einträge im Log.
Nimm am Besten gleich die V2.10.3 aus  #384 , restarte FHEM und berichte bitte ob du damit noch dieses beschriebene Problem hast.

Grüße
Heiko