Herausfinden, ob ein Timeout in der Pipeline ist

[Asgothian]

@martinp sagte in Herausfinden, ob ein Timeout in der Pipeline ist:

@guitardoc sagte in Herausfinden, ob ein Timeout in der Pipeline ist:

Hallo zusammen,

Gibt es eine Möglichkeit, herauszufinden, ob ein Timeout schon angestoßen wurde? Außer umständlich einen Datenpunkt dafür anzulegen und es selbst mitzuloggen?

Danke schon mal für die Info!

Einen Datenpunkt anlegen muss man nicht, sondern nur eine Variable in dem Blockly-Script, z.B. MyTimeOutStarted
Die setzt man beim Starten des Scripts auf false, und beim Starten des Timeouts auf true. Bei regulärem Ablauf des Timeouts und bei vorzeitigem stoppen muss die Variable aber auf false gesetzt werden ...

Das Design-Pattern, zu vermeiden, dass ein Timeout doppelt gestartet wird, ist es, routinemäßig ein stop des Timeouts auszuführen, bevor man ihn startet...

eine zusätzliche Variable ist eigentlich unnötig. Allerdings sollte man immer den handle des Timeouts behalten. Den braucht man um den Timeout zu stoppen. Und der sollte dann auch im Timeout auf null gesetzt werden. (macht Blockly automatisch).
Dann kann man vor dem Starten des Timeout den Handle verifizieren *if (!handle) handle=setTimeout(...);)

A.

[MartinP]

@asgothian Ist die Frage, ob man das mit reinem Blockly bewerkstelligt bekommt, oder da ein Javascript-Einsprengsel in sein Blockly Script gebraucht wird...

[Asgothian]

@martinp sagte in Herausfinden, ob ein Timeout in der Pipeline ist:

@asgothian Ist die Frage, ob man das mit reinem Blockly bewerkstelligt bekommt, oder da ein Javascript-Einsprengsel in sein Blockly Script gebraucht wird...

wie gesagt - Blockly macht es automatisch - es legt die Variable (timeout, timeout2, ...) an, nutzt diese um den Handle zu speichern, und setzt diesen auf null.

Wenn man in einem Blockly ein JS Skript Anteil nutzt (als Funktion) dann kann man diese Variable auch nutzen.

A.

[MartinP]

@asgothian Okay, also würde es reichen, in Blockly abzufragen, ob timeout == 0?

Leider kann aber in Blockly nicht direkt auf die timeouts zugegriffen werden ... also doch Javascript ... oder

Javascript Funktionscode

return timeout;

Debug Ausgaben

javascript.0	14:02:09.136	info	1 timeout = undefined
javascript.0	14:02:09.136	info	setTimeout(ms=1000)
javascript.0	14:02:09.136	info	3 timeout = 98061448
javascript.0	14:02:09.137	info	setTimeout(ms=2000)
javascript.0	14:02:09.137	info	subscribe: {"pattern":{"change":"ne","q":0},"name":"script.js.Spielwiese.Test"}
javascript.0	14:02:09.137	info	registered 2 subscriptions, 0 schedules, 0 messages, 0 logs and 0 file subscriptions
javascript.0	14:02:10.136	info	2 timeout = null
javascript.0	14:02:11.137	info	4 timeout = null

[JLeg]

@martinp sagte in Herausfinden, ob ein Timeout in der Pipeline ist:

Leider kann aber in Blockly nicht direkt auf die timeouts zugegriffen werden

..würde schon denken, dass das geht:

[MartinP]

@jleg Stimmt, das funktioniert ... Hatte "Verzögerung" für eine Aktion gehalten...

[paul53]

@martinp sagte: Leider kann aber in Blockly nicht direkt auf die timeouts zugegriffen werden

Doch:

[guitardoc]

@paul53 Jepp, das funktioniert. Kurz zum Hintergrund, falls das interessiert:

Bei allen batteriebetriebenen Geräten schaue ich per "IDs vom Selektor", ob sich der Ladestand eines der Geräte geändert hat und wenn einbestimmter Wert unterschritten wird, dann sende ich eine Nachricht per Telegram.
Ich habe unterschiedliche batteriebetriebene Geräte (Shellys, unterschiedliche Geräte im Zigbee-Netzwerk), welche in unterschiedlichen Abständen den Ladezustand aktualisieren. Eines der Zigbee-Geräte (ein Lichtsensor) liefert aus unerklärlichen Gründen immer mal 0%, obwohl die Ladung viel größer ist. Hab schon alles versucht, er sagt zwischendurch immer wieder 0%, und das teilweise über Stunden, bevor er den richtigen Wert wieder liefert.
Ich habe den Timeout auf 6h(!) setzen müssen, damit ich nicht immer eine Nachricht bekomme, dass er auf 0% ist, nur weil sich der Ladezustand eines anderen Gerätes geändert hat und das Blockly ausgelöst wird. In der Liste der Geräte, deren Ladung zu gering ist, steht dann ja jedesmal die 0% drin, auch wenn ich die 0% schon vor Stunden erfasst hab.
Wenn ich nun den Timeout jedesmal vor Ausführung lösche, dann fängt er immer wieder an 6h zu warten, mit dem Ergebnis, dass ich vielleicht gar keine Meldung mehr bekomme, denn eines der Geräte wird sich in der Zeit vermutlich schon mit einem geänderten Ladungszustand melden. Daher die Frage, wie man herausbekommt, ob der Timeout schon läuft.

Hier noch das Blockly zur Veranschaulichung (hoffentlich kann man was erkennen).

[paul53]

@guitardoc sagte: Eines der Zigbee-Geräte (ein Lichtsensor) liefert aus unerklärlichen Gründen immer mal 0%, obwohl die Ladung viel größer ist.

Weshalb nicht nur die Sonderbehandlung per Timer für dieses eine Gerät?

EDIT: Etwa so:

[MartinP]

@guitardoc Hier ist der Timeout eigentlich das zu komplizierte Design Pattern. Timeouts braucht man, wenn das Problem adressiert werden muss, dass eine zu lange Zeit gar nichts passiert.
Hier werden aber regelmäßig Null-Werte gesendet, sodass man zu diesem Zeitpunkten prüfen kann, wie lange es her ist, dass ein "guter" Batteriewert hereingekommen ist.

Auf der anderen Seite kann man mit dem Timeout auch gleich prüfen, ob ein Sensor komplett Funkstille hat, also gar nicht mehr sendet.