NEWS
zeitverzögertes Auswerten / Jitter
-
@thaistatos sagte: ist der Timeout Block (nach dem nicht) eine interne Variable?
timeout
ist eine globale Variable. Es gibt sie auch in grün, nachdem der Timeout-Block in das Skript gezogen wurde.@thaistatos sagte in zeitverzögertes Auswerten / Jitter:
der Trigger kommt ja trotzdem 2x kurz nacheinander.
Der zweite Trigger wird gesperrt, wenn er innerhalb von 100 ms nach dem ersten Trigger erfolgt.
-
@thaistatos Ich glaube, über das gleiche Problem ist auch @haus-automatisierung gestolpert. In einem seiner Videos zeigt er javascript code, wie er die ganzen Trigger erst durch ein Javascript-Programm vorverarbeitet, bevor er daraus am Influx Adapter vorbei Datenreihen für die InfluxDB macht.
VIelleicht finden sich da Anregungen, um das hier ja ähnlich gelagerte Problem zu lösen.
-
@martinp Du meinst das hier? https://www.youtube.com/watch?v=rTLQ15Fy85U
Bei mir führt einfach jede Änderung eines Datenpunktes zum speichern aller momentanen Werte. Und später nehme ich das dann mit InfluxDB-Tasks auseinander und verwerfe die ganzen alten (redundanten) Daten über die Retention Time auf dem Bucket.
-
inspiriert durch
https://forum.iobroker.net/topic/13916/gelöst-suche-funktion-zum-entprellen-über-5-sec
und
https://forum.iobroker.net/topic/18638/gelöst-entprellen-von-schaltern/2habe ich jetzt so nachgebaut:
Aber der Verzögerung Block macht wahrscheinlich was ähnliches, nur schöner.
-
@thaistatos sagte: habe ich jetzt so nachgebaut:
Problem: Die Berechnung erfolgt bereits mit dem ersten Trigger und deshalb passen die Werte zeitlich nicht zusammen.
In dieser Version erfolgt die Berechnung sofort nach dem zweiten Trigger (innerhalb 100 ms):
-
muss in das zweite Kommentarfeld auch noch etwas eingetragen werden?
-
@thaistatos sagte: muss in das zweite Kommentarfeld auch noch etwas eingetragen werden?
Nein, das ist nur eine Erläuterung zum Verständnis. Seit JS Version 7.0.5 wird in dem Block nach Ablauf des Timeouts die Variable automatisch auf null gesetzt.
-
muss er timeout noch initialisiert werden?
Mir ist noch nicht klar, warum die Berechnung erst mit dem zweiten Trigger startet?
Oder startet sie eher nach 100ms? -
@thaistatos sagte: warum die Berechnung erst mit dem zweiten Trigger startet?
Beim ersten Trigger ist
timeout
null und es wird der sonst-Zweig ausgeführt, also der Timeout gestartet. Beim zweiten Trigger läuft der Timeout und es wird der mache-Zweig ausgeführt, also die Berechnung. -
@thaistatos sagte in zeitverzögertes Auswerten / Jitter:
Mir ist noch nicht klar, warum die Berechnung erst mit dem zweiten Trigger startet?
tut sie nicht, die Berechnung durchvden zweiten Trigger wird blockiert.
Deswegen
@paul53 sagte in zeitverzögertes Auswerten / Jitter:
Problem: Die Berechnung erfolgt bereits mit dem ersten Trigger und deshalb passen die Werte zeitlich nicht zusammen.
@thaistatos sagte in zeitverzögertes Auswerten / Jitter:
Oder startet sie eher nach 100ms?
ja
-
@homoran sagte: tut sie nicht
@thaistatos meint diese Version.
-
das setzt dann aber voraus, dass immer der der zweite Trigger kommt. Es kann ja auch nur Trigger 1 ausgelöst werden, dann würde gar nichts passieren.
-
@thaistatos sagte: das setzt dann aber voraus, dass immer der der zweite Trigger kommt.
Richtig. Kommt nicht immer ein zweiter Trigger? Dann muss die Verzögerung um 100 ms in Kauf genommen werden.
-
sehr wahrscheinlich kommt auch Trigger 2, aber muss eben nicht.
Ich will mit 100ms Verzögerung nach dem letzten Trigger die Berechnung ausführen.
Also T1, 10ms später T2: Berechnung bei Zeitstempel 100ms nach T1.
nur T1: Berechnung bei Zeitstempel 100ms nach T1.
nur T2: Berechnung bei Zeitstempel 100ms nach T2. -
@thaistatos
Das macht diese Version. -