[Aufruf] Dringender Test sql 1.6.4

Bitter aller die testen können, hier melden.
fsjoke
professional
Beiträge: 497
Registriert: 20.09.2016, 08:37

Re: [Aufruf] Dringender Test sql 1.6.4

Beitrag von fsjoke » 09.02.2018, 20:16

Hallo mitsammen!

Habe große Probleme mit dem neuen SQL 1.6.9 (und Vis 1.1.2).

Der Grund sind folgende Fehlermeldungen:
sql.0 2018-02-09 20:01:13.197 warn For getHistory for id rpi2.0.memory.memory_free: Type empty. Need to write data first. Index = 61
sql.0 2018-02-09 20:01:10.233 error error: relation "undefined" does not exist
sql.0 2018-02-09 20:01:10.125 error Please wait till next data record is logged and reload.
sql.0 2018-02-09 20:01:10.124 warn For getHistory for id km200.0.heatingCircuits.hc1.roomtemperature: Type empty. Need to write data first. Index = 49
sql.0 2018-02-09 20:01:04.739 error error: relation "undefined" does not exist
sql.0 2018-02-09 20:01:04.720 error Please wait till next data record is logged and reload.
sql.0 2018-02-09 20:01:04.719 warn For getHistory for id systeminfo.0.BTC-EUR: Type empty. Need to write data first. Index = 83

Ich habe einige Flot-Charts in verschiedenen Vis-screens.
Habe mittels chrome-debug gesehen dass in Vis der Fehler meist auftritt wenn im Abfragezeitraum keine Daten angefallen sind.
Da ich Daten nur bei Änderung speichere kann das schon öfter passieren wenns z.BV nicht geregnet hat.

SQL hab ich noch nicht gedebuggt da ich erst heute drauf gekommen bin dass der Fehler eher von dort kommt!

Zu allem Unglück zeigt Vis den Fehler 'Please wait till next data record is logged and reload.' noch dazu in einem Alert und zerstört dadurch den VIS-screen (nichts geht mehr bis man nicht den alter bestätigt hat!

Bitte Bitte Bitte: KEINE Alerts in VIS!!!!!!!!!!!!!!!!!!!!!! Da gibt's bessere Mittel um Messages anzuzeigen die nicht die gesamte Seite blockieren!

bis vor einer Woche vor den Updates sind diese Meldungen nicht aufgetaucht.
Frank,
CSL-NUC, Orangepi 2e's und Raspi 3's für Test und Entwicklung und sowie auch Ubuntu und Debian virtuelle Linux Testsysteme.
Adapter die ich selbst beigesteuert habe: BMW, broadlink2, radar, systeminfo, km200, xs1

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

Re: [Aufruf] Dringender Test sql 1.6.4

Beitrag von apollon77 » 10.02.2018, 00:00

Kueppert hat geschrieben: Also die Diagrammanzeige geht. Allerdings werden bei mir immer noch Werte doppelt gelogget.
Und im Flot Chart habe ich immer noch ne Lücke. Hatte ich vorher nie. Da hat er immer die Linie durchgezogen...hab die erweiterten EInstellungen mal mit angehangen.
Warum er manchmal ne Lücke anzeigt und manchmal nicht müsste man exakt in Flot nachsehen. Sind die EInstellungen der beiden Graphen gleich? Sonst wüsste ich auch nicht.

Doppelt loggen ... keine Ahnung wo das herkommt. Vor allem ja auch unterschiedliche Zeitstempel. Sollte an sich nicht sein.
In dem Fall gilft vllt ein Debug-Log - ich brauche einen Zeitausschnitt wo ein Wert doppelt geloggt wurde.
How-to:
* Debug-Log für einen Adapter/Instanz einschalten? -> Instanzen -> Expertenomodus -> Spalte Loglevel

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

Re: [Aufruf] Dringender Test sql 1.6.4

Beitrag von apollon77 » 10.02.2018, 00:14

fsjoke hat geschrieben: Der Grund sind folgende Fehlermeldungen:
sql.0 2018-02-09 20:01:13.197 warn For getHistory for id rpi2.0.memory.memory_free: Type empty. Need to write data first. Index = 61
sql.0 2018-02-09 20:01:10.233 error error: relation "undefined" does not exist

Ich habe einige Flot-Charts in verschiedenen Vis-screens.
Habe mittels chrome-debug gesehen dass in Vis der Fehler meist auftritt wenn im Abfragezeitraum keine Daten angefallen sind.
Da ich Daten nur bei Änderung speichere kann das schon öfter passieren wenns z.BV nicht geregnet hat.
Ne das ist nicht korrekt. Der Fehler tritt auf wenn der SQL-Adapter keinen Typ der Daten dieses Datenpunktes kennt. In der 1.6.x hat sich da einiges geändert, wodurch frühere Fehler jetzt korrigiert werden. Es muss am Ende auch nur einmalig ein neuer Wert geloggt werden. AN sich sollte beim Start der letzte bekannte Wert des States gelesen und auch geloggt werden. Damit sollte die Identifizierung reichen. Es sei denn der Wert ist "Null" (also nicht existent). Ansonsten reicht jeder Wert und auch nur einmalig nach der 1.6.x Installation. Ab dann sollte wieder alles passen.

Alternative ist das Du bei den SQL-Einstellungen des betroffenen Datentyps das "Speichern als" korrekt setzt. Dann wird das genommen. Danach musst du ggf sql-Adapter neu starten. SO kannst Du es fixen bevor der nächste Regen kommt :-)
fsjoke hat geschrieben: SQL hab ich noch nicht gedebuggt da ich erst heute drauf gekommen bin dass der Fehler eher von dort kommt!

