[Aufruf] Dringender Test sql 1.6.4

Bitter aller die testen können, hier melden.
Benutzeravatar
apollon77
guru
Beiträge: 5232
Registriert: 10.04.2015, 12:27

[Aufruf] Dringender Test sql 1.6.4

Beitrag von apollon77 » 31.01.2018, 09:08

Hi All,

der sql-Adapter ab v1.5.8 (war nie auf npm) bis hin zur 1.6.1 hat sich ein Fehler eingeschlichen.
Der Fehler hat dafür gesorgt das Daten teilweise in verschiedene Datentabellen gewandert sind und auch teilweisender Typ falsch gesetzt wurde in der Dtanebank.
Auswirkungen konnten sein:
1.) nur "null" -Werte waren vorhanden vom Start oder Ende des Adapters und nichts zwischendrin. Die Daten sind ggf in den anderen tabellen da, aber der Typ in der DB ist falsch gesetzt. Das ist scheinbar vor allem bei neu angelegten Datenpunkten passiert
2.) Werte wurden korrekt geloggt, aber es wurden die "null"-Werte vom Start zusätzlich in die String tabelle geschrieben. Das ist nur unschön und nicht so schlimm :-)
Die Version 1.5.6 die vorher Stabil war hatte aber zusätzlich noch einen Bug, sodass das zeitliche "Erneut loggen" nach Zeit oder Minimaler Werteänderung nicht korrekt klappte. Hier wurde aber pot. zuviel geloggt.

Die neue 1.6.4 (aktuell auf Github) will das alles beheben.
WICHTIG: Nach dem Update die SQL-Instanz neu Starten!!!

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.

Durch die ersten beiden Punkte ergeben sich folgende Möglichkeiten:
- Man kann in den SQL-Einstellungen des Datenpunkts den Datentyp ändern. Dies bedeutet aber, das pot. alle bisher geloggten Daten zwar in der DB noch da sind, aber nicht mehr gelesen werden. Also hier vorsichtig sein und entweder direkt beim anlegen den korrekten Typ setzen oder wissen was man tut.
- Falls man von oben genanntem Bug #1 betroffen war und so Daten in z.B. der "Number"-Tabelle hat aber SQL immer nur die "null"-Werte aus der String-Tabelle anzeigt kann man so durch setzen des "Speichern als" das wieder so korrigieren. Sollte man dann aber schnell nach dem 1.6.3 Update machen, da nach dem Update ja die neuen Werte korrekt in der String Tabelle landen würden.

Ich hoffe ich konnte es einigermaßen verständlich erklären :-)

Und nun bitte testen. Möchte die Buggy 1.6.1 schnell aus latest weg haben :-)

Danke für Eure Unterstützung!

Ingo
How-to:
* Debug-Log für einen Adapter/Instanz einschalten? -> Instanzen -> Expertenomodus -> Spalte Loglevel

pepp86
starter
Beiträge: 45
Registriert: 09.04.2016, 06:54

Re: [Aufruf] Dringender Test sql 1.6.4

Beitrag von pepp86 » 31.01.2018, 09:23

Leider bringt bei mir weder die 1.6.3 noch die 1.6.4 Besserung. Neue Datenpunkte von Typ Number werden immer noch als String gespeichert. Wenn ich "Speichern als" auf Number setze bewirkt es leider auch nichts. Die Zahlen landen jedoch korrekt in der Tabelle ts_number

Benutzeravatar
apollon77
guru
Beiträge: 5232
Registriert: 10.04.2015, 12:27

Re: [Aufruf] Dringender Test sql 1.6.4

Beitrag von apollon77 » 31.01.2018, 09:26

Hast du nach dem Update die Instanz neu gestartet?

Ansonsten bitte unter Instanzen -> expertenmodus -> Spalte Loglevel auf debug stellen und mit debug log als PN schicken
How-to:
* Debug-Log für einen Adapter/Instanz einschalten? -> Instanzen -> Expertenomodus -> Spalte Loglevel

pepp86
starter
Beiträge: 45
Registriert: 09.04.2016, 06:54

Re: [Aufruf] Dringender Test sql 1.6.4

Beitrag von pepp86 » 31.01.2018, 09:41

Hab die Instanz jetzt einmal komplett beendet und neu gestartet. Jetzt aktualisiert er beim Ändern unter "Speichern als" auf Number den Wert in der DB korrekt auf 0.

