UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[apollon77]

Pps: den migrationspfad gibt es ja … diese erster Beitrag hier. Speichern als setzen auf korrekten Typ. Dann sollten die Daten zurück sein

[sissiwup]

@apollon77:

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?

[sissiwup]

@apollon77:

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?

[apollon77]

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.

[apollon77]

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

[apollon77]

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" ?!

[sissiwup]

@apollon77:

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.

[sissiwup]

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

[apollon77]

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?

[BBTown]

@sissiwup:

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-)

[apollon77]

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?

[sissiwup]

Hallo,

ist ein String-Feld.

Ist halt blöd für die Anzeige in vis, da hier die NULL-Werte angezeigt werden.

[apollon77]

Kannst du null Werte nicht ignorieren?

Ansonsten ist die Frage (mal wieder) ob man zum Backup wirklich iobroker beenden muss. Ich tue das nicht

[BBTown]

@apollon77:

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.

[apollon77]

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.

[sissiwup]

@apollon77:

Kannst du null Werte nicht ignorieren?

Ansonsten ist die Frage (mal wieder) ob man zum Backup wirklich iobroker beenden muss. Ich tue das nicht `

Hallo,

wofür sollen die null-Werte gut sein?

Es ist das Standard-Element von VIS, da kann man leider nichts einstellen.

Oder übersehe ich da etwas?

<u>Offtopic:</u>

Das mit den Neustarten muss vlt. nicht mehr sein. Starte aber alles um 4:00 neu.

Aktuell ist das auch gut so, wenn ich sehe wie oft sich irgendein Adapter wegängt

und aufeinmal keine Werte mehr liefert. Habe aktuell z.B. Probleme mit dem REGA-Adapter,

da kommen halt manchmal manche Ereignisse nicht an.

Der andere Adapter läuft aber in der Zeit tadellos (also kein Netzwerk oder ähnliches).

Außerdem halten sich ausfälle so sehr begrenzt, wenn ich mal ein paar Tage weg bin.

[sissiwup]

@BBTown:

@sissiwup:

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-) `

Auch das mit der Fehlermeldung?

sql.0	2018-02-04 04:11:32.471	error	Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(1550, 1517713892257, , 0, 0, 0);: Error: ER_PARSE_ERROR: You have an error in your SQL syntax; check the manual that
sql.0	2018-02-04 04:11:32.347	error	Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(1549, 1517713892256, , 1, 6, 0);: Error: ER_PARSE_ERROR: You have an error in your SQL syntax; check the manual that

[apollon77]

Die Fehlermeldung natürlich nicht. Siehe meine Fragen dazu weiter oben. Irgendwie kommt in einem zahlenfeld ein leerer Wert rein. Wann passiert es? Beim restart bzw indem Fall danach scheinbar. Kannst du es mit einem iobroker stop/Start reproduzieren? Wenn ja bitte mal sql auf Debug stellen und iobroker neu starten. Das log sollte zeigen was genau passiert.

Zu vis history: mach im GitHub mal ein issue auf, vllt kann man eine „ignoriere null“ Einstellung hinzufügen …

[sissiwup]

@apollon77:

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" ?! `

Klappt nicht:

sql.0	2018-02-04 18:03:37.659	error	Cannot insert INSERT INTO `iobroker`.undefined (id, ts, val, ack, _from, q) VALUES(1563, 1517763807597, , 1, 6, 0);: Error: ER_PARSE_ERROR: You have an error in your SQL syntax; check the manual that
sql.0	2018-02-04 18:03:28.966	error	Error: ER_NO_SUCH_TABLE: Table 'iobroker.undefined' doesn't exist
fritzbox.0	2018-02-04 18:03:27.558	info	data from 192.168.1.100: 04.02.18 18:03:27;DISCONNECT;1;0;
sql.0	2018-02-04 18:03:23.970	error	Cannot insert INSERT INTO `iobroker`.undefined (id, ts, val, ack, _from, q) VALUES(1563, 1517763803920, 057239588336, 1, 6, 0);: Error: ER_NO_SUCH_TABLE: Table 'iobroker.undefined' doesn't exist
fritzbox.0	2018-02-04 18:03:23.823	info	data from 192.168.1.100: 04.02.18 18:03:23;DISCONNECT;2;0;
fritzbox.0	2018-02-04 18:03:23.812	info	data from 192.168.1.100: 04.02.18 18:03:23;RING;2;057239588336;9588336;SIP1;
fritzbox.0	2018-02-04 18:03:23.351	info	data from 192.168.1.100: 04.02.18 18:03:23;CALL;1;12;9588336;9588336;SIP1;
sql.0	2018-02-04 18:02:46.360	error	Error: ER_NO_SUCH_TABLE: Table 'iobroker.undefined' doesn't exist
sql.0	2018-02-04 18:01:50.086	error	Cannot delete DELETE FROM `iobroker`.undefined WHERE id=1550 AND ts < 1454691660768;: Error: ER_NO_SUCH_TABLE: Table 'iobroker.undefined' doesn't exist
sql.0	2018-02-04 18:01:50.033	error	Cannot delete DELETE FROM `iobroker`.undefined WHERE id=1563 AND ts < 1454691660662;: Error: ER_NO_SUCH_TABLE: Table 'iobroker.undefined' doesn't exist
sql.0	2018-02-04 18:01:49.767	error	Cannot insert INSERT INTO `iobroker`.undefined (id, ts, val, ack, _from, q) VALUES(1550, 1517763694492, NULL, 1, 15, 64);: Error: ER_NO_SUCH_TABLE: Table 'iobroker.undefined' doesn't exist
sql.0	2018-02-04 18:01:49.661	error	Cannot insert INSERT INTO `iobroker`.undefined (id, ts, val, ack, _from, q) VALUES(1563, 1517763694492, NULL, 1, 15, 64);: Error: ER_NO_SUCH_TABLE: Table 'iobroker.undefined' doesn't exist
sql.0	2018-02-04 18:01:47.199	error	Cannot delete DELETE FROM `iobroker`.undefined WHERE id=1549 AND ts < 1454691660227;: Error: ER_NO_SUCH_TABLE: Table 'iobroker.undefined' doesn't exist
sql.0	2018-02-04 18:01:44.171	error	Cannot insert INSERT INTO `iobroker`.undefined (id, ts, val, ack, _from, q) VALUES(1549, 1517763694492, NULL, 1, 15, 64);: Error: ER_NO_SUCH_TABLE: Table 'iobroker.undefined' doesn't exist
host.zotac	2018-02-04 18:01:32.233	info	instance system.adapter.sql.0 started with pid 26685
host.zotac	2018-02-04 18:01:30.681	info	instance system.adapter.sql.0 terminated with code 0 (OK)
Caught	2018-02-04 18:01:30.680	error	by controller[3]: 2018-02-04 18:01:30.562 - sql.0 Cannot delete DELETE FROM `iobroker`.undefined WHERE id=1549 AND ts < 1454691660553;: Error: ER_NO_SUCH_TABLE: Table 'iobroker.undefined' doesn't e
Caught	2018-02-04 18:01:30.680	error	by controller[2]: 2018-02-04 18:01:30.550 - sql.0 Cannot insert INSERT INTO `iobroker`.undefined (id, ts, val, ack, _from, q) VALUES(1549, 1517763687678, NULL, 0, 15, 64);: Error: ER_NO_SUCH_TABLE:
Caught	2018-02-04 18:01:30.679	error	by controller[1]: 2018-02-04 18:01:29.833 - sql.0 Cannot insert INSERT INTO `iobroker`.undefined (id, ts, val, ack, _from, q) VALUES(1550, 1517763687678, NULL, 0, 15, 64);: Error: ER_NO_SUCH_TABLE:
sql.0	2018-02-04 18:01:30.562	error	Cannot delete DELETE FROM `iobroker`.undefined WHERE id=1549 AND ts < 1454691660553;: Error: ER_NO_SUCH_TABLE: Table 'iobroker.undefined' doesn't exist
sql.0	2018-02-04 18:01:30.550	error	Cannot insert INSERT INTO `iobroker`.undefined (id, ts, val, ack, _from, q) VALUES(1549, 1517763687678, NULL, 0, 15, 64);: Error: ER_NO_SUCH_TABLE: Table 'iobroker.undefined' doesn't exist
sql.0	2018-02-04 18:01:29.821	error	Cannot insert INSERT INTO `iobroker`.undefined (id, ts, val, ack, _from, q) VALUES(1550, 1517763687678, NULL, 0, 15, 64);: Error: ER_NO_SUCH_TABLE: Table 'iobroker.undefined' doesn't exist

SQL fom GITHUB geladen

Datenpunkt 1563 auf NULL geändert.

SQL neu gestartet.

Datenpunkt geändert (steht auf automatisch).

Gleiche für 1550 und 1549

[sissiwup]

Verhindern der NULL-Werte:

CREATE DEFINER=`root`@`localhost` 
TRIGGER `DEL_NULL` 
BEFORE INSERT ON `ts_string` 
FOR EACH ROW 
   if NEW.q = 64 then 
      set NEW.ts = NULL; 
   end if

Das erzeugt zwar im log böse Fehlermeldungen, dafür ist die Historie sauber.