Zu allem Unglück zeigt Vis den Fehler 'Please wait till next data record is logged and reload.' noch dazu in einem Alert und zerstört dadurch den VIS-screen (nichts geht mehr bis man nicht den alter bestätigt hat!

Bitte Bitte Bitte: KEINE Alerts in VIS!!!!!!!!!!!!!!!!!!!!!! Da gibt's bessere Mittel um Messages anzuzeigen die nicht die gesamte Seite blockieren!

bis vor einer Woche vor den Updates sind diese Meldungen nicht aufgetaucht.
SQL selbst macht keine Alerts oder sonstwas. Das ist Flot ... Einzige Idee wäre in dem Fall keine Fehlermeldung sondern nur ein leeres Ergebnis zurückzugeben. Dachte das wäre eher undurchsichtig. Das mit den Alerts wusste ich nicht ...
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: RE: Re: [Aufruf] Dringender Test sql 1.6.4

Beitrag von Kueppert » 10.02.2018, 07:24

apollon77 hat geschrieben:
Kueppert hat geschrieben: Also die Diagrammanzeige geht. Allerdings werden bei mir immer noch Werte doppelt gelogget.
Und im Flot Chart habe ich immer noch ne Lücke. Hatte ich vorher nie. Da hat er immer die Linie durchgezogen...hab die erweiterten EInstellungen mal mit angehangen.
Warum er manchmal ne Lücke anzeigt und manchmal nicht müsste man exakt in Flot nachsehen. Sind die EInstellungen der beiden Graphen gleich? Sonst wüsste ich auch nicht.

Doppelt loggen ... keine Ahnung wo das herkommt. Vor allem ja auch unterschiedliche Zeitstempel. Sollte an sich nicht sein.
In dem Fall gilft vllt ein Debug-Log - ich brauche einen Zeitausschnitt wo ein Wert doppelt geloggt wurde.
Hi APO,
wegen Loch in der Grafik-stört mich nicht. Beobachte ich einfach Mal weiter.
Debug-log: auf Experte stellen und im Adapter auf debug- Level stellen?
Danke und Grüße, Thorsten

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

fsjoke
professional
Beiträge: 497
Registriert: 20.09.2016, 08:37

Re: [Aufruf] Dringender Test sql 1.6.4

Beitrag von fsjoke » 10.02.2018, 17:18

Hallo Ingo!

Danke für die Ausführung, ja, habe schon gesehen dass Flot der Übeltäter in Vis ist da es die Fehler von SQL anzeigt.

Die Fehlerursache sonst scheinen 'null'-Werte in den Zahlenreihen zu sein. Ich habe die Datenbank durchforstet und gesehen dass diese Null-Werte vermehrt (bei mehreren Datenwerten) seit 5.Februar auftauchen, dem Tag als ich den SQL-Adapter upgedated habe!
vorher ist kein einziger NULL-Wert geloggt worden!

Da ich sonst nichts geändert habe (scripts oder Einstellungen welche Werte wie geloggt werden) ist für mich SQL der Übeltäter da vorher seit Monaten kein 'null' als Zahlenwert aufgezeichnet wurde!

Flot motzt genau bei den Datenreihen welche diese 'nulls' enthalten.
Frank,
CSL-NUC, Orangepi 2e's und Raspi 3's für Test und Entwicklung und sowie auch Ubuntu und Debian virtuelle Linux Testsysteme.
Adapter die ich selbst beigesteuert habe: BMW, broadlink2, radar, systeminfo, km200, xs1

fsjoke
professional
Beiträge: 497
Registriert: 20.09.2016, 08:37

Re: [Aufruf] Dringender Test sql 1.6.4

Beitrag von fsjoke » 10.02.2018, 17:36

Nochwas Ingo!

Beim Schnüffeln in den SQL-Daten in der Datenbank fand ich in den letzten Tagen auch Werte die ein 'from' von sql.0 haben!!

Wie kann das sein? sql sollte doch nie selbst daten erzeugeugen? Das Feld gehörte zu den Heizungsdaten die vom KM200 ausgelesen werden. sql kann da nur auf Änderung prüfen...

p.s.: Nachdem ich die NULL-Werte (insgesamt >600 und alle seit 5.2.2018) aus der Datenbank mittels SQL gelöscht habe meckert Flot nicht mehr... und ich kann Vis wieder betreiben! Hoffe es werden keinen neuen Werte geloggt ...
Frank,
CSL-NUC, Orangepi 2e's und Raspi 3's für Test und Entwicklung und sowie auch Ubuntu und Debian virtuelle Linux Testsysteme.
Adapter die ich selbst beigesteuert habe: BMW, broadlink2, radar, systeminfo, km200, xs1

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 » 10.02.2018, 19:18

Ich glaube die Null Werte die geschrieben werden, erscheinen immer dann, wenn man den SQL Adapter neu startet...

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
sissiwup
professional
Beiträge: 501
Registriert: 27.07.2015, 11:53

Re: [Aufruf] Dringender Test sql 1.6.4

Beitrag von sissiwup » 10.02.2018, 19:56

fsjoke hat geschrieben:Nochwas Ingo!

Beim Schnüffeln in den SQL-Daten in der Datenbank fand ich in den letzten Tagen auch Werte die ein 'from' von sql.0 haben!!

Wie kann das sein? sql sollte doch nie selbst daten erzeugeugen? Das Feld gehörte zu den Heizungsdaten die vom KM200 ausgelesen werden. sql kann da nur auf Änderung prüfen...

p.s.: Nachdem ich die NULL-Werte (insgesamt >600 und alle seit 5.2.2018) aus der Datenbank mittels SQL gelöscht habe meckert Flot nicht mehr... und ich kann Vis wieder betreiben! Hoffe es werden keinen neuen Werte geloggt ...
Hallo,

die NULL-Werte und die Dopplung der Werte scheinen Absicht zu sein. Würde mir auch wünschen, dass das Konfigurierbar ist.
MfG

Sissi

-------------------------------------------
1 CCU2 1 LanGateway 1 Pi-Gateway 1 Zoatec AD02 für ioBroker/MySQL
--------------------------------------------

Benutzeravatar
Homoran
guru
Beiträge: 12335
Registriert: 08.08.2014, 16:50

Re: [Aufruf] Dringender Test sql 1.6.4

Beitrag von Homoran » 10.02.2018, 21:39

Ich weiß nicht ob das jetzt an der neuen Version liegt:
Spoiler: Show hidden text

Code: Alles auswählen

host.ioBroker-Cubie	2018-02-10 21:36:46.529	error	instance system.adapter.sql.0 terminated with code 6 (uncaught exception)
Caught	2018-02-10 21:36:46.527	error	by controller[2]: at readableAddChunk (_stream_readable.js:176:18)
Caught	2018-02-10 21:36:46.526	error	by controller[2]: at Socket.emit (events.js:188:7)
Caught	2018-02-10 21:36:46.525	error	by controller[2]: at emitOne (events.js:96:13)
Caught	2018-02-10 21:36:46.524	error	by controller[2]: at Socket. (/opt/iobroker/node_modules/redis/index.js:274:27)
Caught	2018-02-10 21:36:46.503	error	by controller[2]: at JavascriptRedisParser.execute (/opt/iobroker/node_modules/redis-parser/lib/parser.js:574:12)
Caught	2018-02-10 21:36:46.502	error	by controller[2]: at JavascriptRedisParser.returnReply (/opt/iobroker/node_modules/redis/index.js:192:18)
Caught	2018-02-10 21:36:46.501	error	by controller[2]: at RedisClient.return_reply (/opt/iobroker/node_modules/redis/index.js:824:9)
Caught	2018-02-10 21:36:46.500	error	by controller[2]: at normal_reply (/opt/iobroker/node_modules/redis/index.js:726:21)
Caught	2018-02-10 21:36:46.499	error	by controller[2]: at Command.callback (/opt/iobroker/node_modules/iobroker.js-controller/lib/states/statesInRedis.js:287:17)
Caught	2018-02-10 21:36:46.498	error	by controller[2]: at /opt/iobroker/node_modules/iobroker.sql/main.js:1292:140
Caught	2018-02-10 21:36:46.497	error	by controller[2]: TypeError: Cannot read property 'val' of null
Caught	2018-02-10 21:36:46.496	error	by controller[1]: at readableAddChunk (_stream_readable.js:176:18)
Caught	2018-02-10 21:36:46.495	error	by controller[1]: at Socket.emit (events.js:188:7)
Caught	2018-02-10 21:36:46.494	error	by controller[1]: at emitOne (events.js:96:13)
Caught	2018-02-10 21:36:46.493	error	by controller[1]: at Socket. (/opt/iobroker/node_modules/redis/index.js:274:27)
Caught	2018-02-10 21:36:46.492	error	by controller[1]: at JavascriptRedisParser.execute (/opt/iobroker/node_modules/redis-parser/lib/parser.js:574:12)
Caught	2018-02-10 21:36:46.491	error	by controller[1]: at JavascriptRedisParser.returnReply (/opt/iobroker/node_modules/redis/index.js:192:18)
Caught	2018-02-10 21:36:46.490	error	by controller[1]: at RedisClient.return_reply (/opt/iobroker/node_modules/redis/index.js:824:9)
Caught	2018-02-10 21:36:46.489	error	by controller[1]: at normal_reply (/opt/iobroker/node_modules/redis/index.js:726:21)
Caught	2018-02-10 21:36:46.488	error	by controller[1]: at Command.callback (/opt/iobroker/node_modules/iobroker.js-controller/lib/states/statesInRedis.js:287:17)
Caught	2018-02-10 21:36:46.487	error	by controller[1]: at /opt/iobroker/node_modules/iobroker.sql/main.js:1292:140
Caught	2018-02-10 21:36:46.486	error	by controller[1]: TypeError: Cannot read property 'val' of null
Caught	2018-02-10 21:36:46.469	error	by controller[0]: Cannot find module 'pg-native'
sql.0	2018-02-10 21:36:45.061	warn	Exception: TypeError: Cannot read property 'val' of null
sql.0	2018-02-10 21:36:45.056	error	at readableAddChunk (_stream_readable.js:176:18)
sql.0	2018-02-10 21:36:45.056	error	at Socket.emit (events.js:188:7)
sql.0	2018-02-10 21:36:45.056	error	at emitOne (events.js:96:13)
sql.0	2018-02-10 21:36:45.056	error	at Socket. (/opt/iobroker/node_modules/redis/index.js:274:27)
sql.0	2018-02-10 21:36:45.056	error	at JavascriptRedisParser.execute (/opt/iobroker/node_modules/redis-parser/lib/parser.js:574:12)
sql.0	2018-02-10 21:36:45.056	error	at JavascriptRedisParser.returnReply (/opt/iobroker/node_modules/redis/index.js:192:18)
sql.0	2018-02-10 21:36:45.056	error	at RedisClient.return_reply (/opt/iobroker/node_modules/redis/index.js:824:9)
sql.0	2018-02-10 21:36:45.056	error	at normal_reply (/opt/iobroker/node_modules/redis/index.js:726:21)
sql.0	2018-02-10 21:36:45.056	error	at Command.callback (/opt/iobroker/node_modules/iobroker.js-controller/lib/states/statesInRedis.js:287:17)
sql.0	2018-02-10 21:36:45.056	error	at /opt/iobroker/node_modules/iobroker.sql/main.js:1292:140
sql.0	2018-02-10 21:36:45.056	error	TypeError: Cannot read property 'val' of null
sql.0	2018-02-10 21:36:45.055	error	uncaught exception: Cannot read property 'val' of null
Ich hatte hier lange nicht mehr ins log gesehen.

Mache jetzt erst einmal ein Downgrade




Gruß
Rainer
kein Support per PN!
Fragen im Forum stellen - es gibt fast nichts, was nicht auch für andere interessant ist.

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

Re: RE: Re: [Aufruf] Dringender Test sql 1.6.4

Beitrag von apollon77 » 10.02.2018, 21:52

Kueppert hat geschrieben: Debug-log: auf Experte stellen und im Adapter auf debug- Level stellen?
Ja, aber unter Instanzen :-)
How-to:
* Debug-Log für einen Adapter/Instanz einschalten? -> Instanzen -> Expertenomodus -> Spalte Loglevel

