Hallo zusammen,
die Logzeile
Zitat2021-03-07 20:24:45|general.system.notify.new_device|DOIF|warning: condition c01: (Missing operator before DECT_1?)|warning|condition c01|(Missing operator before DECT_1?
wirft bei
importCachefile (erwartungsgemäß) einen Fehler, da vermutlich anhand des | die Felder aufgelöst werden und so ein ungültiges SQL-Statement entsteht:
ZitatDBD::mysql::st execute failed: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'Unbekannt'', }',''),('2021-03-07 20:24:45','general.system.notify.new_device'...' at line 1 at ./FHEM/93_DbLog.pm line 1869.
So ist es Christoph.
Da müsste ich intern mal eine Maskierung von Pipe vornehmen ... dachte ich hätte es schon in der Vergangenheit gemacht.
Muss ich mal schauen ...
Zitat von: DS_Starter am 06 April 2021, 18:42:34
Da müsste ich intern mal eine Maskierung von Pipe vornehmen ... dachte ich hätte es schon in der Vergangenheit gemacht.
Muss ich mal schauen ...
Ich hatte schon versucht, die Pipes durch ihr Unicode-Codepoint zu ersetzen, aber das hat (auch halb erwartungsgemäß) nicht funktioniert.
Ich denke daran "|" intern in den relevanten Schritten in z.B. <PIPE> umzusetzen (und wieder return natürlich).
Würde sich dann auch auf Export/Import beziehen.
Dein exportiertes File könntest du dann wenn ich soweit bin über einen Filter jagen, "|" in <PIPE> umsetzen, und importieren.
Während des Imports wird an der richtigen Stelle <PIPE> in "|" konvertiert und in die DB geschrieben.
Muss ich ber erstmal alles umsetzen und testen.
Hallo Christoph,
ich hatte mich doch nicht getäuscht, das Pipe Zeichen ist bereits escaped in der Zeile 1399:
$event =~ s/\|/_ESC_/g;
Habe mir die Fehlerzeile nochmal genauer angeschaut.
Ich denke nicht dass es an den Pipe liegt, die Trennung der Felder sieht normal aus.
Ich denke es liegt an dem Standardspliiting über ":" nach "condition:".
Das passt in diesem Fall nicht. Hier müsste das Modul eine eigene DbLog_SplitFn nutzen, denn "condition c01: (Missing operator before DECT_1?)" ist kompett VALUE und darf nicht nochmal getrennt werden.
2021-03-07 20:24:45|general.system.notify.new_device|DOIF|warning: condition c01: (Missing operator before
TIMESTAMP DEVICE TYPE EVENT
DECT_1?)|warning|condition c01|(Missing operator before DECT_1?
READING VALUE UNIT
Hallo,
Zitat von: DS_Starter am 07 April 2021, 22:19:03
ich hatte mich doch nicht getäuscht, das Pipe Zeichen ist bereits escaped in der Zeile 1399:
$event =~ s/\|/_ESC_/g;
Habe mir die Fehlerzeile nochmal genauer angeschaut.
Ich denke nicht dass es an den Pipe liegt, die Trennung der Felder sieht normal aus.
Nur zu meinem Verständnis: Müsste dann in der Cache-Datei dann nicht auch das | verschwunden und durch _ESC_ ersetzt sein?
Zitat von: DS_Starter am 07 April 2021, 22:19:03
Ich denke es liegt an dem Standardspliiting über ":" nach "condition:".
Das passt in diesem Fall nicht. Hier müsste das Modul eine eigene DbLog_SplitFn nutzen, denn "condition c01: (Missing operator before DECT_1?)" ist kompett VALUE und darf nicht nochmal getrennt werden.
2021-03-07 20:24:45|general.system.notify.new_device|DOIF|warning: condition c01: (Missing operator before
TIMESTAMP DEVICE TYPE EVENT
DECT_1?)|warning|condition c01|(Missing operator before DECT_1?
READING VALUE UNIT
Hm, die müsste dann Damian in DOIF implementieren, oder?
Hi,
Zitat
Nur zu meinem Verständnis: Müsste dann in der Cache-Datei dann nicht auch das | verschwunden und durch _ESC_ ersetzt sein?
Ja, allerdings nur wenn | im Event vorkommen würde, also z.B. bei Event:
warning: condition c01 | (Missing operator before DECT_1?)
Daraus würde dann im Cache (und dem Exportfile):
warning: condition c01 _ESC_ (Missing operator before DECT_1?)
Später würde es dann wieder zurück verwandelt. Im Cache stehen nur die tatsächlichen Feldtrenner als "|" die nach dem Splitting identifiziert wurden.
Zitat
Hm, die müsste dann Damian in DOIF implementieren, oder?
Ja, genau. Alternativ das Reading/den Event "warning: condition c01: (Missing operator before DECT_1?)" besser gestalten, d.h. nach "condition c01" darf kein ": " kommen weil ": " die Standard-Splittingbedingung ist.
Vielleicht könnte ich auch im DbLog nachbessern und die Zeile 1083 "my @parts = split(/: /,$event);" umwandeln in:
my @parts = split(/: /,$event, 2);
Dann sollte es auch funktionieren. Bin mir nur unsicher ob die Änderung evtl. irgendwo Nebenwirkungen hat.
Werde es mal testen ... bei DbLog bin ich immer vorsichtig ;)
Am einfachsten/schnellsten wäre wenn Damian diesen Readinginhalt umändert.
Hallo Christoph,
ich habe das Standardsplitting in DBLog abgeändert wie oben geschrieben und kurz angetestet.
Sieht erstmal gut aus.
Teste doch bitte mal die V aus meinem contrib für eine längere Zeit.
Vielleicht erreichen wir dadurch das Ziel.
"wget -qO ./FHEM/93_DbLog.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbLog.pm"
Ich werde es bei mir auch erstmal laufen lassen und schauen ob mir etwas negatives auffallen sollte.
Grüße,
Heiko
Hallo!
Zitat von: DS_Starter am 08 April 2021, 22:39:36
Hi,
Ja, allerdings nur wenn | im Event vorkommen würde, also z.B. bei Event:
warning: condition c01 | (Missing operator before DECT_1?)
Daraus würde dann im Cache (und dem Exportfile):
warning: condition c01 _ESC_ (Missing operator before DECT_1?)
Das war aber bei mir nicht so! Im Cache-File standen die Pipes in der Fehlermeldung (die Regex-Trenner) plain text drin.
Hab mal die Version aus contrib eingespielt und schaue mal, ob ich den Fehler reproduzieren kann.
Dein Event
warning: condition c01: (Missing operator before DECT_1?)
enthält ja keine Pipes die hätten ersetzt werden müssen.
Naja, wir werden sehen ... ;)
Hallo Christoph,
gibts Erkenntnisse deinerseits ?
Bei mir habe ich mit der geringfügigen Änderung zumindest keine negativen Seiteneffekte erlebt.
Grüße,
Heiko
Habe bisher auch keine bemerkt, hatte aber auch noch keinen Fall, dass ein ,,fehlerhafter" Cache-File erzeugt wurde.