Allerdings zeigt der Adapter jetzt unter Tabelle einen Fehler:
Dateianhänge
Screenshot.PNG

pepp86
starter
Beiträge: 45
Registriert: 09.04.2016, 06:54

Re: [Aufruf] Dringender Test sql 1.6.4

Beitrag von pepp86 » 31.01.2018, 09:42

Bei neuen Datenpunkten funktioniert jetzt alles korrekt für den Typ number

Benutzeravatar
apollon77
guru
Beiträge: 5232
Registriert: 10.04.2015, 12:27

Re: [Aufruf] Dringender Test sql 1.6.4

Beitrag von apollon77 » 31.01.2018, 09:43

Kannst Du mal sicherstellen das ein Wert geloggt wurde und nochmal die Tabellenanzeige versuchen. Habe da ne Vermutung :-) Die Vermutung ist das die History-Abfrage davon ausgeht dasd der Typ bekannt ist ... der wird aber ggf erst initialisiert wenn der erste Wert geloggt wird.
Ansonsten brauche ich debug log :-)
How-to:
* Debug-Log für einen Adapter/Instanz einschalten? -> Instanzen -> Expertenomodus -> Spalte Loglevel

pepp86
starter
Beiträge: 45
Registriert: 09.04.2016, 06:54

Re: [Aufruf] Dringender Test sql 1.6.4

Beitrag von pepp86 » 31.01.2018, 09:45

Werte sind in der number Tabelle vorhanden. Das lief ja trotz falschem Typ unter datapoints jederzeit korrekt.

Hier das Debug log:

2018-01-31 09:40:21.551 - debug: sql.0 redis pmessage messagebox.system.adapter.sql.0 messagebox.system.adapter.sql.0 {"command":"getHistory","message":{"id":"javascript.0.Heizung.Test3","options":{"aggregate":"none","instance":"sql.0","from":true,"ack":true,"q":true,"end":1517388029381,"count":50,"user":"system.user.admin"}},"from":"system.adapter.admin.0","callback":{"message":{"id":"javascript.0.Heizung.Test3","options":{"aggregate":"none","instance":"sql.0","from":true,"ack":true,"q":true,"end":1517388029381,"count":50,"user":"system.user.admin"}},"id":51,"ack":false,"time":1517388021550},"_id":99887388}
2018-01-31 09:40:21.552 - debug: sql.0 SELECT ts, val, ack, `iobroker`.sources.name as 'from', q FROM `iobroker`.undefined INNER JOIN `iobroker`.sources ON `iobroker`.sources.id=`iobroker`.undefined._from WHERE `iobroker`.undefined.id=2794 AND `iobroker`.undefined.ts < 1517388029381 ORDER BY ts DESC LIMIT 50;
2018-01-31 09:40:21.553 - debug: sql.0 SELECT ts, val, ack, `iobroker`.sources.name as 'from', q FROM `iobroker`.undefined INNER JOIN `iobroker`.sources ON `iobroker`.sources.id=`iobroker`.undefined._from WHERE `iobroker`.undefined.id=2794 AND `iobroker`.undefined.ts < 1517388029381 ORDER BY ts DESC LIMIT 50;
2018-01-31 09:40:21.564 - error: sql.0 Error: ER_NO_SUCH_TABLE: Table 'iobroker.undefined' doesn't exist

Benutzeravatar
apollon77
guru
Beiträge: 5232
Registriert: 10.04.2015, 12:27

Re: [Aufruf] Dringender Test sql 1.6.4

Beitrag von apollon77 » 31.01.2018, 09:57

Installier nochmal neu vom Github, ist jetzt dehug erwetert. Dann bitte nochmal debug schicken. Danke
How-to:
* Debug-Log für einen Adapter/Instanz einschalten? -> Instanzen -> Expertenomodus -> Spalte Loglevel

Benutzeravatar
Kueppert
professional
Beiträge: 532
Registriert: 13.05.2017, 15:18
Wohnort: NRW

Re: [Aufruf] Dringender Test sql 1.6.4

Beitrag von Kueppert » 31.01.2018, 10:18

Hi,
Update bei mir ist drauf. Instanz neu gestartet. Es wird bei mit nur null geloggt. Vorher hatte ich, vor Neustart, die Fehlermeldung, dass die Tabelle nicht existiert...BildBild

