[Aufruf] Dringender Test sql 1.6.4
-
Zeitpunkte sind identisch?
Beende mal die Instanz. Schau das dann keine mehr läuft (ps auxww|grep sql) und Starte neu. Dann immer noch? `
Habe die Instanz im Admin beendet und deinen Befehl in der Konsole eingegeben. Ausgabe lautet:
Kann das Ergebnis nicht interpretieren. Ich starte die Instanz im ioBroker jetzt wieder und berichte weiter.
Danke dir und VG, Thorsten
PS: Auszug aus dem log. Weiß nicht ob das hilft. Sieht normal aus:
! ` > sql.0 2018-02-01 20:56:27.062 info Connected to mysql
sql.0 2018-02-01 20:56:26.993 info enabled logging of mihome.0.devices.sensor_ht_158d000149c2cc.humidity
sql.0 2018-02-01 20:56:26.992 info enabled logging of mihome.0.devices.sensor_ht_158d000149c2cc.temperature
sql.0 2018-02-01 20:56:26.991 info enabled logging of javascript.0.Speed-Test.data.speeds.upload
sql.0 2018-02-01 20:56:26.991 info enabled logging of javascript.0.Speed-Test.data.speeds.download
sql.0 2018-02-01 20:56:26.991 info enabled logging of javascript.0.Speed-Test.ping
sql.0 2018-02-01 20:56:26.990 info enabled logging of ping.1.raspberrypi3.www_google_de
sql.0 2018-02-01 20:56:26.990 info enabled logging of zwave.0.NODE14.SENSOR_MULTILEVEL.Temperature_1
sql.0 2018-02-01 20:56:26.990 info enabled logging of zwave.0.NODE12.SENSOR_MULTILEVEL.Temperature_1
sql.0 2018-02-01 20:56:26.988 info enabled logging of zwave.0.NODE11.SENSOR_MULTILEVEL.Temperature_1
sql.0 2018-02-01 20:56:26.987 info enabled logging of tankerkoenig.0.stations.0.e5.short
sql.0 2018-02-01 20:56:26.986 info enabled logging of tankerkoenig.0.stations.1.e5.short
sql.0 2018-02-01 20:56:26.985 info enabled logging of tankerkoenig.0.stations.2.e5.short
sql.0 2018-02-01 20:56:26.984 info enabled logging of tankerkoenig.0.stations.3.e5.short
sql.0 2018-02-01 20:56:26.980 info enabled logging of rpi2.0.temperature.soc_temp
sql.0 2018-02-01 20:56:26.455 info starting. Version 1.6.5 in /opt/iobroker/node_modules/iobroker.sql, node: v4.8.3
host.raspberrypi3 2018-02-01 20:56:23.065 info instance system.adapter.sql.0 started with pid 17100 `
-
Keine zweite Instanz. Komisch … schau mal
-
Hatte auch noch die ältere SQL laufen. Versuche gerade Mal wieder ein Update über die Konsole. Nehme deinen Adapter von Git… Man irgendwie dauert das so lang. Unterbreche jetzt Mal nicht mit Strg+c. Vielleicht bringt das was und läuft irgendwann durch. Man kann ja leider in PuTTY nicht erkennen, ob der Pi sich aufgegangen hat...
Ich berichte weiter...
Gesendet von meinem HUAWEI RIO-L01 mit Tapatalk
-
1.6.7 funktioniert bei mir nicht. Alles nur null Einträge, obwohl String-Werte. So sollte das nicht produktiv gesetzt werden.
(Siehe dazu meinen gesonderten Eintrag).
Hier sollte für Altnutzer ein vernünftiger Migrationspfad gewählt werden.
-
Siehe anderer Thread. Kann es sein das du in 2.6.1 diese Datenpunkte tun logging erst aktiviert hast?
Neue Werte sollten wenn du nichts tust in der String Tabelle landen und damit sollten an sich tun. Nur alte Werte aus der 1.6.1 Zeit sind „weg“ -es sei denn du fixt es manuell. Ich habe keinen Weg gefunden es automatisch zu fixen. Da die 1.6.1 auch „nur“ ein paar Tage live war habe ich mich für diesen Weg entschieden.
Ps: migrationspfade bei bugfixes sind eher schwierig …
-
Pps: den migrationspfad gibt es ja … diese erster Beitrag hier. Speichern als setzen auf korrekten Typ. Dann sollten die Daten zurück sein
-
Pps: den migrationspfad gibt es ja … diese erster Beitrag hier. Speichern als setzen auf korrekten Typ. Dann sollten die Daten zurück sein `
Naja, wie repariere ich das denn nachhaltig? Ich habe seit 1.6.1 ca. 100 neue Datenpunkte. Wie erkenne ich welche defekt sind.
Habe die auf Zeichenfolge geändert. Wenn ich danach wieder auf automatisch gehe sind sie aber wieder kaputt.
Kann ich das in der Tabelle irgendwie anpassen?
-
Dazu wurde auch die Art und Weise wie der "Datentyp" ermittelt wird komplett überarbeitet und funktioniert jetzt so:
-
Wenn in der SQL-Konfig des Datenpunkts unter "Speichern als" ein Datentyp gesetzt ist, gewinnt dieser immer und die Daten werden so geloggt. Falls in der Datenbank ein anderer Typ steht wird der DB-Typ korrigiert!
-
Ansonsten wird geschaut ob schon ein Typ in der Datenbank steht und wenn ja wird dieser genutzt. Das kann mit oben genanntem Problem 1 pot. komische Effekte haben. Dazu gleich mehr.
-
Wenn kein Typ in der DB steht (also eher bei neuen Datenpunkten) dann wird im ioBroker-Objekt nach dem Typ geschaut und dieser genommen. `
Hallo, das "DB-Typ wird korrigiert" scheint nicht zu funktionieren.
Was habe ich gemacht:
Habe einen Datenpunkt auf "Zeichenkette" gestellt (in DB als Typ 1).
Dann hätte sich ja der DB-Typ laut deiner Aussage oben korrigieren müssen.
In der DB steht aber immer noch Typ 1
Habe dann den Datenpunkt wieder auf "Automatisch" gestellt. Damit war das Problem der Anzeige und des loggens wieder da.
Habe in der Datenbank den DB-Typ auf 0 gesetzt.
SQl-Adapter neu gestartet. Hat aber auch nichts gebracht?
-
-
Dann bitte „speichern als“ so setzen wie es Sein soll. Er sollte beim ersten zu loggenden wert das korrigieren wenn es abweicht. Wenn er das nicht tut bitte Debug log als pn vom Start und bis zum ersten Mal wo Daten neu gespeichert werden schicken und sagen welcher dp es ist. Dann schaue ich ins log. Bei mir tut die Korrektur. Im Notfall einfach das speichern als so lassen
Wie du es erkennst … leider gar nicht
ich wüsste nicht wie. Das ist das Problem dieses bugs. -
Ich habe eine Idee. Lass mich später mal ne kleine Änderung machen,m dann könnte man versuchen in der DB die Typen alle auf "null" zu setzen und der Adapter könnte SIe dann beim ersten Speichern von Daten neu auf den "Speichern als" ODER "Objekt-Typ" setzen … je nachdem was vorher war passt das vllt nicht 100% aber könnte einige fixen ... Wäre ein experiment wenn du es versuchen willst. Verspreche aber nichts weil ich es selbst nicht testen kann
-
Also sissiwup,
ich hab auf Github mal eine Kleinigkeit geändert.
Wenn die "eigentlich richtigen typen" denen der ioBroker-Objekte entsprechen (was meistens der Fall sein sollte) dann kann man jetzt in der "datapoints"-tabelle die "type"-SPalte auf NULL setzen und beim nächsten Start bzw beim ersten Loggen von Daten sollte der korrekte Typ aktualisiert werden.
Am besten erstmal mit 1-2 Datenpunkten versuchen bevor du alle Typen killst
Ist das vllt ein "Fix" ?!
-
Also sissiwup,
ich hab auf Github mal eine Kleinigkeit geändert.
Wenn die "eigentlich richtigen typen" denen der ioBroker-Objekte entsprechen (was meistens der Fall sein sollte) dann kann man jetzt in der "datapoints"-tabelle die "type"-SPalte auf NULL setzen und beim nächsten Start bzw beim ersten Loggen von Daten sollte der korrekte Typ aktualisiert werden.
Am besten erstmal mit 1-2 Datenpunkten versuchen bevor du alle Typen killst
Ist das vllt ein "Fix" ?! `
Hallo, probiere ich heute Abend aus. Danke.
-
Hallo,
ein merkwürdiges Problem:
Auswirkungen: Es werden wieder ein paar Null Werte in die Tabelle geschrieben.
Das passiert nur beim Neustart des ioBrokers (Mache ich jede Nacht um 4:00 zur Datensicherung)
Danach ist alles wieder stabil. War vorher nicht so, da hat er wenigstens keine "NULL" Werte geschrieben.
Lösche ich aktuell mit:
DELETE FROM `ts_string` WHERE q = 64;64 steht wohl für vom Adapter geraten …
Kann ich das irgendwie verhindern, das er das macht?
Ich habe das jetzt erstmal über einen Trigger verhindert:
CREATE DEFINER=`root`@`localhost` TRIGGER `DEL_NULL` BEFORE INSERT ON `ts_string` FOR EACH ROW if NEW.val = NULL then set NEW.id = NULL; end if -
Die null Werte sind Absicht. Beim stop der sql Instanz wird ein null als „Ende der datenaufzeichnung“ Markierung geschrieben und beim Start als „Beginn“ Markierung. Unterschied zur 1.6.1 … die null landen jetzt in der richtigen datentabelle.
Die Query Fehler: von wann ist das? Auch vom restart? Hast du ne Idee wie ein leerer wert Zustandekommen kann? Welcher Datenpunkt ist das?
-
Auswirkungen: Es werden wieder ein paar Null Werte in die Tabelle geschrieben.
Das passiert nur beim Neustart des ioBrokers (Mache ich jede Nacht um 4:00 zur Datensicherung)
Danach ist alles wieder stabil. War vorher nicht so, da hat er wenigstens keine "NULL" Werte geschrieben. ` Das ist kein "Problem" sondern das normale Verhalten nach einem Neustart des Adapters.
apollon77 hat das etwas weiter oben beschrieben/erläutert
[EDIT]Wie ich sehe war apollon77 mit seiner Antwort schneller 8-)
-
Ps: könnten die Query Fehler davon kommen das manchmal eine Zahl und manchmal „geschlossen“ da drin steht? Oder wird das in nem String Feld gespeichert?
-
Hallo,
ist ein String-Feld.
Ist halt blöd für die Anzeige in vis, da hier die NULL-Werte angezeigt werden.
-
Kannst du null Werte nicht ignorieren?
Ansonsten ist die Frage (mal wieder) ob man zum Backup wirklich iobroker beenden muss. Ich tue das nicht
-
Ansonsten ist die Frage (mal wieder) ob man zum Backup wirklich iobroker beenden muss. Ich tue das nicht
` Ich auch nicht 8-)Ich lasse Nachts um 04:00h ein Image der SD-Karte auf mein NAS schreiben und im Falle eines Problems habe ich innerhalb von 20 Minuten (so lange dauert es ein 16GB Image auf die SD-Karte zu schreiben) ein funktionierendes Image auf eine SD zurückgespielt. Dafür liegt immer eine Ersatz-SD Karte im Schrank.
-
Man besten vorher iobroker Backup ausführen. Dann hast du beides.
Ich hab ein inkrementelles Backup und rsynce noch das iobroker Verzeichnis auf nen zweiten Rechner.
Am Ende ändert sich nur objects.json und ggf states.json Rest ist recht statisch wenn man nichts ändert.