Benutzeravatar
Homoran
guru
Beiträge: 12335
Registriert: 08.08.2014, 16:50

Re: [Aufruf] Dringender Test sql 1.6.4

Beitrag von Homoran » 10.02.2018, 21:54

Wobei das unter Admin 3 egal ist.
Der Expertenmodus von Adapter und Instanzen ist gekoppelt.


Gruß
Rainer
kein Support per PN!
Fragen im Forum stellen - es gibt fast nichts, was nicht auch für andere interessant ist.

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

Re: [Aufruf] Dringender Test sql 1.6.4

Beitrag von apollon77 » 10.02.2018, 22:01

fsjoke hat geschrieben: Die Fehlerursache sonst scheinen 'null'-Werte in den Zahlenreihen zu sein. Ich habe die Datenbank durchforstet und gesehen dass diese Null-Werte vermehrt (bei mehreren Datenwerten) seit 5.Februar auftauchen, dem Tag als ich den SQL-Adapter upgedated habe!
vorher ist kein einziger NULL-Wert geloggt worden!

Flot motzt genau bei den Datenreihen welche diese 'nulls' enthalten.
Das die "null" Werte geloggt werden ist absicht. Ziel ist das man das Ende und den Start einer Aufzeichnung erkennen kann. Das ist vor allem dann sinnvoll wenn man nur "bei Änderung" aufzeichnet, da man sonst nicht weiss ob die Daten wirklich so waren oder nichts geloggt wurde weil der sql-Adapter aus war.
fsjoke hat geschrieben: Beim Schnüffeln in den SQL-Daten in der Datenbank fand ich in den letzten Tagen auch Werte die ein 'from' von sql.0 haben!!

