93_DbLog - Umstellung Log-Funktion auf non-blocking

[PatrickR]

@lolo: attr DbLogType Current/History


Von unterwegs gesendet.

[Loredo]

könntest du auch noch einbauen, dass DbLog_splitFn nicht nur in $modules{ $defs{$name}{TYPE} }{DbLog_splitFn} gesucht wird, sondern auch in $defs{$name}{'.DbLog_splitFn'}?
$defs{$name}{'.DbLog_splitFn'} sollte dabei dann Vorrang haben.

Ich habe das inzwischen in das sich in Entwicklung befindliche Modul "98_powerMap" mit eingebaut. Es setzt bereits $defs{$name}{'.DbLog_splitFn'} und wartet darauf, dass DbLog es dort abholt 
Wäre also prima, wenn bei den ganzen gerade ohnehin stattfindenden Updates diese Kleinigkeit ergänzt werden könnte.




Danke & Gruß
Julian

[DS_Starter]

Hallo zusammen,

hier wie angekündigt die V2.8.5. Es werden Events von CacheUsage, NextSync nur noch erzeugt wenn die Attr "syncEvent"" bzw. "cacheEvents" gesetzt sind. State gibt im Normalfall keine Events, Fehler wie DBI-Error usw. tun dies.
Commandref ist aktualisiert.

@Julien, ja habe es nicht vergessen. Aber ich möchte erstmal hier in ruhigere Fahrwasser kommen.

LG
Heiko

[Ellert]

Ich habe mal 15 min geloggt und es gibt keine DbLog-Events. Nur das Attribut asyncMode 1 ist gesetzt.

Danke
Ellert

[Tobias]

Hi Julian,
warum willst du "$defs{$name}{'.DbLog_splitFn'}" das so einbauen und niocht so, wie es im Wiki für die Modulentwickler drinsteht?
Oder hab ich noch etwas nicht ganz verstanden?

@DS_Starter: du könntest das Modul im stabilen Zustand auch selbst einchecken. Anosnsten musst du mir eine PM schreiben wen ich es machen soll. Allerdings mit 1-2 Tagen verzögerung möglich ...

[ioT4db]

Hallo Zusammen,
bin kein Entwickler, nur User! 

Ich habe aber festgestellt, dass seit dem Update auf 2.8.2 des DbLog-Moduls Events mit sehr langen Inhalt nicht komplett geloggt werden, sondern "abgeschnitten" gespeichert werden.

Aufgefallen ist es mir beim THZ-Modul, welches z.B. ein sehr langes Reading "sGlobal" hat. Es ist etwa 750 Zeichen lang.

Nach dem Update auf Version 2.8.2 wurde dieser Reading sGlobal bei ca. 513 Zeichen "abgeschnitten".

Könnte das etwas mit den hier vorgenommenen Änderungen zu tun haben?

Auch fällt auf, dass bei gleichzeitigem Verwenden des FileLog-Devices auch im Filelog nur noch das gekürzte Event steht. Deaktiviert man das Logging per DbLog, so wird das Reading auch wieder vollständig im FileLog abgespeichert!

Danke schonmal für Euer Feedback und VG...

[JoeALLb]

Aufgefallen ist es mir beim THZ-Modul, welches z.B. ein sehr langes Reading "sGlobal" hat. Es ist etwa 750 Zeichen lang.

Hast Du die Spalte in der Datenbank  manuell "verbreitert"?
Im Standard ist diese nur 512 Zeichen "breit", kann also gar nicht mehr zeichen abspeichern....

[ioT4db]

Hast Du die Spalte in der Datenbank  manuell "verbreitert"?
Im Standard ist diese nur 512 Zeichen "breit", kann also gar nicht mehr zeichen abspeichern....

Hi. Ja, hab ich. Die Spalte EVENT ist bei mir auf 1024 Zeichen geändert. Wie gesagt ging es ja bis ich, ich glaube vorgestern Abend, FHEM aktualisiert habe.

Auch würde das nicht erklären, warum beim Parallelbetrieb (FileLog + DbLog) auch das Event gekürzt im FileLog auftaucht...

