Monatsrückblick Januar/Februar 2026 ist online!

[Huebeni]

Hallo,

ich nutze ioBroker seit Mitte letzten Jahres auf einem Raspberry PI und logge die Temperatur und Luftfeuchtigkeit von einigen Sensoren (Technoline TX-35 DTH an Jeelink).

Nach dem Update des sql-History Plug-Ins bin ich auch über die Entprellzeit gestolpert. Ursprünglich hatte ich alle 10Minuten gelogged. Jetzt versuche ich folgendes zu erreichen:

Abweichungen >0,5 sollen sofort gespeichert werden.

Mindestens soll aber alle 30Min gelogged werden - dann aber der aktuelle Wert.

Einstellungen der Datenpunkte ist jetzt:

Nur Änderungen aufzeichnen: ja

Entprellzeit 1000ms

Gleiche Werte aufzeichnen 1800s

Minimale Abweichung: 0,5

Version iobroker.sql: 1.5.4

Mein Problem:

Wenn die Werte sich langsam ändern gibt es ein mir nicht verständliches Verhalten.

Ich sehe in den Charts, dass zwar Werte gespeichert werden (alle 1800s), aber dann immer der alte Wert. Erst, wenn die 0,5 überschritten werden, dann der aktuelle. Was macht das für einen Sinn?

Ich will doch nicht genau den gleichen Wert alle 30Min speichern, wenn der tatsächliche sich weniger als die Hyterese geändert hat, sondern den aktuellen.

Ist das tatsächlich so, oder mache ich eine Fehler?

Sollte man das nicht ändern?

Danke schon mal,

Michael

[apollon77]

Hi,

So einen Kombi-Anwendungsfall hatte bisher wohl noch keiner.

Jetzt dann eine Frage wie es sich dann in Deinen Augen verhalten sollte.

Annahme:

Wert zuletzt geloggt ist 1.

Wert ändert sich langsam. nach 30 Minuten ist der Wert 1.4 und ist mit Deinen Einstellungen oben noch nicht geloggt worden.

Wenn ich es so anpasse wie von Dir vorgeschlagen würde jetzt der Wert 1.4 geloggt.

Soll dann ausgehend von dem Wert die Hysterese wieder starten … also nächster geloggter Wert ist erst <=0.9 oder >=1.9 oder gilt weiterhin die Hysterese wie davor, in dem Fall also <=0.5/>=1.5 ?!

Eigentlich wäre der erste Vorschlag in meinen Augen konsistent ... ob er von den leuten aber "erwartet" wird weiss ichnicht :-)

Was denkst Du?

[Pman]

Ich würde intuitiv das erste von dir beschriebene Verhalten erwarten.

[Homoran]

Hallo Apollon,

Ich bin zwar nicht der TE, aber Fall 1 ist für mich absolut logisch. Ich hätte aufgrund der möglichen Einstellungen ebenso wie der TE sogar erwartet, dass dies so umgesetzt ist.

Gruß

Rainer

[apollon77]

TE? Thread-Ersteller? :-)

Ok, also +1 für Option 1 … wer hat noch eine Meinung :-)

[AlCalzone]

Logisch wäre für mich, wenn immer der aktuelle Wert gespeichert wird und die konfigurierten Eigenschaften sozusagen als Trigger bezogen auf den letzten gespeicherten Wert gesehen werden. D.h.

• Wert hat sich um mindestens 0,5 geändert => aktuellen Wert speichern.

• Seit 1800s kein Wert gespeichert => aktuellen Wert speichern.
  D.h die Hysterese sollte in deinem Beispiel IMO 0,9..1,9 sein.

[Thisoft]

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 ;)

[apollon77]

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.

[AlCalzone]

Wird das dann auch für die anderen History-Adapter übernommen?

[apollon77]

Wenn es hier bestätigt ist dann ja ;-)

[Huebeni]

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!

[Huebeni]

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?

[apollon77]

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".

[Huebeni]

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.

[apollon77]

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.

[Homoran]

Ggf. Nach der installation noch ein````
sudo iobroker sql stop
sudo iobroker upload sql
sudo iobroker sql start

Gruß

Rainer

[apollon77]

Rainer, das ist in dem Fall unnötig … Aber ja. stop, Prozesse checken und dann start :-)

[Huebeni]

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

[apollon77]

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.

[Huebeni]

Hi Apollon77 - super! Update ist gemacht. Schaue mir die Werte später an.