SQL.Adpter: Insert-Befehle innerhalb von 40ms

OliverIO

tja, wenn man das mal kann, liest man nicht regelmäßig die Referenz nach.:man-shrugging:

nettekov

Sorry für der Verzug:
IOBroker läuft auf einer DS718+ in einem virtuellen Linux
MariaDB läuft ebenfalls auf der DS718+

MariaDB : 10.3.29-0070
SQL-Adapter: v1.16.1

Ich habe auch mal die Datapoint aufgeräumt, da durch die Umbenennung der Alias -ID jedes Mal eine neue angelegt.
a
Auffällig hier auch , da die meistens Fehlermeldung bei ID >32 entstehen
Tabelle datapoints

Zuerst alle Datenpunkten mit ID >32 deaktiviert
Dann in allen Tabellen (datapoints, TS_counter, ts_number) alle Datensätze mit ID >32 gelöscht.
Danach die Datenpunkte wieder Aktiviert
Nachher: Tabelle datapoints:

Aber es gab keine Verbesserung.

Ich verstehe die Fehlermeldung des Datenbank-Server nicht.
Er sagt, dass es ein Syntax-Fehler gibt.
Wenn ich aber den Insert-Befehl aus der Fehlermeldung im php-Admin ausführe, dann ist alles in Ordnung.
Gibt so erstmal keinen Sinn.
Zusätzlich zum eigentlichen Insert-Befehl muss was zum DB-Server geschickt werden, was ihn aus dem Tritt bringt.

Gruss Nettekov

haus-automatisierung · MariaDB : 10.3.29-0070 SQL-Adapter: v1.16.1

@nettekov sagte in SQL.Adpter: Insert-Befehle innerhalb von 40ms:

SQL-Adapter: v1.16.1

2.2.0 ist stable. Bitte aktualisieren. Deine Version ist ja uralt. Da steige ich gar nicht erst in die Fehlersuche ein :)

@nettekov sagte in SQL.Adpter: Insert-Befehle innerhalb von 40ms:

IOBroker läuft auf einer DS718+ in einem virtuellen Linux

Du meinst einen Docker Container? Und die MariaDB läuft auch in einem Container? 10.3 läuft jetzt bald aus dem Support. Eventuell auch da mal ein Update machen (wird aber nichts mit dem Fehler zu tun haben).

nettekov

@haus-automatisierung
Ich bin noch nicht so affin im Iobroker.
Ich hatte in der Hitze des Gefechtes in den Instanzen nachgeschaut, dort stand v1.16.1 (Was das auch immer für eine Version das ist)

Bei den Adapter steht aber 2.2.0

Ich hatte auch, bevor ich dieses Thread erstellt habe, erstmal eine Rundrum Aktualiserung durchgeführt:

sudo apt update 
sudo apt full-upgrade
iob repo unset beta
iob update
iob upgrade
iob stop 
iob upgrade self
iob start

Da bin ich bei dir.
Bevor ich schreibt, sollte erstmal alles aktuell sein!

@haus-automatisierung sagte:

Du meinst einen Docker Container? Und die MariaDB läuft auch in einem Container? 10.3 läuft jetzt bald aus dem Support. Eventuell auch da mal ein Update machen (wird aber nichts mit dem Fehler zu tun haben).

Nee das virtuelle Linux läuft nicht im Docker Container, sondern Synology stellt auf der DS718+ zwei Virtuelle Maschinen zur Verfügung, wo Eine davon als virtuelles Linux mit ioBroker agiert.

Der Mariadb-Server läuft auch nicht im Container, sondern ist von Synology ein Paket, was von Synology selber Aktuell gehalten wird.

Bei Synology wird z.Z. als akuelle Version die 10.3.29-0070, ob wohl wir bei MariaDB schon bei 10.10.2; (17. November 2022)
sind.
Ich habe hier leider keine Einfluss, welche MariaDB-Version wird.

Generell glaube ich mehr daran, das die Ursache am DB-Server liegt, weil Diese trotz korrekter Syntax , dem Insert-Befehl als fehlerhaft anzeigt.

