clear Timeout funktioniert nicht mehr
-
@sub1ne sagte: ich reagiere auf die Wertänderung von "deconz.0.Sensors.6.open" - einmal wenn er "true" wird, einmal, wenn er "false" wird.
Nein, der Trigger reagiert nicht nur auf Wertänderung, sondern auch dann, wenn der Zeitstempel bei gleich bleibendem Wert aktualisiert wird.
@sub1ne sagte in clear Timeout funktioniert nicht mehr:
Dort gibt es weder in Zeile 1 eine Deklaration von catModeTimeout
Das kann ich bei mir nicht nachvollziehen.
-
@paul53 said in clear Timeout funktioniert nicht mehr:
Das kann ich bei mir nicht nachvollziehen.
d.h. wenn du in deinem MIT Blockly generierten Skript auf Javascript umschaltest wird in Zeile 1 ein
var myTimeout = null;gemacht? Das ist bei mir definitiv nicht der Fall...
-
@sub1ne die Ursache warum dein Skript nicht funktioniert hat hat @paul53 Bereits oben erwähnt:
Ein trigger auf “ist wahr” wird jedes Mal aktiv wenn der datenpunkt mit wahr aktualisiert wird. Das kann öfter sein als man denkt.
Was dann passiert ist einfach. Es wird ein zweiter timeout gestartet und der gleichen Variable zugeordnet. Damit kann der erste timeout nicht mehr angehalten werden.
Ein sauberer Weg auf die Änderung falsch/wahr zu trigger ist ein trigger auf “ist größer als vorher”, (bei falsch: ist kleiner als vorher)
Wenn du in deinem originalen Blockly die triggerbedi ging anpasst dann sollte es also auch gehen.
Das die Variable vor dem “setTimeout” nicht deklariert wird liegt wahrscheinlich daran das die timeout Benennungen initial nicht wie “benutzerdefinierte” Variablen behandelt werden. Sie stehen ja auch nicht in der “variablen” Liste von Blockly.
A.
-
@sub1ne sagte: Blockly generierten Skript auf Javascript umschaltest wird in Zeile 1 ein
var timeout;gemacht. Enthält undefined.
-
@asgothian sagte in clear Timeout funktioniert nicht mehr:
Ein trigger auf “ist wahr” wird jedes Mal aktiv wenn der datenpunkt mit wahr aktualisiert wird. Das kann öfter sein als man denkt.
Ein sauberer Weg auf die Änderung falsch/wahr zu trigger ist ein trigger auf “ist größer als vorher”, (bei falsch: ist kleiner als vorher)
Nur mal kurz geräubert,
das heißt also, so
ist besser als so?
-
@nordischerjung
Besser und besser.In genau dem Beispiel ist das Ergebnis ziemlich gleich. Ich ziehe das erste vor, insbesondere wenn mich der gegenteilige Fall nicht interessiert.
Das gilt so lange wie im falls der “wert” Baustein genutzt wird.
A.
-
-
@paul53 Ja danke, das hatte ich mir so auch schon überlegt.
-
@asgothian said in clear Timeout funktioniert nicht mehr:
Ein trigger auf “ist wahr” wird jedes Mal aktiv wenn der datenpunkt mit wahr aktualisiert wird.
demnach ist der generierte Eventbehandler
on({id: 'deconz.0.Sensors.6.open', val: true}, async function (obj) {...});schlecht gewählt, die Javascript API gibt da laut Doku (https://github.com/ioBroker/ioBroker.javascript/blob/master/docs/en/javascript.md#on---subscribe-on-changes-or-updates-of-some-state) bessers her, nämlich:
on({id: 'deconz.0.Sensors.6.open', val: true, oldVal: false}, async function (obj) {...});somit reagiert der Trigger nur auf Änderungen von false auf true.
@asgothian said in clear Timeout funktioniert nicht mehr:
Ein sauberer Weg auf die Änderung falsch/wahr zu trigger ist ein trigger auf “ist größer als vorher”, (bei falsch: ist kleiner als vorher)
ich bin seit 14 Jahren als Software-Engineer tätig...und die Verwendung von "true > false" würde ich nicht gerade als sauber bezeichnen...bei C++, C# oder Java haut dir das mal schön der Compiler um die Ohren...
-
@paul53 und "... wurde geändert" triggert also nur wenn der Wert sich zu dem vorherigen Wert geändert hat? Also von true auf false und umgekehrt?
-
-
@sub1ne sagte: "... wurde geändert" triggert also nur wenn der Wert sich zu dem vorherigen Wert geändert hat? Also von true auf false und umgekehrt?
Ja.
Diese Bedingungen triggern nur bei Wertänderung:- wurde geändert
- ist kleiner als letztes
- ist größer als letztes
Alle anderen Bedingungen können auch bei Aktualisierung des Zeitstempels ohne Wertänderung triggern.
