[Aufrug] sql 1.7.0 testen

Kueppert

So,

habe jetzt das log exportiert und die DOPPLUNGEN hier einmal angehangen.

Log 2:58 Uhr:

! ` > 2018-02-15 02:58:08.912 - debug: sql.0 new value received for ping.1.raspberrypi3.www_google_de, new-value=true, ts=1518659888908, relog=false

2018-02-15 02:58:08.912 - debug: sql.0 value not changed ping.1.raspberrypi3.www_google_de, last-value=true, new-value=true, ts=1518659888908

2018-02-15 02:58:20.364 - debug: sql.0 new value received for rpi2.0.temperature.soc_temp, new-value=48.31, ts=1518659900362, relog=false

2018-02-15 02:58:21.366 - debug: sql.0 Datatype rpi2.0.temperature.soc_temp: Currently: number, StorageType: Number

2018-02-15 02:58:21.367 - debug: sql.0 INSERT INTO iobroker.ts_number (id, ts, val, ack, _from, q) VALUES(1, 1518659900362, 48.31, 1, 1, 0);

2018-02-15 02:58:33.485 - debug: sql.0 new value received for mihome.0.devices.sensor_ht_158d000149c2cc.temperature, new-value=19.33, ts=1518659913482, relog=false

2018-02-15 02:58:33.486 - debug: sql.0 Min-Delta not reached mihome.0.devices.sensor_ht_158d000149c2cc.temperature, last-value=19.28, new-value=19.33, ts=1518659913482

2018-02-15 02:58:33.489 - debug: sql.0 new value received for mihome.0.devices.sensor_ht_158d000149c2cc.humidity, new-value=59.37, ts=1518659913485, relog=false

2018-02-15 02:58:33.490 - debug: sql.0 Min-Delta reached mihome.0.devices.sensor_ht_158d000149c2cc.humidity, last-value=59.05, new-value=59.37, ts=1518659913485

2018-02-15 02:58:33.490 - debug: sql.0 Datatype mihome.0.devices.sensor_ht_158d000149c2cc.humidity: Currently: number, StorageType: Number

2018-02-15 02:58:33.491 - debug: sql.0 INSERT INTO iobroker.ts_number (id, ts, val, ack, _from, q) VALUES(13, 1518656416889, 59.05, 1, 7, 0);

2018-02-15 02:58:33.497 - debug: sql.0 new value received for mihome.0.devices.sensor_ht_158d000149c2cc.temperature, new-value=19.33, ts=1518659913494, relog=false

2018-02-15 02:58:33.498 - debug: sql.0 value not changed mihome.0.devices.sensor_ht_158d000149c2cc.temperature, last-value=19.28, new-value=19.33, ts=1518659913494

2018-02-15 02:58:33.500 - debug: sql.0 new value received for mihome.0.devices.sensor_ht_158d000149c2cc.humidity, new-value=59.37, ts=1518659913496, relog=false

2018-02-15 02:58:33.500 - debug: sql.0 value not changed mihome.0.devices.sensor_ht_158d000149c2cc.humidity, last-value=59.37, new-value=59.37, ts=1518659913496

2018-02-15 02:58:38.954 - debug: sql.0 new value received for ping.1.raspberrypi3.www_google_de, new-value=true, ts=1518659918951, relog=false

2018-02-15 02:58:38.955 - debug: sql.0 value not changed ping.1.raspberrypi3.www_google_de, last-value=true, new-value=true, ts=1518659918951

2018-02-15 02:58:43.497 - debug: sql.0 Datatype mihome.0.devices.sensor_ht_158d000149c2cc.humidity: Currently: number, StorageType: Number

2018-02-15 02:58:43.498 - debug: sql.0 INSERT INTO iobroker.ts_number (id, ts, val, ack, _from, q) VALUES(13, 1518659913485, 59.37, 1, 7, 0); `

Log 3:50 Uhr:

! > 2018-02-15 03:49:57.010 - debug: sql.0 INSERT INTOiobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(1, 1518662996005, 49.39, 1, 1, 0);

2018-02-15 03:50:13.849 - debug: sql.0 new value received for ping.1.raspberrypi3.www_google_de, new-value=true, ts=1518663013845, relog=false

2018-02-15 03:50:13.850 - debug: sql.0 value not changed ping.1.raspberrypi3.www_google_de, last-value=true, new-value=true, ts=1518663013845

2018-02-15 03:50:43.900 - debug: sql.0 new value received for ping.1.raspberrypi3.www_google_de, new-value=true, ts=1518663043895, relog=false

2018-02-15 03:50:43.900 - debug: sql.0 value not changed ping.1.raspberrypi3.www_google_de, last-value=true, new-value=true, ts=1518663043895

