DBLog - unrecognized token (SQLite)

[hmtec99]

Hallo Leute,

bin gerade dabei von Filelog auf DBLog umzustellen. Funktioniert soweit auch, allerdings bekomme ich folgenden Fehler beim Änderung der Heizungstemperatur über ein Nextion-Display:

DBD::SQLite::db prepare failed: unrecognized token: "'rectext: $a1=ku_heizung_ruheq
" at ./FHEM/93_DbLog.pm line 2404 (kopiert aus FHEMWEB).

Danach stellt das Logging bis zum nächsten Neustart von FHEM die Funktion ein.

Hintergrund: Das Kommando ($a1=ku_heizung_ruheq) wird vom Display an FHEM gesendet (Modul Nextion) und nach Auslösung der entsprechenden Aktion (myUtils) in eine Datei geschrieben.
Diese wird dann von den Displays beim Aufwachen eingelesen.

Hat jemand eine Idee? Vielleicht ein Problem mit Sonderzeichen?

Gruß, Oliver

[DS_Starter]

Hallo Oliver,

das ist mit großer Wahrscheinlichkeit ein Problem mit dem "$" im $a1.
Es wird als Variable gewertet.

Kennst du das Attribut valuFn im DbLog ?

Setzt dir das mal auf:

Code Auswählen Erweitern


{
if ($VALUE =~ /$/){
    $VALUE =~ s,$,\$,g;
  }
}


Das soll das $ maskieren. Möglicherweise ist die Syntax noch nicht ganz korrekt ... mal probieren bitte.

Grüße,
Heiko

[hmtec99]

Danke für den Hinweis.

Hat allerdings nix gebracht.

ist es vielleicht das Hochkomma nach den Anführungszeichen oder werden die von DBLog eingefügt?

DBD::SQLite::db prepare failed: unrecognized token: "'rectext: $a1=ku_heizung_ruheq
"

[DS_Starter]

ist es vielleicht das Hochkomma nach den Anführungszeichen oder werden die von DBLog eingefügt?

Ja, du hast recht. Das wird es sein. Es wird von DbLog nicht eingefügt, aber normalerweise escaped. Hast du die aktuellste DbLog-Version ?

Wenn du verbose 5 einschaltest, gibt es Einträge der Art:

Code Auswählen Erweitern


DbLog <name> -> processing event Timestamp: ....


Dort müsste dein Term 'rectext: $a1=ku_heizung_ruheq  (nur mit einem Hochkomma) auftauchen.
Außerdem könntest du sicherheitshalber noch das Attribut "useCharfilter" im DbLog setzen um eventuell vorhandene Steuerzeichen zu entfernen.

Grüße,
Heiko

Vermutlich muss ich es bei mir mal versuchen nachzustellen, aber heute nicht mehr. 

[DS_Starter]

Hallo Oliver,

bist du weitergekommen ?
Wenn nicht, teste mal bitte auch die Version aus diesem Beitrag: https://forum.fhem.de/index.php/topic,106992.msg1008642.html#msg1008642

Grüße,
Heiko

[khk123]

Hi Heiko,

ist zwar ein alter Thread, aber bei mir tauchte das Problem mit dem $-Zeichen gestern auch auf.

Code Auswählen Erweitern


DBD::SQLite::db prepare failed: unrecognized token: "$" at ./FHEM/93_DbLog.pm line 2453.

Auslöser war wohl eine fehlerhafte Formatierung in einem JSONMOD-Device.
Daraufhin hatte ich deinen alten Vorschlag mit Attribut valuFn eingesetzt.

Code Auswählen Erweitern

{
if ($VALUE =~ /$/){
    $VALUE =~ s,$,\$,g;
  }
}

Danach wurde aber an alle VALUE-Felder ein $-Zeichen angehängt und alle SVGs, die numerische Werte erwarteten, meldeten Fehler:

Code Auswählen Erweitern


2021.04.11 12:01:02 1: PERL WARNING: Argument "21.7$" isn't numeric in numeric gt (>) at ./FHEM/98_SVG.pm line 1591.
2021.04.11 12:01:02 1: PERL WARNING: Argument "22.0$" isn't numeric in numeric gt (>) at ./FHEM/98_SVG.pm line 1591.
2021.04.11 12:01:02 1: PERL WARNING: Argument "21.1$" isn't numeric in numeric gt (>) at ./FHEM/98_SVG.pm line 1591.


Habs mittlerweile wieder rausgenommen und mit 

Code Auswählen Erweitern


set DbRep sqlCmd update history set VALUE = REPLACE(VALUE,"$","")

die VALUE-Felder wieder korrigiert. Mein Fall ist daher behoben, aber das Problem mit dem $-Zeichen besteht anscheinend immer noch.

VG
Karlheinz

[DS_Starter]

Hallo Karlheinz,

wenn man das $ völlig eliminieren will, wäre dann der Workaround im Attribut valuFn z.B. so:

Code Auswählen Erweitern


{
if ($VALUE =~ /$/){
    $VALUE =~ s,$,,g;
  }
}


Dann fliegt das Zeichen raus.
In Verbindung mit SVG muss man natürlich schauen, dass man sauber numerische Werte loggt. Es gibt auch viele Varianten um bei der Anzeige im SVG mit nichtnumerischen Zeichen umzugehen und diese zu eliminieren oder umzuwandeln.
Am einfachsten ist es aber gleich sauber loggen.
Das muss am Besten gleich an der Quelle passieren, d.h. die zu loggenden Readings/Events müssten idealerweise so aussehen wie sie sollen.

LG,
Heiko

[khk123]

Hallo Heiko,

danke für die schnelle Antwort. Das Problem war ja durch eine fehlerhafte Definition meinerseits entstanden und ist mittlerweile korrigiert. Wollte nur den Hinweis geben, dass der alte Vorschlag mit valueFn Probleme verursachen kann und dass das $-Zeichen-Problem noch vorhanden ist. Ansonsten bin ich ebenfalls der Meinung, dass das Loggen gleich richtig erfolgen sollte.

VG
Karlheinz