Wie kann das sein? sql sollte doch nie selbst daten erzeugeugen? Das Feld gehörte zu den Heizungsdaten die vom KM200 ausgelesen werden. sql kann da nur auf Änderung prüfen...
Diese Werte und auch andere die als "from" ein "sql.0" haben kommen vom sql-Adapter und sind somit solche Sonderwerte. Darüber kann man erkennen das es sich um solche Sonderwerte handelt. Die existieren auch nur in der SQL-Datenbank.
Daher können Sie auch an sich nicht an den obigen Problemen Ursache sein, es sei denn der echte Wert war auch "Null" :-)
fsjoke hat geschrieben: p.s.: Nachdem ich die NULL-Werte (insgesamt >600 und alle seit 5.2.2018) aus der Datenbank mittels SQL gelöscht habe meckert Flot nicht mehr... und ich kann Vis wieder betreiben! Hoffe es werden keinen neuen Werte geloggt ...
Ich würde eher tippen das inzwischen Typen für alle Datenpunkte korrekt sind und existieren. Du kannst mal in der "datapoints" Tabelle schauen ob Du welche mit "NULL" als "type" hast ... die sind dann noch komisch und haben wohl keinen neuen Wert bekommen.
How-to:
* Debug-Log für einen Adapter/Instanz einschalten? -> Instanzen -> Expertenomodus -> Spalte Loglevel

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