2018-02-15 03:50:53.970 - debug: sql.0 new value received for mihome.0.devices.sensor_ht_158d000149c2cc.temperature, new-value=19.35, ts=1518663053963, relog=false

2018-02-15 03:50:53.971 - debug: sql.0 Min-Delta reached mihome.0.devices.sensor_ht_158d000149c2cc.temperature, last-value=19.28, new-value=19.35, ts=1518663053963

2018-02-15 03:50:53.971 - debug: sql.0 Datatype mihome.0.devices.sensor_ht_158d000149c2cc.temperature: Currently: number, StorageType: Number

2018-02-15 03:50:53.972 - debug: sql.0 INSERT INTO iobroker.ts_number (id, ts, val, ack, _from, q) VALUES(14, 1518659913494, 19.33, 1, 7, 0);

2018-02-15 03:50:53.981 - debug: sql.0 new value received for mihome.0.devices.sensor_ht_158d000149c2cc.humidity, new-value=58.49, ts=1518663053968, relog=false

2018-02-15 03:50:53.982 - debug: sql.0 Min-Delta reached mihome.0.devices.sensor_ht_158d000149c2cc.humidity, last-value=59.37, new-value=58.49, ts=1518663053968

2018-02-15 03:50:53.982 - debug: sql.0 Datatype mihome.0.devices.sensor_ht_158d000149c2cc.humidity: Currently: number, StorageType: Number

2018-02-15 03:50:53.983 - debug: sql.0 INSERT INTO iobroker.ts_number (id, ts, val, ack, _from, q) VALUES(13, 1518659913496, 59.37, 1, 7, 0);

2018-02-15 03:50:53.999 - debug: sql.0 new value received for mihome.0.devices.sensor_ht_158d000149c2cc.temperature, new-value=19.35, ts=1518663053989, relog=false

2018-02-15 03:50:54.000 - debug: sql.0 value not changed mihome.0.devices.sensor_ht_158d000149c2cc.temperature, last-value=19.35, new-value=19.35, ts=1518663053989

2018-02-15 03:50:54.005 - debug: sql.0 new value received for mihome.0.devices.sensor_ht_158d000149c2cc.humidity, new-value=58.49, ts=1518663053991, relog=false

2018-02-15 03:50:54.005 - debug: sql.0 value not changed mihome.0.devices.sensor_ht_158d000149c2cc.humidity, last-value=58.49, new-value=58.49, ts=1518663053991

2018-02-15 03:50:56.561 - debug: sql.0 new value received for rpi2.0.temperature.soc_temp, new-value=48.85, ts=1518663056559, relog=false

2018-02-15 03:50:57.563 - debug: sql.0 Datatype rpi2.0.temperature.soc_temp: Currently: number, StorageType: Number

2018-02-15 03:50:57.564 - debug: sql.0 INSERT INTO iobroker.ts_number (id, ts, val, ack, _from, q) VALUES(1, 1518663056559, 48.85, 1, 1, 0);

2018-02-15 03:51:03.975 - debug: sql.0 Datatype mihome.0.devices.sensor_ht_158d000149c2cc.temperature: Currently: number, StorageType: Number

2018-02-15 03:51:03.976 - debug: sql.0 INSERT INTO iobroker.ts_number (id, ts, val, ack, _from, q) VALUES(14, 1518663053963, 19.35, 1, 7, 0);

2018-02-15 03:51:03.989 - debug: sql.0 Datatype mihome.0.devices.sensor_ht_158d000149c2cc.humidity: Currently: number, StorageType: Number

2018-02-15 03:51:03.990 - debug: sql.0 INSERT INTO iobroker.ts_number (id, ts, val, ack, _from, q) VALUES(13, 1518663053968, 58.49, 1, 7, 0); `

Hoffe, das hilft weiter…
2700_sql_dopplungen.png

apollon77

Aaaaalso … ist kein echtes Doppellogging, sieht nur so aus :-)

Die Logik funktioniert wie folgt:

Wenn Datenpunkte nicht geloggt werden weil Sie "verworfen" werden - in deinem Fall weil sich der Wert nicht geändert hat - wird der letzte dieser "verworfenen" Werte intern gespeichert. Sobald die nächste Änderung kommt wird dieser Wert dann zusätzlich in der Db gespeichert um eine korrekte Grafik zu bekommen wenn man die Daten visualisiert. Somit hättest Du dann so lange der Wert gleich geblieben ist das auch Grafisch so dargestellt (gerade Linie) und erst danach die Änderung zum neuen Wert. Viele Diagrammtools verbinden nur die Punkte 8es sei denn man kann "Treppendarstellung" wählen.

An der Stelle ist interessant das der "mihome"-Adapter so kurz nacheinander den gleichen Wert generiert. Das wäre eher das was interessant ist.

apollon77

~~@Kueppert:~~

Have jetzt auch nochmal wegen der Löcher in der Darstellung bei flot geschaut. Hänge das Ergebnis hier an. Ggf macht es Sinn, dass der flot Entwickler auch da auch einschaltet? `