Gesendet von meinem HUAWEI RIO-L01 mit Tapatalk
Hardware: Raspberry Pi2 (als CCU) + Pi3 mit Jessy (ioBroker) + Intel NUC,Proxmox -> Debian 9 in VM
Ausstattung: Philips Hue, Synology 415+, RaZberry, FIBARO Motion Sensor & Wall Plug, HM Door Sensor & Messdose, div. Xiaomi-Sensoren

Benutzeravatar
apollon77
guru
Beiträge: 5232
Registriert: 10.04.2015, 12:27

Re: [Aufruf] Dringender Test sql 1.6.4

Beitrag von apollon77 » 31.01.2018, 10:21

Najs mit "nur null" kannst Du von dem oben beschriebenen Problem Nr 2 betroffen sein. Kann es sein das der Datneounkt mit der 1.5.8 oder 1.6.x erst neu angelegt wurde? Wenn ja dann mal versuchen unter der Datenpunkt Konfig bei "Speichern als" denn korrekten Datentyp (Number) zu wählen und Instanz neu zu starten. Wie ists danach?
How-to:
* Debug-Log für einen Adapter/Instanz einschalten? -> Instanzen -> Expertenomodus -> Spalte Loglevel

Benutzeravatar
Kueppert
professional
Beiträge: 532
Registriert: 13.05.2017, 15:18
Wohnort: NRW

Re: [Aufruf] Dringender Test sql 1.6.4

Beitrag von Kueppert » 31.01.2018, 12:00

Apollon,
ja das ist korrekt. Hab xiaomi neu bei mir drin. Hab auf Nummer gestellt und die Instanz neu gestartet. Folgendes Bild:

Muss ich evtl abwarten??BildBild

Gesendet von meinem HUAWEI RIO-L01 mit Tapatalk
Hardware: Raspberry Pi2 (als CCU) + Pi3 mit Jessy (ioBroker) + Intel NUC,Proxmox -> Debian 9 in VM
Ausstattung: Philips Hue, Synology 415+, RaZberry, FIBARO Motion Sensor & Wall Plug, HM Door Sensor & Messdose, div. Xiaomi-Sensoren

Benutzeravatar
apollon77
guru
Beiträge: 5232
Registriert: 10.04.2015, 12:27

Re: [Aufruf] Dringender Test sql 1.6.4

Beitrag von apollon77 » 31.01.2018, 12:02

Nach setzen auf "Number" die Instanz neu gestartet?

Bzw bitte nochmal von Github aktualisieren,. Habe da für getHostpry was gefixt das er nicht den falschen typ aus der DB nimmt. Im zweifel kommt nichts zurück bis der erste Datenpunkt neu gelogt wurde nach dem Start.
How-to:
* Debug-Log für einen Adapter/Instanz einschalten? -> Instanzen -> Expertenomodus -> Spalte Loglevel

Benutzeravatar
apollon77
guru
Beiträge: 5232
Registriert: 10.04.2015, 12:27

Re: [Aufruf] Dringender Test sql 1.6.4

Beitrag von apollon77 » 31.01.2018, 12:07

STOP WArten!! Muss noch was fixen auf Github.
How-to:
* Debug-Log für einen Adapter/Instanz einschalten? -> Instanzen -> Expertenomodus -> Spalte Loglevel

pepp86
starter
Beiträge: 45
Registriert: 09.04.2016, 06:54

Re: [Aufruf] Dringender Test sql 1.6.4

Beitrag von pepp86 » 31.01.2018, 12:18

Mit dem aktuellsten download vom github funktioniert bei mir jetzt alles.

Benutzeravatar
Kueppert
professional
Beiträge: 532
Registriert: 13.05.2017, 15:18
Wohnort: NRW

Re: [Aufruf] Dringender Test sql 1.6.4

Beitrag von Kueppert » 31.01.2018, 12:34

OK ich warte...der pi3 stürzt beim Update auch immer ab. Aber das wird in einem anderen Thema bearbeitet.
Mache das nächste Update über die Konsole ;)

Gesendet von meinem HUAWEI RIO-L01 mit Tapatalk
Hardware: Raspberry Pi2 (als CCU) + Pi3 mit Jessy (ioBroker) + Intel NUC,Proxmox -> Debian 9 in VM
Ausstattung: Philips Hue, Synology 415+, RaZberry, FIBARO Motion Sensor & Wall Plug, HM Door Sensor & Messdose, div. Xiaomi-Sensoren