Re: [Aufruf] Dringender Test sql 1.6.4

Beitrag von apollon77 » 10.02.2018, 22:03

sissiwup hat geschrieben: die NULL-Werte und die Dopplung der Werte scheinen Absicht zu sein. Würde mir auch wünschen, dass das Konfigurierbar ist.
Doppelwerte nicht, NULL ja :-)

Ich schaue die Tage mal das ich es konfigurierbar mache bei dem "Wiederstand" hier :-) (kein Vorwurf, kann es verstehen. Ist halt eine Änderung die gewöhnungsbedürftig ist)
How-to:
* Debug-Log für einen Adapter/Instanz einschalten? -> Instanzen -> Expertenomodus -> Spalte Loglevel

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

Re: [Aufruf] Dringender Test sql 1.6.4

Beitrag von apollon77 » 10.02.2018, 22:06

Homoran hat geschrieben:Ich weiß nicht ob das jetzt an der neuen Version liegt:
Spoiler: Show hidden text

Code: Alles auswählen

host.ioBroker-Cubie	2018-02-10 21:36:46.529	error	instance system.adapter.sql.0 terminated with code 6 (uncaught exception)
Caught	2018-02-10 21:36:46.527	error	by controller[2]: at readableAddChunk (_stream_readable.js:176:18)
Caught	2018-02-10 21:36:46.526	error	by controller[2]: at Socket.emit (events.js:188:7)
Caught	2018-02-10 21:36:46.525	error	by controller[2]: at emitOne (events.js:96:13)
Caught	2018-02-10 21:36:46.524	error	by controller[2]: at Socket. (/opt/iobroker/node_modules/redis/index.js:274:27)
Caught	2018-02-10 21:36:46.503	error	by controller[2]: at JavascriptRedisParser.execute (/opt/iobroker/node_modules/redis-parser/lib/parser.js:574:12)
Caught	2018-02-10 21:36:46.502	error	by controller[2]: at JavascriptRedisParser.returnReply (/opt/iobroker/node_modules/redis/index.js:192:18)
Caught	2018-02-10 21:36:46.501	error	by controller[2]: at RedisClient.return_reply (/opt/iobroker/node_modules/redis/index.js:824:9)
Caught	2018-02-10 21:36:46.500	error	by controller[2]: at normal_reply (/opt/iobroker/node_modules/redis/index.js:726:21)
Caught	2018-02-10 21:36:46.499	error	by controller[2]: at Command.callback (/opt/iobroker/node_modules/iobroker.js-controller/lib/states/statesInRedis.js:287:17)
Caught	2018-02-10 21:36:46.498	error	by controller[2]: at /opt/iobroker/node_modules/iobroker.sql/main.js:1292:140
Caught	2018-02-10 21:36:46.497	error	by controller[2]: TypeError: Cannot read property 'val' of null
Caught	2018-02-10 21:36:46.496	error	by controller[1]: at readableAddChunk (_stream_readable.js:176:18)
Caught	2018-02-10 21:36:46.495	error	by controller[1]: at Socket.emit (events.js:188:7)
Caught	2018-02-10 21:36:46.494	error	by controller[1]: at emitOne (events.js:96:13)
Caught	2018-02-10 21:36:46.493	error	by controller[1]: at Socket. (/opt/iobroker/node_modules/redis/index.js:274:27)
Caught	2018-02-10 21:36:46.492	error	by controller[1]: at JavascriptRedisParser.execute (/opt/iobroker/node_modules/redis-parser/lib/parser.js:574:12)
Caught	2018-02-10 21:36:46.491	error	by controller[1]: at JavascriptRedisParser.returnReply (/opt/iobroker/node_modules/redis/index.js:192:18)
Caught	2018-02-10 21:36:46.490	error	by controller[1]: at RedisClient.return_reply (/opt/iobroker/node_modules/redis/index.js:824:9)
Caught	2018-02-10 21:36:46.489	error	by controller[1]: at normal_reply (/opt/iobroker/node_modules/redis/index.js:726:21)
Caught	2018-02-10 21:36:46.488	error	by controller[1]: at Command.callback (/opt/iobroker/node_modules/iobroker.js-controller/lib/states/statesInRedis.js:287:17)
Caught	2018-02-10 21:36:46.487	error	by controller[1]: at /opt/iobroker/node_modules/iobroker.sql/main.js:1292:140
Caught	2018-02-10 21:36:46.486	error	by controller[1]: TypeError: Cannot read property 'val' of null
Caught	2018-02-10 21:36:46.469	error	by controller[0]: Cannot find module 'pg-native'
sql.0	2018-02-10 21:36:45.061	warn	Exception: TypeError: Cannot read property 'val' of null
sql.0	2018-02-10 21:36:45.056	error	at readableAddChunk (_stream_readable.js:176:18)
sql.0	2018-02-10 21:36:45.056	error	at Socket.emit (events.js:188:7)
sql.0	2018-02-10 21:36:45.056	error	at emitOne (events.js:96:13)
sql.0	2018-02-10 21:36:45.056	error	at Socket. (/opt/iobroker/node_modules/redis/index.js:274:27)
sql.0	2018-02-10 21:36:45.056	error	at JavascriptRedisParser.execute (/opt/iobroker/node_modules/redis-parser/lib/parser.js:574:12)
sql.0	2018-02-10 21:36:45.056	error	at JavascriptRedisParser.returnReply (/opt/iobroker/node_modules/redis/index.js:192:18)
sql.0	2018-02-10 21:36:45.056	error	at RedisClient.return_reply (/opt/iobroker/node_modules/redis/index.js:824:9)
sql.0	2018-02-10 21:36:45.056	error	at normal_reply (/opt/iobroker/node_modules/redis/index.js:726:21)
sql.0	2018-02-10 21:36:45.056	error	at Command.callback (/opt/iobroker/node_modules/iobroker.js-controller/lib/states/statesInRedis.js:287:17)
sql.0	2018-02-10 21:36:45.056	error	at /opt/iobroker/node_modules/iobroker.sql/main.js:1292:140
sql.0	2018-02-10 21:36:45.056	error	TypeError: Cannot read property 'val' of null
sql.0	2018-02-10 21:36:45.055	error	uncaught exception: Cannot read property 'val' of null
Ich hatte hier lange nicht mehr ins log gesehen.