Hier ist die Frage was für Daten im Hintergrund existieren. Also man müsste schauen was genau an "GetHistory" als Daten zurückkommen.

BBTown

Ich habe gerade gesehen dass es eine v.1.7.1 gibt und diese Installiert.

Erneut ist mein Raspi dabei eingefroren :(

Ich habe mal einen ScreenShot des letzten Zustandes beim freeze angefügt, vlt ist der hilfreich?!

[EDIT] ich sehe gerade erneut den Eintrag bzgl. SQL-Lite
1917_sql_adapzer_log.jpg

apollon77

Naja, wie zuletzt gesagt: Die letzte Meldung sagt das er "sqlite" kompilieren muss und das wohl auch tut. Ich kann da nichts tun :-(

Ein anderer user hatte erfgolg mit einem Update per Konsole indem er ioBroker vorher gestoppt hat. Scheinbar wird viel CPU/RAM bei dem Kompilieren gebraucht und es lief durch von nicht viel neben her auf dem Rechner lief. versuch das mal.

Wenn Du sqlite nicht brauchst sollte nach einem "ipbroekr upload sql" alles aktuell sein mit der 1.7.1 trotzdem :-)

Kueppert

~~@apollon77:~~

Naja, wie zuletzt gesagt: Die letzte Meldung sagt das er "sqlite" kompilieren muss und das wohl auch tut. Ich kann da nichts tun :-(

Ein anderer user hatte erfgolg mit einem Update per Konsole indem er ioBroker vorher gestoppt hat. Scheinbar wird viel CPU/RAM bei dem Kompilieren gebraucht und es lief durch von nicht viel neben her auf dem Rechner lief. versuch das mal.

Wenn Du sqlite nicht brauchst sollte nach einem "ipbroekr upload sql" alles aktuell sein mit der 1.7.1 trotzdem :-) ` Hi,

jaaa, ich habe immer das Problem beim SQL Update das der pi3 einfriert. Updates mache ich daher nur noch über die Konsole. Mache daneben eine 2. Konsole auf im mit dem Befehl TOP die Auslastung zu kontrollieren.

Wichtig ist, vorher den ioBroker zu stoppen… Ich gehe davon aus, dass der RAM das Problem ist.

Gesendet von meinem HUAWEI RIO-L01 mit Tapatalk

BBTown

Ich brauche sqlite nicht, und nach einem reboot des Raspi (Stecker zeiehn 8-) ) kommt der SQL-Adapter auch korrekt in der v.1.7.1 hoch.

Ein wenig hatte ich die Hoffnung, dass beim Update ggf. sqlite ignoriert werden kann, wenn es gar keine sqlite vorinstalltion (Konfiguration) gibt.

BBTown

Dennoch natürlich danke für den Hinweis auf den Workaround, ich werde versuchen mir den zu merken 8-)

apollon77

~~@BBTown:~~

Ein wenig hatte ich die Hoffnung, dass beim Update ggf. sqlite ignoriert werden kann, wenn es gar keine sqlite vorinstalltion (Konfiguration) gibt. `

Dann müste man zwei Adapter machen. Einmal "sql mit sqlite" und einmal "sql ohne". Dadurch das sqlite in den dependecy vom Paket steht macht npm das halt immer :-( Der Installationsprozess weiss ja nicht was Du nutzen willst.

grundsätzlich sage ich mal das einer von Euch sehr gern mal unter https://github.com/mapbox/node-sqlite3/issues ein Issue auf machen sollte das der Buildprozess auf einem RaspiX viel Speicher bla brauct … die sind die einzigen die da was checken und optimieren können.

BBTown

~~@apollon77:~~

grundsätzlich sage ich mal das einer von Euch sehr gern mal unter https://github.com/mapbox/node-sqlite3/issues ein Issue auf machen sollte das der Buildprozess auf einem RaspiX viel Speicher bla brauct ` Ich habe da mal ein issue erstellt, in der Hoffnung dass mein Anliegen verstanden wird 8-)

Ich will das auch gar nicht zu hoch aufhängen, womöglich betrifft das ganze Procedere gar nicht viele Anwender und es gäbe ja auch einen Workaround.

Da ich kein Programmierer bin, ist meine Vorstellung davon wo man womöglich etwas umschiffen/optimieren kann ja durchaus mitunter weit weg von der Realität ;)

Community Forum

NEWS

[Aufrug] sql 1.7.0 testen

Support us

917

32.4k

81.5k

1.3m