Benutzeravatar
apollon77
guru
Beiträge: 5232
Registriert: 10.04.2015, 12:27

Re: [Aufruf] Dringender Test sql 1.6.5

Beitrag von apollon77 » 31.01.2018, 12:51

Dann sollte mit 1.6.5 im Notfall auch der getHistory-Fall mit dem Fehler abgefangen sein
How-to:
* Debug-Log für einen Adapter/Instanz einschalten? -> Instanzen -> Expertenomodus -> Spalte Loglevel

Benutzeravatar
Kueppert
professional
Beiträge: 532
Registriert: 13.05.2017, 15:18
Wohnort: NRW

Re: [Aufruf] Dringender Test sql 1.6.5

Beitrag von Kueppert » 31.01.2018, 13:04

apollon77 hat geschrieben:Dann sollte mit 1.6.5 im Notfall auch der getHistory-Fall mit dem Fehler abgefangen sein
Hmmm,
wie bekomme ich die 1.6.5 denn installiert? Der schmeisst mir in der Konsole folgende Fehler aus:
Spoiler: Show hidden text
root@raspberrypi3:/opt/iobroker# sudo npm install iobroker.sql@1.6.5
npm ERR! Linux 4.9.30-v7+
npm ERR! argv "/usr/bin/nodejs" "/usr/bin/npm" "install" "iobroker.sql@1.6.5"
npm ERR! node v4.8.3
npm ERR! npm v2.15.11

npm ERR! version not found: iobroker.sql@1.6.5
npm ERR!
npm ERR! If you need help, you may report this error at:
npm ERR! <https://github.com/npm/npm/issues>

npm ERR! Please include the following file with any support request:
npm ERR! /opt/iobroker/npm-debug.log
root@raspberrypi3:/opt/iobroker#
PS: Habs auch mal mit Version 1.6.4 getestet. Gleiches Bild O.o letztes mal ginbg es noch (ohne sudo; sagte Hormoran aber, soll ich mit dazu schreiben)
Hardware: Raspberry Pi2 (als CCU) + Pi3 mit Jessy (ioBroker) + Intel NUC,Proxmox -> Debian 9 in VM
Ausstattung: Philips Hue, Synology 415+, RaZberry, FIBARO Motion Sensor & Wall Plug, HM Door Sensor & Messdose, div. Xiaomi-Sensoren

Benutzeravatar
apollon77
guru
Beiträge: 5232
Registriert: 10.04.2015, 12:27

Re: [Aufruf] Dringender Test sql 1.6.5

Beitrag von apollon77 » 31.01.2018, 13:14

Die Versionen sind alle noch nur auf Github! Also per "Custom-Install". Ich veröffentliche nach den tests
How-to:
* Debug-Log für einen Adapter/Instanz einschalten? -> Instanzen -> Expertenomodus -> Spalte Loglevel

Benutzeravatar
Kueppert
professional
Beiträge: 532
Registriert: 13.05.2017, 15:18
Wohnort: NRW

Re: [Aufruf] Dringender Test sql 1.6.4

Beitrag von Kueppert » 31.01.2018, 13:18

Achso...mmhhh... Kannst du mir den Befehl sagen? Den hab ich noch nicht in meiner Liste stehen...

Gesendet von meinem HUAWEI RIO-L01 mit Tapatalk
Hardware: Raspberry Pi2 (als CCU) + Pi3 mit Jessy (ioBroker) + Intel NUC,Proxmox -> Debian 9 in VM
Ausstattung: Philips Hue, Synology 415+, RaZberry, FIBARO Motion Sensor & Wall Plug, HM Door Sensor & Messdose, div. Xiaomi-Sensoren

Benutzeravatar
apollon77
guru
Beiträge: 5232
Registriert: 10.04.2015, 12:27

Re: [Aufruf] Dringender Test sql 1.6.4

Beitrag von apollon77 » 31.01.2018, 13:21

versuch mal im iobroker-Verzeichnis ein

Code: Alles auswählen

sudo npm install https://github.com/ioBroker/ioBroker.sql
How-to:
* Debug-Log für einen Adapter/Instanz einschalten? -> Instanzen -> Expertenomodus -> Spalte Loglevel

Antworten