Mache jetzt erst einmal ein Downgrade
Fix auf Github. Ein Logging war der verursacher. Du hast scheinbar einen Datenpunkt aktiviert der noch nie einen Wert hatte
How-to:
* Debug-Log für einen Adapter/Instanz einschalten? -> Instanzen -> Expertenomodus -> Spalte Loglevel

Benutzeravatar
BBTown
professional
Beiträge: 878
Registriert: 20.01.2017, 01:25
Wohnort: Kreis Segeberg

Re: [Aufruf] Dringender Test sql 1.6.4

Beitrag von BBTown » 10.02.2018, 22:51

habe die v.1.7.0 installiert
Macht bisher was er soll
Wenn man die "NULL" Werte abschaltet und der SQL-Adapter sich danach neu startet, werden noch einmal NULL Werte geschrieben (Ende Aufzeichnung aus vorheriger Einstellung?!). Anschließend beim Neustart des Adapters dann nicht mehr.
Ciao und Gruß,
Heiko

ioBroker auf QNAP TS-251A (Docker), node v.6.14.1, npm v.3.10.10, js-controller v.1.4.2)
HomeMatic CCU-2 (Wired und Funk) / Philips HUE / echo.DOT / Broadlink RM pro / SONOS

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

Re: [Aufruf] Dringender Test sql 1.6.4