Sollten sie kein anderen Idee haben, würde ich vorschlagen, das ich die IObroker -DB exportieren und bei mir auf eine lokalen MYSQL-Server(XAMPP) importiere und laufen lasse . Hier habe ich dann auch die Möglichkeit über Wireshark den Datenverkehr zu analysieren.

@haus-automatisierung : Wie ist deine Meinung?

Gruss Nettekov

haus-automatisierung

@nettekov sagte in SQL.Adpter: Insert-Befehle innerhalb von 40ms:

Bei Synology wird z.Z. als akuelle Version die 10.3.29-0070, ob wohl wir bei MariaDB schon bei 10.10.2; (17. November 2022)

Stimmt, wird mir auch nur angeboten. Denke mal die werden das Paket dann vor EOL auch aktualisieren. Glaube aber wie gesagt nicht, dass das das Problem ist und würde erstmal dabei bleiben. Ist ja nun ein ganz einfacher INSERT, welcher seit 20+ Jahren so funktioniert :)

Hast Du den SQL-Adapter denn jetzt auf Version 2.2.0? Besteht damit nach wie vor das gleiche Problem?

Codierknecht

@nettekov
Just for info:
Ich betreibe das Ganze mit so ziemlich dem gleichen Setup. ioBroker im Container und MariaDB 10.3.7-0051 als natives Synology-Paket.

Diesen seltsamen Effekt konnte ich aber bislang noch nie beobachten.

nettekov

Hallo zusammen,

Der SQL-Adapter ist laut der Versionsamgabe in Adapterbereich auf 2.2.0

Ein wichtiges Detail habe ich aber vergessen zu erwähnen, die Fehlermeldung fingen an, als ich die zwei neugekauufen Temperatur - Sensoren von Aquara ins Zigee-Netz einsetze und das Dazenloggon dort aktiviert habe.

[Aqara Smart Luftdruck Temperatur Feuchtigkeit Umwelt Aqara Sensor] (https://a.aliexpress.com/_mLSqnrG)

Die Fehlermeldung bleiben aber weitgehenst bei den beiden Sensoren.
Vorher lief das Loggen monatelang ohne Probleme

Gruß Nettekov

Codierknecht

@nettekov sagte in SQL.Adpter: Insert-Befehle innerhalb von 40ms:

die Fehlermeldung fingen an, als ich die zwei neugekauufen Temperatur - Sensoren von Aquara ins Zigee-Netz einsetze und das Dazenloggon dort aktiviert habe

Das dürften die sein die ich auch einsetze.

Ich logge aber nicht direkt deren DP, sondern die Alias-DP die ich für alle meine Temperatur-/Feuchte-Sensoren angelegt habe.

nettekov

@codierknecht said in SQL.Adpter: Insert-Befehle innerhalb von 40ms:

Das dürften die sein die ich auch einsetze.

Jepp , ich habe die selben Sensoren. Ich verwenden auch Alias-ID

ich habe auch beim DP die Entprellzeit auf 5Sec und die Blockzeit auf 6sec, mit dem Gedank, das er zuviel Datensätze bekommen, was aber für ein DB-Server eigentlich kein Problem darstellt.

Die Frage ist, warum der DB-Server bei einem korrekten Insert -Befehl die Syntax als Fehler mukiert.
Wenn ich denn komplette Insert-Befehl aus der Fehlermeldung über PHP-ADMIN einspiele, ist alles OK.

@haus-automatisierung Ich stimmt dir zu , das der DB-Server wahrscheinlich keine Fehler hat, aber entweder wir irgendwas mit gesendet, was die Fehlermeldung nicht anzeigt oder vielleicht es wir durch zu eine geringen Eingangsbuffer, was weggeschnitten, wenn zuviel Befehle in einer Transaktion gesendet werden.

Aber das ist alles nur eine Spekulation.

Gruss Nettekov

haus-automatisierung

@nettekov Eventuell ist auch das @ im Alias ein Problem. Mit solchen Sonderzeichen bin ich bei Datenbanken immer vorsichtig ;) Wobei das ja eigentlich über Fremschlüssel gelöst wird und in dem Insert gar nicht enthalten ist.

