SQL History - Entprellzeit/Gleiche Werte Speichern bei minimaler Abweichung
-
Also ich habe gestern von einem Teil der Datenpunkte die Settings hin und her geändert.
Danach sieht man für diesen Teil folgendes:
26.1 true hm-rpc.1 2017-08-01 09:54:30.139
25.6 true hm-rpc.1 2017-08-01 09:45:55.462
25.1 true hm-rpc.1 2017-08-01 09:31:29.208
25.5 true hm-rpc.1 2017-08-01 09:01:32.018
25.5 true hm-rpc.1 2017-08-01 08:58:57.320
25 true hm-rpc.1 2017-08-01 08:54:35.760
24.5 true hm-rpc.1 2017-08-01 08:51:42.798
24 true hm-rpc.1 2017-08-01 08:48:37.164
23.5 true hm-rpc.1 2017-08-01 08:44:36.695
23 true hm-rpc.1 2017-08-01 08:31:39.036
22.9 true hm-rpc.1 2017-08-01 08:20:17.020
22.4 true hm-rpc.1 2017-08-01 08:11:21.231
21.9 true hm-rpc.1 2017-08-01 08:06:21.703
21.4 true hm-rpc.1 2017-08-01 08:01:41.876
21 true hm-rpc.1 2017-08-01 07:55:44.667
20.5 true hm-rpc.1 2017-08-01 07:49:54.508
20 true hm-rpc.1 2017-08-01 07:31:44.670
19.8 true hm-rpc.1 2017-08-01 07:12:00.584
19.3 true hm-rpc.1 2017-08-01 07:01:47.458
19 true hm-rpc.1 2017-08-01 06:52:23.594
18.5 true hm-rpc.1 2017-08-01 06:32:02.936
18.5 true hm-rpc.1 2017-08-01 06:02:14.187
18.5 true hm-rpc.1 2017-08-01 05:50:35.271
18 true hm-rpc.1 2017-08-01 05:32:17.012
17.9 true hm-rpc.1 2017-08-01 05:02:24.018
18 true hm-rpc.1 2017-08-01 04:32:31.043
D.h. Die Datenpunkte werden alle 30Minuten mit dem aktuellen Wert gelogged. Damit scheint die Änderung zu funktionieren.
Das kann ich auch bei anderen Datenpunkten sehen.
Aber:
Warum wird z.B. der Wert 25.5 um 9:01 erneut gelogged? Davor wurde der gleiche Wert wegen der Hysterese um 8:58 geschrieben. Wir dann das Timeout nicht neu gestartet? Ich habe ein paar weitere mit nicht verständliche Zeitpunkte markiert.
Warum hat das zyklische Loggen erst nach dem Ändern der Parameter funktioniert?
Die Datenpunkte, bei denen ich die Parameter nicht verändert/aufgefrischt hatte, wird nur beim Erreichen der Hysterese gelogged.
Diese Fehler haben denke ich nichts mit den neuen Änderungen zu tun => Neuer Thread?
Heute aktiviere ich das Logging (in genau diesem Zustand) und schaue mir das an. Wie kann ich Dir die Logs zukommen lassen?
Zur Entprellzeit: Die ist aus meiner Sicht ok. Die Werte ändern sich langsam genug. Dazu habe ich mir eine Zeit lang die Ereignisse für die Datenpunkte angesehen. Zudem sollen ja gerade kurze Wackler gefiltert werden.
-
Ich habe den Code nochmal gecheckt und da sieht alles gut aus. Eine Bitte: Stelle sicher das nicht aus irgendeinem grund zwei Prozesse vom sql-Adapter laufen … nur so zur Sicherheit
Und sonst hilft mir nur noch das Debug-Log um es zu verstehen ...
Eine Info noch für dich: Nach dem Start des Adapters werden die ganzen "Gleiche Werte Erneut in x Minuten Loggen"-Timer NICHT alle auf einmal gestartet (würden dann ja auch alle auf einmal wieder laufen und ggf zu einer Lastspitze führen). Die werden zufällig gestartet. Eine Änderung des Wertes stoppt die dann und startet Sie neu. Damit ist es verteilt. Das erste falls es keine Änderung gab kann aber ggf komisch sein.
-
Ggf. Nach der installation noch ein````
sudo iobroker sql stop
sudo iobroker upload sql
sudo iobroker sql startGruß Rainer -
Rainer, das ist in dem Fall unnötig … Aber ja. stop, Prozesse checken und dann start
-
Hi, habe es kontrolliert, Adapter wurde neu gestartet und es läuft nur eine Instanz.
Das Komische ist, nach einem Adapter-Neustart funktioniert erst nur die Hysterese.
Das kann man auch im Log sehen.
Z.B. Datenpunkt hm-rpc.1.CUX1200002.1.TEMPERATURE
Um 10:15 Logging gestartet (Level auf Debug) => Adapter startet neu
Für den Datenpunkt gibt es keinen "timed relog".
Ändere ich die Settings bekomme ich unabhängig von der Hysterese "timed Relogs" alle 30min.
Diese sollten aus meiner Sicht aber nicht anschlagen, da es häufiger als 30min relogs wegen der Hysterese gibt.
@apollon77: Link zu den Logs kommt als PN
Ich bin noch dran aus den Logs und den gespeicherten Werten weitere Muster zu finden.
Grüße,
Michael
-
Super, ich glaube ich habe den grund gefunden.
Der Re-log-Timer wurde immer direkt neu gestartet sobald es einen neuen Wert gab und nicht erst die ganzen Checks gemacht.
Bitte 1.5.6 von Github versuchen.
der hm-rpc.1.CUX1200002.1.TEMPERATURE ist ein super Beispiel gewesen weil sich da der Wert faktisch sehr selten ändert.
-
Hi Apollon77 - super! Update ist gemacht. Schaue mir die Werte später an.
-
Hallo zusammen: Habe mir gerade die gespeicherten Werte mit der 1.5.6 angesehen.
Sieht gut aus.
Die Werte werden wie erwartet nach der Relog-Zeit gespeichert oder wenn die Hysterese überschritten wurde.
Es war nicht nötig irgendwelche Einstellungen zu ändern, es hat direkt nach dem Update korrekt funktioniert.
Kann das sonst jemand bestätigen?
Danke schon mal!
-
Auf Github gibt es die gleichen Änderungen jetzt auch in neuen Versionen für influxdb und history. Wer also das im Einsatz hat kann das jetzt auch testen
-
Wollte gerade mal die neue Version testen. Bekomme die aber einfach nicht installiert. Obwohl lt. Log alles OK aussieht (?) bleibt der Adapter auf der momentan installierten Version 1.5.3. Habe dabei festgestellt dass auch ein Update auf die "offiziell" angebotene Version 1.5.4 den gleichen Effekt hat - keine Fehler, aber auch keinen Effekt.
Was ist denn da nun wieder los? Reboot hab ich zwischendurch (sogar mehrfach) versucht…
<code>2017-08-03 11:26:47.156 - [32minfo[39m: iobroker url "https://github.com/ioBroker/ioBroker.sql/tarball/master" sql 2017-08-03 11:26:50.935 - [32minfo[39m: iobroker install https://github.com/ioBroker/ioBroker.sql/tarball/master 2017-08-03 11:26:51.558 - [32minfo[39m: iobroker npm install https://github.com/ioBroker/ioBroker.sql/tarball/master --production --prefix "C:/ioBroker" (System call) 2017-08-03 11:28:03.007 - [32minfo[39m: iobroker npm 2017-08-03 11:28:03.013 - [32minfo[39m: iobroker WARN deprecated node-uuid@1.4.8: Use uuid module instead 2017-08-03 11:28:24.909 - [32minfo[39m: iobroker got C:/ioBroker/node_modules/iobroker.sql/admin 2017-08-03 11:28:24.937 - [32minfo[39m: iobroker upload [3] sql.admin C:/ioBroker/node_modules/iobroker.sql/admin/words.js words.js application/javascript 2017-08-03 11:28:25.074 - [32minfo[39m: iobroker upload [2] sql.admin C:/ioBroker/node_modules/iobroker.sql/admin/sql.png sql.png image/png 2017-08-03 11:28:25.162 - [32minfo[39m: iobroker upload [1] sql.admin C:/ioBroker/node_modules/iobroker.sql/admin/index.html index.html text/html 2017-08-03 11:28:25.262 - [32minfo[39m: iobroker upload [0] sql.admin C:/ioBroker/node_modules/iobroker.sql/admin/custom.html custom.html text/html 2017-08-03 11:28:25.405 - [32minfo[39m: iobroker exit 0[/code]</code> -
Hast Den den Adapter nach dem Install mal neu gestartet? Bei Github-Installs passiert das meistens nicht.
Passt die Versionsnummer dann vllt beim Start im Log?
-
Du hast Recht, lt. Log wird die Version 1.5.6 gestartet. Angezeigt wird mir im Admin aber immer noch die 1.5.3!
Hängt das jetzt nur mit Github zusammen oder sollte ich da mal nen separaten Thread dazu aufmachen?
-
Mach mal ein
iobroker upload sql
und wenn es dann immer noch so ist iobroker stop/start
Ingo F
-
leider - nach upload und anschließendem Neustart immer noch das gleiche…
-
Hast Du mal nen Screenshot?!
-
Wovon? Das hier?
-
Hi, dass die Änderung grundsätzlich so passt kann ich weiter bestätigen. Habe die githu 1.5.6 im Einsatz.
Jetzt ist mir aber kleines Problem beim Re-Log aufgefallen:
Wenn ich per Filter die sql-Log-Einstellung von mehreren Objekten ändere, dann wird ab sofort doppelt gelogged. Also z.B.
Timeout auf 3600s:
1:55
2:01
2:55
3:01
Wie als würden zum Zeitpunkt der Settings-Änderungen eine zweite Serie parallel aufgesetzt werden - nur so eine Vermutung.
Wenn ich den Adapter neu starte passt es wieder.
-
Hey,
na Du findest ja Sachen
Fixed auf Github. Ich habe aber die Version deswegen nicht nochmals geändert … also neu installieren und restarten ...
-
Neue Versionen sind jetzt auch offiziell auf npm gepublished und damit für ioBroker im "Latest". Stable mach ich nach meinem urlaub
