Navigation

    Logo
    • Register
    • Login
    • Search
    • Recent
    • Tags
    • Unread
    • Categories
    • Unreplied
    • Popular
    • GitHub
    • Docu
    • Hilfe
    1. Home
    2. Deutsch
    3. ioBroker Allgemein
    4. SQL-adapter: Werte nicht gespeichert wegen 'duplicate entry'

    NEWS

    • Neuer Blog: Fotos und Eindrücke aus Solingen

    • ioBroker@Smart Living Forum Solingen, 14.06. - Agenda added

    • ioBroker goes Matter ... Matter Adapter in Stable

    SQL-adapter: Werte nicht gespeichert wegen 'duplicate entry'

    This topic has been deleted. Only users with topic management privileges can see it.
    • Homoran
      Homoran Global Moderator Administrators last edited by

      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

      1 Reply Last reply Reply Quote 0
      • A
        aquapro last edited by

        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

        1 Reply Last reply Reply Quote 0
        • sissiwup
          sissiwup last edited by

          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

          1 Reply Last reply Reply Quote 0
          • T
            tgirard last edited by

            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

            1 Reply Last reply Reply Quote 0
            • S
              Solear last edited by

              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.

              1 Reply Last reply Reply Quote 0
              • P
                Pman last edited by

                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.

                1 Reply Last reply Reply Quote 0
                • S
                  Solear last edited by

                  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?

                  1 Reply Last reply Reply Quote 0
                  • T
                    tp1de last edited by

                    Duplicate Key tritt bei mir bei Entprellzeit im Datenobjekt von 10 Sekunden auf !

                    Die Entprellzeit scheint also auch so nicht vollumfänglich zu funktionieren.

                    1 Reply Last reply Reply Quote 0
                    • S
                      Solear last edited by

                      @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.

                      1 Reply Last reply Reply Quote 0
                      • T
                        tp1de last edited by

                        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 !

                        1 Reply Last reply Reply Quote 0
                        • P
                          Pman last edited by

                          @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.

                          1 Reply Last reply Reply Quote 0
                          • First post
                            Last post

                          Support us

                          ioBroker
                          Community Adapters
                          Donate
                          FAQ Cloud / IOT
                          HowTo: Node.js-Update
                          HowTo: Backup/Restore
                          Downloads
                          BLOG

                          899
                          Online

                          31.9k
                          Users

                          80.1k
                          Topics

                          1.3m
                          Posts

                          8
                          14
                          1911
                          Loading More Posts
                          • Oldest to Newest
                          • Newest to Oldest
                          • Most Votes
                          Reply
                          • Reply as topic
                          Log in to reply
                          Community
                          Impressum | Datenschutz-Bestimmungen | Nutzungsbedingungen
                          The ioBroker Community 2014-2023
                          logo