SQL History - Entprellzeit/Gleiche Werte Speichern bei minimaler Abweichung
-
Also ich hätte auch ganz intuitiv und logisch erwartet dass sich der Adapter bereits so verhält wie du, Apollon, jetzt vorgeschlagen hast. Inclusive der "Neujustierung" der Hysterese beim Loggen wegen "Zeitüberschreitung".
Dass ich bis jetzt noch nicht bemerkt habe dass es anders ist liegt wohl daran dass ich einerseits die Log-parameter recht großzügig eingestellt habe und andererseits kein pedantischer Mensch bin
-
Na, dann bitte mal Github Version 1.5.5 versuchen.
1.) Tuts jetzt wie erwartet?
2.) Tut der Rest noch?
Es wird jetzt beim zeitlichen Logging einfach immer der aktuellste Wert des States geladen, geloggt und als neuer Referenzwert gesetzt.
-
Wird das dann auch für die anderen History-Adapter übernommen?
-
Wenn es hier bestätigt ist dann ja
-
Hi,
das geht ja flott!
Ich schließe mich den Vor-Postern an: Die Hysterese sollte ausgehend vom letzten gespeicherten Wert neu starten. D.h. <=0.9 oder >=1.9.
Werde die neue Version heute mal laufen lassen. Dann kann ich Feedback geben.
Danke!
-
So, habe das 1.5.5 Plugin laufen lassen.
Datenpunkte wie folgt konfiguriert:
Nur Änderungen aufzeichnen: ja
Entprellzeit 10000ms
Gleiche Werte aufzeichnen 1800s
Minimale Abweichung: 0,5
Die Daten kommen mit knapp 10s Abstand
Für mich gibt es ein paar Ungereimtheiten:
Ich hatte das Plugin aus Github aktualisiert und die Einstellungen für meine Datenpunkte angepasst:
Ein paar mal wurde der gleiche Wert nach Ansprechen der Hysterese erneut gelogged.
Wurde hier ein Timer nicht zurückgesetzt?
33.4 true hm-rpc.1 2017-07-31 15:09:00.458
33.6 true hm-rpc.1 2017-07-31 14:56:50.612
34.1 true hm-rpc.1 2017-07-31 14:53:56.245
34.1 true hm-rpc.1 2017-07-31 14:42:00.465
33.6 true hm-rpc.1 2017-07-31 14:36:39.834
34.1 true hm-rpc.1 2017-07-31 14:23:59.053
34.1 true hm-rpc.1 2017-07-31 14:21:24.352
33.6 true hm-rpc.1 2017-07-31 13:57:17.325
33.1 true hm-rpc.1 2017-07-31 13:54:14.522
33.1 true hm-rpc.1 2017-07-31 13:52:43.103
32.6 true hm-rpc.1 2017-07-31 13:43:38.893
33.1 true hm-rpc.1 2017-07-31 13:24:17.320
33.1 true hm-rpc.1 2017-07-31 13:20:43.562
32.6 true hm-rpc.1 2017-07-31 13:15:22.969
33.1 true hm-rpc.1 2017-07-31 12:54:24.351
33.1 true hm-rpc.1 2017-07-31 12:52:48.717
32.6 true hm-rpc.1 2017-07-31 12:45:42.622
32.1 true hm-rpc.1 2017-07-31 12:24:25.740
32.1 true hm-rpc.1 2017-07-31 12:23:04.190
31.6 true hm-rpc.1 2017-07-31 11:50:14.025
Um 15:08 habe ich deswegen den Adapter neu gestartet. Danach hat nur noch Hysterese angesprochen, nicht aber die "Gleiche Werte aufzeichnen" Zeit. Dadurch konnte ich nicht prüfen, ob die Änderung zu 1.5.5 überhaupt funktioniert.
20.9 true hm-rpc.1 2017-07-31 22:53:50.668
21.4 true hm-rpc.1 2017-07-31 22:13:37.545
21.9 true hm-rpc.1 2017-07-31 21:46:45.983
22.4 true hm-rpc.1 2017-07-31 21:25:48.782
22.9 true hm-rpc.1 2017-07-31 21:02:57.697
23.4 true hm-rpc.1 2017-07-31 20:40:15.020
23.9 true hm-rpc.1 2017-07-31 20:22:48.782
24.4 true hm-rpc.1 2017-07-31 19:55:19.241
24.9 true hm-rpc.1 2017-07-31 19:38:01.432
25.4 true hm-rpc.1 2017-07-31 19:06:35.640
25.9 true hm-rpc.1 2017-07-31 17:29:50.635
26.4 true hm-rpc.1 2017-07-31 17:13:44.536
26.9 true hm-rpc.1 2017-07-31 17:07:41.738
27.4 true hm-rpc.1 2017-07-31 16:55:44.537
27.9 true hm-rpc.1 2017-07-31 16:47:01.419
28.4 true hm-rpc.1 2017-07-31 16:43:13.599
28.9 true hm-rpc.1 2017-07-31 16:40:07.979
29.4 true hm-rpc.1 2017-07-31 16:38:01.427
29.9 true hm-rpc.1 2017-07-31 16:36:24.388
30.4 true hm-rpc.1 2017-07-31 16:34:22.040
30.9 true hm-rpc.1 2017-07-31 16:12:17.345
31.4 true hm-rpc.1 2017-07-31 15:52:27.656
31.9 true hm-rpc.1 2017-07-31 15:46:58.600
32.4 true hm-rpc.1 2017-07-31 15:40:05.148
32.9 true hm-rpc.1 2017-07-31 15:18:55.308
33.4 true hm-rpc.1 2017-07-31 15:09:00.458
Aus meiner Sicht scheint es mit dem "Gleiche Werte aufzeichen"-Timer noch ein Problem zu geben. Zum einen beim Aufsetzten beim Adapter-Start, als auch das Re-Triggern nach dem Auslösen der Hysterese.
Kann das sein?
-
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 -
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
