SQL History - Entprellzeit/Gleiche Werte Speichern bei minimaler Abweichung
-
Bei Github-Installs kann es sein das der Adapter nicht automatisch neu gestartet wird, also ist erstmal nur alles aussagekräftig was seit dem neustart war :-)
Kannst Du es mal mit Debug laufen lassen und schauen was das Log so sagt?
Ansonsten: Wenn die Werte mit 10s Abstand kommen und die Entprellzeit 10s ist dann ist das knapp weil dann ggf Werte aussortiert werden. Am besten Entprellzeit runtersetzen!
Das interessante ist das icn der Timerlogik an sich nichts geändert habe, sondern nur das beim "zuschlagen" des Timers immer der aktuellste Wert genommen wird und nicht der "letzte".
-
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 -
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.
-
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!
-
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> -
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.
329
Online32.7k
Benutzer82.5k
Themen1.3m
Beiträge