nettekov

Hallo zusammen,
@haus-automatisierung Habe ich auch gedacht, aber 5 weitere Sensor verwenden auch in der Alias-ID den

und hier gib es bis jetzt die Probleme nicht.

Ich habe mir gestern mit Wireshark die Netzwerk-Protokolle angeschaut und habe einen kleinen Anhaltspunkt gefunden.
ich bin wie folgt vorgegangen:

Ich habe die IOBROKER-DB aus der Synology exportiert
Auf meine lokalen MYSQL-Server(XAMPP) importiert und mit den SQL-Adapter verbunden.
Gleichzeitig lasse ich Wireshark parallel laufen
Die DP-ID 47,48,49 ist einer von den neue Aquara_Sensoren, der hauptsächlich die Probleme macht

Ergebnis:
Die selben Probleme treten auf mit dem MYSQL Server auf. Also kann es ein DB-Server spezifisches Problem nicht sein

Auffällig hier, alle INSERT-Statements von den anderen DP (<>ID47-49) haben eine typische Protokolllänge ca.160Bytes

Wenn von den DP47-49 INSERT-Statements, dann haben Diese ein Länge von 250-400 Bytes, teils werden die SQL-Statement TRUNCATED

Witzigerweise, wenn ich diese INSERT-Sequenzen aus den Protokoll kopieren und lasse Diese mit PHP-Admin oder HeidiSQL ausführen, gehen sie alle als OK durch und werden gespeichert.

Ich packe mal ein paar Screenshots dazu, vielleicht habt ihr eine Idee, bzw wie ist eure Meinung dazu

Gruss Nettekov

1.Iobroker-Protokoll:

Normaler DP mit ID 9 , der keine Probleme machen und eine Länge von 160 Byte hat.
Fehler A: ID 48 mit Länge von 387 und ist truncated
Fehler B: ID 47 mit Länge von 340 und ist truncated
Hier ist die ID 49 mal ohne Fehler durchgegangen
Generell kann sagen, die meisten DP kommen mit eine Protokolllänge von unter 200Byte.
Nur die AQuara -Sensor fassen anscheinend mehrere Messwert zusammen, so das in den meinsten Fälle dann die Protokolllänge über 250Byte.

OliverIO

@nettekov

Kannst du bitte mal prüfen, ob bei diesen datenpunkten in den sql Einstellungen ein Kreuzchen bei Zähler gesetzt ist? Und bei den anderen nicht?

Mir ist aufgefallen, das manchmal noch ein weiteres insert für die Tabelle Counter mit drin steht. Das könnte die größere Länge erklären.

Allerdings nicht den Syntax Fehler.
Auch im Code des Adapters ist da nicht viel spannendes drin.

https://github.com/ioBroker/ioBroker.sql/blob/64606a7c897adc741499572c7fbefb1af42f5063/main.js#L1524

In der Fehleranmeldung wird erst die query die versendet wird ausgegeben und dann die Fehlermeldung die von der dB zurückkommt.
Die ist allerdings nicht immer vollständig im log ausgegeben.

Da bitte mal noch in die Iobroker log Datei auf der Festplatte nachschauen, nicht das die Iobroker Oberfläche hier was abschneidet was man dann nicht sieht.

Wenn das nichts ergibt, dann noch das logging auf db Seite erweitern um zu schauen was da tatsächlich ankommt.

nettekov

@OliverIO Beiden DI-ID 47-49 (neuer Aquara-Sensor) ist der Haken Zähler gesetzt. Bei den anderen DP nicht durchgängig gesetzt , aber die Meisten.

Die Fehlermeldung wird vom SQL-Server abgeschnitten:

Gruss Nettekov

nettekov

Hallo zusammen,

nach dem ich eine Nacht darüber geschlafen habe, haben sich die Dinge im Kopf mal zusammengefasst.
Das Auslösen des Problems sind zwar die neuen Aquara-Sensor, weil Diese anscheinend mehrere Werte gleichzeitig schicken und somit der SQL-Adapter in eine INSERT-Befehl mehrere (3-5) Datensätze zusammenfasst, was zu der Fehlermeldung führt.
Allerdings sollte das jeder SQL-Server Händeln können und zu keinem Fehler führen.