[Loredo]

warum willst du "$defs{$name}{'.DbLog_splitFn'}" das so einbauen und niocht so, wie es im Wiki für die Modulentwickler drinsteht?
Oder hab ich noch etwas nicht ganz verstanden?

Der Wiki Artikel spricht davon $hash->{DbLog_splitFn} in der X_Initialize() Funktion zu setzen.
Dies entspricht einer Definition für alle Instanzen dieses Moduls, da $hash hier nur eine Referenz auf $modules{ $hash->{TYPE} } ist und DbLog_splitFn somit tatsächlich in $modules{ $hash->{TYPE} }{DbLog_splitFn} gespeichert wird (siehe auch hier). Daran möchte ich nichts ändern.

Was mir fehlt ist die Möglichkeit pro definiertem Device ebenfalls individuell eine DbLog_splitFn setzen zu können, also in $defs{ $hash->{NAME} }. Sprich: Dort würde dann eigentlich ein INTERNAL angelegt. Mir erschien es sinnvoll dies hier mit einem führenden Punkt unsichtbar zu schalten statt es sichtbar zu haben. Deshalb $defs{ $hash->{NAME} }{'.DbLog_splitFn'}. Der Grund ist, dass IMHO ein externes Modul wie 98_powerMap nicht direkt in den Hash der Moduldefinition schreiben soll, sondern wenn überhaupt nur in eine Modulinstanz unter $defs (und auch dann nur "freundlich"; in diesem Fall auch nur, wenn das externe Modul bisher noch gar keine DbLog_splitFn gesetzt hat).

Über den führenden Punkt kann man aber sicher streiten und letztlich geht es mir nur um die Funktionalität ansich.

[JoeALLb]

Hi. Ja, hab ich. Die Spalte EVENT ist bei mir auf 1024 Zeichen geändert. Wie gesagt ging es ja bis ich, ich glaube vorgestern Abend, FHEM aktualisiert habe.

Auch würde das nicht erklären, warum beim Parallelbetrieb (FileLog + DbLog) auch das Event gekürzt im FileLog auftaucht...

Nun, in Zeile 819 wird der text mit folgendem code gekürzt.

Code Auswählen Erweitern

$reading  = substr($reading,0, $columns{READING});
Wenn Du das für dich in

Code Auswählen Erweitern

$reading  = substr($reading,0, 1024);
änderst, sollte das vorerst gehen.

Warum genau dieses Kürzen der Readings hier gemacht wird, kann ich nicht einschätzen.... meiner Meinung nach sollte das MySQL selbst auch passend kürzen, wenn eine Spalte zu schmal ist.

[marvin78]

MySQL tut das auch. Macht es SQLite auch?

[JoeALLb]

MySQL tut das auch. Macht es SQLite auch?

Im Code ist speziell SQLite ausgenommen... also wird es nur für die anderen DBs gemacht.

Code Auswählen Erweitern

if ($hash->{DBMODEL} ne 'SQLITE') {

[marvin78]

In DbLog ist vieles seltsam und es wird nicht besser.

[ioT4db]

Nun, in Zeile 819 wird der text mit folgendem code gekürzt.

Code Auswählen Erweitern

$reading  = substr($reading,0, $columns{READING});
Wenn Du das für dich in

Code Auswählen Erweitern

$reading  = substr($reading,0, 1024);
änderst, sollte das vorerst gehen.

Warum genau dieses Kürzen der Readings hier gemacht wird, kann ich nicht einschätzen.... meiner Meinung nach sollte das MySQL selbst auch passend kürzen, wenn eine Spalte zu schmal ist.

das ging schnell, danke für die Info! Ich werde erst noch etwas warten, bevor ich die Zeile ändere. Vielleicht gabs nen wichtigen Grund!? Falls dieser für mich unrelevant ist, änder ich es in der Zeile...

[JoeALLb]

In DbLog ist vieles seltsam und es wird nicht besser.

Da halte ich dagegen: Es tun sich hier gerade wunderbare Weiterentwicklungen! Dafür bin ich Heiko sehr dankbar!!