Beitrag von apollon77 » 10.02.2018, 22:54

*pppsssstttt* ... Menno bist Du schnell, das wollte ich noch verraten ;-))

Naja, ok Katze aus dem Sack. ... Weiter geht es dann jetzt hier:

http://forum.iobroker.net/viewtopic.php?f=36&t=11693

Und ja, denke die letzten "NULL"s kommen vom Beenden des Adapters
How-to:
* Debug-Log für einen Adapter/Instanz einschalten? -> Instanzen -> Expertenomodus -> Spalte Loglevel

Benutzeravatar
Homoran
guru
Beiträge: 12335
Registriert: 08.08.2014, 16:50

Re: [Aufruf] Dringender Test sql 1.6.4

Beitrag von Homoran » 10.02.2018, 22:57

apollon77 hat geschrieben:Fix auf Github. Ein Logging war der verursacher. Du hast scheinbar einen Datenpunkt aktiviert der noch nie einen Wert hatte
Mit Install von Github keine weiteren Error!
BBTown hat geschrieben:habe die v.1.7.0 installiert
Ist aber bei mir immer noch die 1.6.9


Gruß
Rainer
kein Support per PN!
Fragen im Forum stellen - es gibt fast nichts, was nicht auch für andere interessant ist.

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

Re: [Aufruf] Dringender Test sql 1.6.4