Ich denke auch, das die Syntax-Fehlermeldung von beiden Server richtig sond, allerdings nicht ihm SQL-Statement , sondern in der Parametrierung der MySQL-Protokoll-Frames, das Diese z.B. auf eine kurzes SQL-Statement einstellen, was dann zu lange ist.

Ich werden heute oder morgen , den INSERT-Befehl aus einen fehlerhaften Protokoll kopieren und in HeidiSQL nochmal ausführen und dann beide MySql-Protokolle vergleichen
Da muss es ja einen Unterschied geben.

Wie ist eure Meinung.

Gruss Nettekov

haus-automatisierung

@nettekov sagte in SQL.Adpter: Insert-Befehle innerhalb von 40ms:

Ich werden heute oder morgen , den INSERT-Befehl aus einen fehlerhaften Protokoll kopieren und in HeidiSQL nochmal ausführen und dann beide MySql-Protokolle vergleichen
Da muss es ja einen Unterschied geben.

Bevor Du das machst, würde ich an Deiner Stelle eher ein kurzes nodejs script schreiben, welches genau die gleiche Library verwendet wie der Adapter und einfach mal das Statement von dort senden. Tritt der Fehler dann auch auf, kann man das viel einfacher eingrenzen.

nettekov

@haus-automatisierung: Können wir gerne machen. Bin halt in Linux nicht ganz fit, da ich eher von der Windows-Welt komme.
Sagt mir, wo ich es hin kopieren soll und wie ich es aufrufen kann.

Gruss nettekov

OliverIO

@nettekov

ok, also der db meldet nicht den kompletten fehler.
jetzt noch was bei der db tatsächlich ankommt.

das kann man über das general query log aktivieren.
da werden dann alle query requests reingeschrieben.
https://mariadb.com/kb/en/general-query-log/

die befehle kannst du entweder über den client auf dem rechner ausführen (auf der shell mysql eingeben, auch wenn du mariadb verwendest)
oder auch aus heidisql.
da genau so eingeben wie die normalen queries.

falls du mehr konfigurieren willst, dann kannst du es auch in der normalen
konfig datei /etc/mysql/my.cnf machen

weiterhin kannst du auch mal das error log von mariadb/mysql anschauen oder erweitern. aber da dürfte nix anderes drin stehen.
ich denke, der befehl der wirklich ankommt ist erst mal interessant
https://mariadb.com/kb/en/error-log/

nettekov

Hallo zusammen,

@OliverIO : Ich habe gestern mal nachgeschaut. Bei der Synology NAS, wo die MariaDB als Paket installiert ist, keine Möglichkeit gefunden , irgendwelche Log zu akivieren, weil es nicht angeboten wird

Vielleich über PHPmyadmin, kann ich nochmal nachschauen.
Bei MYsql über XAMPP sieht es nicht viel besser aus.

@haus-automatisierung : Du hast angeboten , ein extra Nodejs zu erstellen. Steht dein Angebot noch?

Gruss Stefan

haus-automatisierung

@nettekov sagte in SQL.Adpter: Insert-Befehle innerhalb von 40ms:

@haus-automatisierung : Du hast angeboten , ein extra Nodejs zu erstellen. Steht dein Angebot noch?

Das war unglücklich formuliert. Ich meinte, dass ich das so machen würde um den Fehler zu finden.

nettekov

@haus-automatisierung Wäre das das module-Verzeichnis für den SQL.Adapter

Kann ich aus Linux(putty) ein javascript starten, was ein SQL-Statement abschickt?
Wenn ja, könnt ihr mir kurz erklären wie?

oder soll ich auf dem Webserver eine HTML -Seite erstellen, was das java-script ausführt.

Gruss Nettekov

Community Forum

NEWS

SQL.Adpter: Insert-Befehle innerhalb von 40ms

Support us

744

32.5k

81.7k

1.3m