SQL-adapter: Werte nicht gespeichert wegen 'duplicate entry'
-
Guten Morgen!
vielleicht kann mir jemand helfen? Ich habe eine mySql Datenbank auf einem bananaPi. Leider speichert seit einigen Tagen der sql-Adapter mehrere Daten nicht mehr. Das log ist voll mit Einträgen wie:
sql-0 2016-03-25 08:01:27 error Cannot insert INSERT INTO iobroker.ts_number (id, ts, val, ack, _from, q) VALUES(255, 1458889278000, 0.4, 1, 46, 0);: Error: ER_DUP_ENTRY: Duplicate entry '255-1458889278000' for key 'PRIMARY'
Ich habe dann den Inhalt der Tabelle ts_number gelöscht. Aber das Problem taucht sofort wieder auf.
Wäre um Hilfe sehr dankbar!
schöne Ostern
Thierry
-
Hmmm hat niemand eine gute Idee ? Mein Log ist 'zugemüllt' mit 'Duplicate entry'. Ich habe die Tabellen in MySQL gelöscht, die ganzen History Einstellungen gelöscht und alles nochmals installiert und es geht genau gleich weiter. Das ist echt schade, denn die log Funktion war ein wichtiges Argument, kann ich jetzt aber nicht benutzen, weil gerade bei den Heizungsventilen .valve überhaupt kein Wert mehr gespeichert wird.
Danke für Unterstützung / Ideen
Thierry
-
Hi,
ich habe das gleiche Problem!
Bin für Hilfe dankbar.
Viele Grüße
Trident
-
Hallo Thierry,
ich habe leider noch keine Ahnung von SQL-Datenbanken und daher auch nicht mit dem SQL-Adapter.
Daher kann ich nur versuchen mit Fragen evtl. in die Richtung zu zeigen
Wenn ich das Log richtig verstehe existiert in der Datenbank ein Primärschlüssel (primary key).
Dieser wird doppelt vergeben und so kommt es zu dem Fehler.
Was ist das für ein Datenfeld - und wer legt es an? (Struktur und Inhalt)
Anscheinend setzt sich dieser Schlüssel aus id und ts zusammen.
Was sind das für werte? (255, 1458889278000) (ts=timestamp?)
Gruß
Rainer
-
Jip, ist timestamp. Und er ist kurz und dadurch könnte es zu doppelten Einträgen kommen.
Aber gab es da nicht schon mal eine Diskussion.
Schau mal http://forum.iobroker.net/viewtopic.php?f=23&t=1776, da ging es dann auch um lock, wegen gleichen Einträgen.
Gruß
Tino
-
Hallo,
der BananaPI kann keine Millisekunden auflösen (siehe letzte 000 im TS).
Deshalb kann es keine zwei Werte in der gleichen Sekunde geben.
Kommt bei mir auch ab und an vor, könnte man durch globalen Zähler beim berechnen des TS lösen.
Ich glaube ist im Code auch schon kommentiert, dass da noch was zu tun ist.
Nach dem Motto, wenn aktueller TS = letzter TS dann aktuelle TS=aktueller TS + ++globaler Zähler
-
Danke an alle! Ich glaube ich habe es jetzt verstanden:
1. die fehlenden Werte bei den zwei Thermostaten hatte nix mit den duplicate entries zu tun. Habe die Firmware von 1.3 auf 1.4 erhöht, jetzt gehts.
2. Die doppelten Werte habe ich noch immer, bin aber der ID nachgegangen und es handelt sich um Speicher und Auslastung von Raspberry und Banana-Pi. Diese werden nicht alle 10'000 Millisekunden, sondern häufiger gesendet. Wenn der Timestamp immer noch der gleiche ist, gibt es eine Fehlermeldung (welche aber wohl gar nicht relevant ist).
beste Grüsse
Thierry
-
Hallo,
ich habe dasselbe Problem. Mein Log wird zugemüllt mit EInträgen wie
sql-0 2016-04-25 18:37:19 error Cannot insert INSERT INTO iobroker.ts_number (id, ts, val, ack, _from, q) VALUES(6, 1461602239000, 6.83, 0, 2, 0);: Error: ER_DUP_ENTRY: Duplicate entry '6-1461602239000' for key 'PRIMARY' sql-0 2016-04-25 18:37:19 error Cannot insert INSERT INTO iobroker.ts_number (id, ts, val, ack, _from, q) VALUES(5, 1461602239000, 60, 0, 2, 0);: Error: ER_DUP_ENTRY: Duplicate entry '5-1461602239000' for key 'PRIMARY' sql-0 2016-04-25 18:34:54 error Cannot insert INSERT INTO iobroker.ts_number (id, ts, val, ack, _from, q) VALUES(6, 1461602094000, 6.94, 0, 2, 0);: Error: ER_DUP_ENTRY: Duplicate entry '6-1461602094000' for key 'PRIMARY' sql-0 2016-04-25 18:34:54 error Cannot insert INSERT INTO iobroker.ts_number (id, ts, val, ack, _from, q) VALUES(5, 1461602094000, 61, 0, 2, 0);: Error: ER_DUP_ENTRY: Duplicate entry '5-1461602094000' for key 'PRIMARY'Was kann ich tun? So wie ich das versteh sind die Meldungen harmlos, sie besagen scheinbar nur, dass sich der Wert noch nicht geändert hat, aber es ist nicht schön wenn mein ganzes Log rot ist.
-
Der Fehler tritt auf wenn ein Datenpunkt zwei mal in der selben Sekunde geändert wird, da nur History-ID und Timestamp als Primary key definiert sind, ein Primary key kann es aber nur einmal geben, also kann der zweite Wert nicht gespeichert werden!
Workaround:
- Entprellzeit über 1000 ms einstellen
Lösungen:
- Entprellzeit unter 1000 ms verbieten
=> schlechte Lösung
- REPLACE statt INSERT
=> schlechte Lösung, die zwar die Fehler im LOG beseitigt, aber trotzdem inkorrekt ist, da dabei ein Wert überschrieben wird. Es ist ein Sensor oder anderer Datenpunkt vorstellbar welcher seinen Wert sehr schnell ändert, dieser könnte von History nicht korrekt erfasst werden.
- Millisekunden implementieren
=> erhöht zwar die zeitliche Auflösung, behebt aber nicht das eigentliche Problem. Änderungen innerhalb einer Millisekunde können trotzdem nicht erfasst werden.
- SQL-Schema erweitern
=> meiner Meinung nach der einzig richtige Weg. Eine mögliche Erweiterung wäre das hinzufügen einer Spalte "counter INT" zur Tabelle und zum Primary Key. Counter wird standardmäßig mit 0 beschrieben, bei duplicate key error wird er um 1 erhöht. Beim Abrufen wird nach TS und Counter sortiert.
-
Vielen Dank!
Habe jetzt die Entprellzeit überall auf 10000 ms (10 Sekunden) gestellt.
Das war zwar im SQL-Adapter voreingestellt, hat er auch für die hm-rpc-Historieeinstellungen übernommen, aber bei den Javascripts hat er überall eine Entprellzeit von 0 gehabt. Das habe ich beim aktivieren übersehen.
Könnte ein Bug sein, dass beim Javascriptadapter die Voreinstellungen vom SQL-Adapter beim Einstellen nicht als Voreinstellung übernommen werden?
-
Duplicate Key tritt bei mir bei Entprellzeit im Datenobjekt von 10 Sekunden auf !
Die Entprellzeit scheint also auch so nicht vollumfänglich zu funktionieren.
-
@tom57:Duplicate Key tritt bei mir bei Entprellzeit im Datenobjekt von 10 Sekunden auf !
Die Entprellzeit scheint also auch so nicht vollumfänglich zu funktionieren. `
Sind alle Objekte mit 10000 angegeben? Schau sie mal durch, bei mir waren ein paar mit 0 dabei unter Javascript.
-
Die Polling-Zeiten für Eingänge (Analoge / Digitale) liegen bei vielen Millisekunden.
Beim Piface bei 250 mS. Die Umstellung auf genaue Zeit mit Millisekunden würde reichen.
Ich schreibe ca. 30-35.000 Sätze in die DB pro Tag. Dabei habe ich aber keinen Anspruch mehrere Einträge pro Sekunde zu schreiben.
Das Datenobjekt um das es sich handelt ist bei mir ein digitaler Eingang des Piface Bord. Der Eingang wird über ein 220V Relais belegt.
Ich vermute mal, dass das Schalt-Jitter vom Relais ist. In dem Fall scheint die Entprellzeit nicht zu greifen.
Alle Datenpunkte mit 10 Sekunden !
-
@tom57:Die Polling-Zeiten für Eingänge (Analoge / Digitale) liegen bei vielen Millisekunden.
Beim Piface bei 250 mS. Die Umstellung auf genaue Zeit mit Millisekunden würde reichen.
Ich schreibe ca. 30-35.000 Sätze in die DB pro Tag. Dabei habe ich aber keinen Anspruch mehrere Einträge pro Sekunde zu schreiben.
Das Datenobjekt um das es sich handelt ist bei mir ein digitaler Eingang des Piface Bord. Der Eingang wird über ein 220V Relais belegt.
Ich vermute mal, dass das Schalt-Jitter vom Relais ist. In dem Fall scheint die Entprellzeit nicht zu greifen.
Alle Datenpunkte mit 10 Sekunden ! `
Mag sein, dass es mit Millisekunden für dich funktionieren würde aber es sollte schon für alle denkbaren Anwendungen funktionieren.