Beitrag von apollon77 » 10.02.2018, 22:59

Ja, musst nochmal :-) hatte zuerst deinen Bug gefixt und erst danach die anderen 1.7.0er Dinge gemacht :-)
How-to:
* Debug-Log für einen Adapter/Instanz einschalten? -> Instanzen -> Expertenomodus -> Spalte Loglevel

Benutzeravatar
BBTown
professional
Beiträge: 878
Registriert: 20.01.2017, 01:25
Wohnort: Kreis Segeberg

Re: [Aufruf] Dringender Test sql 1.6.4

Beitrag von BBTown » 10.02.2018, 23:22

apollon77 hat geschrieben:*pppsssstttt* ... Menno bist Du schnell, das wollte ich noch verraten ;-))
sorry ;)
Ciao und Gruß,
Heiko

ioBroker auf QNAP TS-251A (Docker), node v.6.14.1, npm v.3.10.10, js-controller v.1.4.2)
HomeMatic CCU-2 (Wired und Funk) / Philips HUE / echo.DOT / Broadlink RM pro / SONOS

fsjoke
professional
Beiträge: 497
Registriert: 20.09.2016, 08:37

Re: [Aufruf] Dringender Test sql 1.6.4

Beitrag von fsjoke » 11.02.2018, 15:56

Na da hat sich ja einiges bewegt inzwischen!

Ich habe den Sinn der Null-Werte nicht verstanden, die sollten nie notwendig und sein!
Eine Integration der Daten im Nachhinein (notwendig um z.B die Leistung zu berechnnen) wird dadurch unnötig kompliziert.

Null-Werte sollten aufgezeichnet werden wenn KEINE Daten kommen.

Eine STrategie welche ich verwenden musste um einer Industrielle Anwendung Daten aufzuzeichnen war folgende:

Es gibt zwei timeouts:
t1 = die maximale Zeit zwischen gleichen Datenpunkten (kann/soll verwendet werden um Datenpunkte aufzuzeichnen auch wenn die Daten gleich bleiben damit z.B. jede STunde oder jeden Tag zumindest ein Datenpunkt aufgezeichnet wird.
t2 = maximale Dauer zwischen zwei Datenpunkten, wenn länger wird null als Unterbrechung aufgezeichnet (aber nur 1x!)

Die Datenpunkte wurden (mit den Zeitstempeln) folgendermaßen mit der Strategie 'nbur bei Änderung' gespeichert:
* Letzter Datenpunkt wird als alter gespeichert
* neuer als neuer
* t2 wird neu getriggert
wenn alt==neu
* - t1 wird beim ersten mal getriggert
* - wenn t1 ausläuft wird neu geschrieben und t1 wieder getriggert.
sonst (wenn alt != neu)
* - alt wird gespeichert (hat noch den timestamp des letzten alten Wertes)
* - neu wird gespeichert
* - t1 und t2 werden gecancelt
wenn t2 ausläuft (dann ist der letzte Datenpunkt noch der neue vom letzten mal und der alte der alte davor)
* - neu wird geschrieben
* - null wird geschrieben


Diese Methode zeichnet genau auf wie lange gleiche Daten gelesen wurden und wann Änderungen oder keine Daten vorkanem.
Die Daten sind dann leicht integrierbar und fehlende Daten werden auch gekennzeichnet.

Die 'Entprellung' fehlt hier zwar, kann aber auch eingebunden werden, sie ist aber bei Aufzeichnung von Änderungen meist nicht notwendig.
Frank,
CSL-NUC, Orangepi 2e's und Raspi 3's für Test und Entwicklung und sowie auch Ubuntu und Debian virtuelle Linux Testsysteme.
Adapter die ich selbst beigesteuert habe: BMW, broadlink2, radar, systeminfo, km200, xs1

Antworten