SQL-adapter: Werte nicht gespeichert wegen 'duplicate entry'
-
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.
