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

[integer63]

Hallo in die Runde,

nur zur Sicherheit, ich habe vorher nicht darauf geachtet und habe heute nach den Update auf 1.6.5 diese Einträge im Log gefunden:

sql.0	2018-01-31 20:31:31.057	info	enabled logging of hm-rpc.2.000915698D5F65.1.MOTION
sql.0	2018-01-31 20:31:01.117	error	at return_pub_sub (/opt/iobroker/node_modules/redis/index.js:794:18)
sql.0	2018-01-31 20:31:01.117	error	at RedisClient.emit (events.js:194:7)
sql.0	2018-01-31 20:31:01.117	error	at emitThree (events.js:116:13)
sql.0	2018-01-31 20:31:01.117	error	at RedisClient. (/opt/iobroker/node_modules/iobroker.js-controller/lib/states/statesInRedis.js:104:25)
sql.0	2018-01-31 20:31:01.117	error	at change (/opt/iobroker/node_modules/iobroker.js-controller/lib/adapter.js:3165:34)
sql.0	2018-01-31 20:31:01.117	error	at Adapter.emit (events.js:188:7)
sql.0	2018-01-31 20:31:01.117	error	at emitOne (events.js:96:13)
sql.0	2018-01-31 20:31:01.117	error	at Adapter. (/opt/iobroker/node_modules/iobroker.sql/main.js:196:5)
sql.0	2018-01-31 20:31:01.117	error	at processMessage (/opt/iobroker/node_modules/iobroker.sql/main.js:709:9)
sql.0	2018-01-31 20:31:01.117	error	at getHistory (/opt/iobroker/node_modules/iobroker.sql/main.js:1728:50)
sql.0	2018-01-31 20:31:01.117	error	TypeError: Cannot read property 'storageType' of undefined
sql.0	2018-01-31 20:31:01.092	error	pmessage messagebox.system.adapter.sql.0 {"command":"getHistory","message":{"id":"hm-rpc.2.000915698D5F65.1.MOTION","options":{"aggregate":"none","instance":"sql.0","from":true,"ack":true,"q":true,"e

Muss mich das beunruhigen?

[apollon77]

Komisch, hab mal eine 1.6.6 hinterhergeschoben die das abfange sollte. Please try

[Kueppert]

@apollon77:

mach mal "iobroker upload sql". Dann da? ` [emoji38] gibt es doch nicht… Ja hat geholfen, danke dir :D

Selbst Kaltstart vom pi und Neustart der Instanz haben nicht dazu geführt, dass die Anzeige korrekt wird.

Jetzt noch bis morgen warten wegen der Daten. Sieht jetzt alles gut aus.

Gesendet von meinem HUAWEI RIO-L01 mit Tapatalk

[apollon77]

Liegt bei dir daran das Du die installationen wegen dem Kompilier-Problem immer abbrichst und es so nie zuende läuft :-)

[integer63]

Mit 1.6.6 haben sich die Log-Einträge verändert:
` > sql.0 2018-01-31 22:20:17.266 info enabled logging of hm-rpc.2.000C170999FDF5.1.ILLUMINATION

sql.0 2018-01-31 22:20:09.606 error Error: ER_NO_SUCH_TABLE: Table 'ioBroker.undefined' doesn't exist

sql.0 2018-01-31 22:20:09.573 error Please wait till next data record is logged and reload.

sql.0 2018-01-31 22:20:09.558 warn For getHistory for id hm-rpc.2.000C170999FDF5.1.ILLUMINATION: Type empty. Need to write data first. Index = 381 Und mir ist aufgefallen, dass die Instanz gelb bleibt: ![2876_sql-iobroker.admin.png](/assets/uploads/files/2876_sql-iobroker.admin.png) obwohl alles soweit zu funktionieren scheint: > sql.0 2018-01-31 22:16:06.073 info Connected to mysql `

[apollon77]

Wegen gelb: reloade mal die Ansicht bzw schaue mal in den Objekten was unter sql.0.info.connection steht … ist das true? Dann ist alles gut ...

Die eine Meldung kommt in bestimmten Fällen und sollte verschwinden sobald einmal ein neuer Wert für den Datenpunkt (hm-rpc.2.000C170999FDF5.1.ILLUMINATION) geloggt wurde. Bitte mal schauen ob/das es verschwindet. interessant ist das erst 8 Sekunden nach dem "getHistory" der Datenpounkt in SQL aktiviert wurde ... Was hast Du da getrieben? :-)

[integer63]

@apollon77:

Wegen gelb: reloade mal die Ansicht bzw schaue mal in den Objekten was unter sql.0.info.connection steht … ist das true? Dann ist alles gut ... `
Na ja, reloadet habe ich schon mehrfach und unter Objekte habe ich kein sql.0 - sollte doch alphabetisch sortiert sein, oder:

[integer63]

Oder meinst du das hier:

[apollon77]

Hm … ich hab die :-) Wenn DU schon sql ewig installiert hast kann das sein. Der info.connection kam erst irgendwann dazu. ggf ioBroker mal neu starten ?! :-)

An dem teil hab ich nichts geändert

[Kueppert]

Also,

Habe jede Menge Werte erhalten, die wurden auch geloggt.

Von meiner Seite nun absolut erst Mal grünes Licht (v1.6.5)

VG Thorsten~~<link_text text="https://uploads.tapatalk-cdn.com/201802 ... 31db60.jpg">https://uploads.tapatalk-cdn.com/20180201/84d26ffb3aa2bb55a8a50d406631db60.jpg</link_text>" />

Gesendet von meinem HUAWEI RIO-L01 mit Tapatalk~~

[Kueppert]

Hi, ich habe festgestellt, dass Daten doppelt geloggt werden. Hat das Problem noch jemand?

<link_text text="https://uploads.tapatalk-cdn.com/201802 ... 164c11.jpg">https://uploads.tapatalk-cdn.com/20180201/b4dc9f637f8b1e500bf8ef5e29164c11.jpg</link_text>" /><link_text text="https://uploads.tapatalk-cdn.com/201802 ... 0b6c5c.jpg">https://uploads.tapatalk-cdn.com/20180201/91242e8abfc4b98fe3bac789000b6c5c.jpg</link_text>" />

Gesendet von meinem HUAWEI RIO-L01 mit Tapatalk~~~~

[apollon77]

Zeitpunkte sind identisch?

Beende mal die Instanz. Schau das dann keine mehr läuft (ps auxww|grep sql) und Starte neu. Dann immer noch?

[Kueppert]

@apollon77:

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 `

[apollon77]

Keine zweite Instanz. Komisch … schau mal

[Kueppert]

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

[sissiwup]

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.

[apollon77]

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 …

[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?