Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[invidianer]

@paul53
Hm, okay, danke, aber wie bekomme ich den aus dem Blockly raus? Da sehe ich nirgends eine solche Zuweisung :(

[paul53]

@invidianer sagte: wie bekomme ich den aus dem Blockly raus?

Es ist offenbar eine fehlerhafte Implementation des Timeout-Blocks in neueren Javascript-Adapter-Versionen (ab 29.5.2023).
Workaraound:

[invidianer]

@paul53
Okay, danke, ich habe den "setze timeout_fertig auf wahr" ergänzt.
Krass, dann habe ich quasi einen Fehler aufgedeckt? Dann hatte es ja vielleicht was Gutes ;)

[paul53]

@invidianer sagte: Fehler aufgedeckt? Dann hatte es ja vielleicht was Gutes

Habe Issue auf Github erstellt.

[invidianer]

@paul53
Dankeschön!

[haus-automatisierung]

@invidianer sagte in Fälschlicherweise mehrfache Ausgabe einer Meldung verhindern:

Krass, dann habe ich quasi einen Fehler aufgedeckt?

Definitionssache. setTimeout liefert eine timeout ID zurück. Also eine Referenz auf einen Timeout, mit welcher dieser abgebrochen werden kann (siehe stop (verwendet clearTimeout()). Wenn der Timeout nun durchgelaufen ist, ist diese Timeout ID ja nicht mehr gültig und der Timeout existiert ja nicht mehr. Daher ist es aus meiner Sicht sinnvoll (mache ich überall in der JavaScript-Programmierung mit Timeouts so - und viele andere auch), diesen Wert wieder zurückzusetzen.

Heiß: In der Timeout-Variablen steht nur etwas, wenn ein aktiver (= noch nicht ausgeführter Timeout) existiert, welcher ggf. abgebrochen werden soll. Damit kann man vermeiden, einen Timeout ein zweites Mal zu starten (= nicht <timeout>).

Aus meiner Sicht also alles korrekt.

[paul53]

@haus-automatisierung sagte: Wenn der Timeout nun durchgelaufen ist, ist diese Timeout ID ja nicht mehr gültig

Sie blockiert aber den Neustart des Timers, solange die Leistung unterhalb des Grenzwertes schwankt.

[haus-automatisierung]

@paul53 sagte in Fälschlicherweise mehrfache Ausgabe einer Meldung verhindern:

Sie blockiert aber den Neustart des Timers, solange die Leistung unterhalb des Grenzwertes schwankt.

Dann muss man das in diesem Fall mit einer weiteren Variable sperren. Also z.B. waschvorgangAktiv = true wenn einmal die Leistung über 3 Watt war. Und das dann in dem "sonst falls` mit aufnehmen.

EDIT: Gibts ja schon (Waschmaschine aktiv). Einfach mit UND in den sonst falls aufnehmen

falls nicht <timeout> UND Waschmaschine aktiv

[paul53]

@haus-automatisierung sagte: Dann muss man das in diesem Fall mit einer weiteren Variable sperren.

Aber erst durch die Änderung in Blockly vom 29.05.2023. Damit ist Blockly nicht mehr abwärtskompatibel.

[haus-automatisierung]

@paul53 Ja, und vorher war es ein Bug, dass die Timeouts nicht zurückgesetzt wurden, wenn sie gelaufen sind. Warum nicht abwärtskompatibel? Es gab vor 7.x gar keinen Block dafür, um überhaupt auf einen existierenden Timeout zu prüfen. Ja, man konnte eine Variable anlegen die genauso wie der Timeout hieß - das war aber nie so vorgesehen und ein unschöner Workaround.

Aktuell gibt es keinen Block, um einen Timeout zurück auf null zu setzen. Nur mit "stop" - und das ist vom Wording ja etwas komisch, weil der ja gar nicht mehr läuft, wenn man das innerhalb der Callback-Funktion nutzt.

Das ist aufgefallen, als ich den "Variablen-Block" für Timeouts implementiert habe. Also bei genau so einem Fall wie oben. Ich wollte damit prüfen, ob es schon einen laufenden Timeout gibt. Falls nicht -> starten. Das gewünschte Verhalten à la "wurde jemals ein Timeout gestartet?" finde ich nur schwer verständlich.

Ich hatte vorher auch geschaut, ob das "Variable mit dem gleichen Namen wie der Name des Timeouts anlegen"-Workaround irgendwo in der Dokumentation auftaucht. War nicht der Fall.

[paul53]

@haus-automatisierung sagte: Es gab vor 7.x gar keinen Block dafür, um überhaupt auf einen existierenden Timeout zu prüfen.

Das war schon immer möglich - nicht mit einer selbst erstellten Variablen. Es gab nur keinen gesonderten (grünen) Block dafür. Außerdem musste man, wenn man den Timeout gerade erst erstellt hatte, erst in die Javascript-Ansicht und wieder zurück schalten.
Es funktioniert noch genau so, außer dass in der Javascript-Ansicht eine zweite Variable timeout auftaucht.

[haus-automatisierung]

@paul53 Und das findest Du wirklich logischer als das aktuelle Verhalten?

[haus-automatisierung]

@paul53 sagte in Fälschlicherweise mehrfache Ausgabe einer Meldung verhindern:

außer dass in der Javascript-Ansicht eine zweite Variable timeout auftaucht.

Deine Issue-Beschreibungen könnten wirklich etwas ausführlicher sein :)

[paul53]

@haus-automatisierung sagte: logischer als das aktuelle Verhalten?

Durch die Änderung funktionieren einige ältere Blocklys nicht mehr!
Wäre es von Anfang an so gewesen, hätte man sich danach gerichtet.

[haus-automatisierung]

@paul53 sagte in Fälschlicherweise mehrfache Ausgabe einer Meldung verhindern:

Durch die Änderung funktionieren einige ältere Blocklys nicht mehr!

• Es wurde in einem Major-Update geändert (ab 7.x)
• Das Feature um auf eine Timeout-Variable zu prüfen, gab es vorher nicht offiziell und ist z.B. in der Blockly-Dokumentation gar nicht zu finden: https://github.com/ioBroker/ioBroker.javascript/blob/master/docs/en/blockly.md
• Wenn es jetzt zurückgeändert wird, wäre es für viele auch ein Breaking-Change, welche den neu erstellten Block für die Prüfung verwenden

Ich werde hier also nichts anfassen. Man könnte darüber sprechen, dass es keine angepassten Release-Notes für 7.x mit einem Hinweis gab. Im Changelog steht ja, dass die Timeouts zurückgesetzt werden.

[paul53]

@haus-automatisierung sagte: Breaking-Change, welche den neu erstellten Block für die Prüfung verwenden

Den betrifft es nicht, sondern nur "Ausführen timeout". Ich würde eher noch um einen (grünen) Block "setze timeout auf null" ergänzen.

[haus-automatisierung]

@paul53 sagte in Fälschlicherweise mehrfache Ausgabe einer Meldung verhindern:

Den betrifft es nicht, sondern nur "Ausführen timeout".

Natürlich betrifft es den. Wird der Timeout nicht zurückgesetzt, ist das eine ganz andere Logik als jetzt:

Aktuell heißt es, dass kein Timeout läuft. Entferne ich das zurücksetzen auf null, heißt das "es wurde irgendwann mal ein Timeout mit dem Namen gestartet, aber keine Ahnung ob da noch was läuft oder nicht".

falls nicht <timeout>
   starteTimeout...

[paul53]

@haus-automatisierung sagte: Entferne ich das zurücksetzen auf null, heißt das "es wurde irgendwann mal ein Timeout mit dem Namen gestartet, aber keine Ahnung ob da noch was läuft oder nicht".

Richtig. So wie in Javascript, wo man selbst für das Rücksetzen auf null sorgen muss.

falls nicht <timeout> // timeout wurde noch nicht auf null zurück gesetzt
   starteTimeout...

[invidianer]

@haus-automatisierung sagte in Fälschlicherweise mehrfache Ausgabe einer Meldung verhindern:
…

EDIT: Gibts ja schon (Waschmaschine aktiv). Einfach mit UND in den sonst falls aufnehmen

falls nicht <timeout> UND Waschmaschine aktiv

Hmm, dann ist es also im Endeffekt (technisch) egal, ob ich „setze timeout_fertig auf wahr" ergänze, wie zuerst vorgeschlagen, oder die Methode hier verwende? Also nur „stilistisch“ anders?

[paul53]

@haus-automatisierung sagte: Im Changelog steht ja, dass die Timeouts zurückgesetzt werden.

In Version 7.05, aber nicht als Breaking-Change. Einige Blockly-Skripte, die vorher erstellt wurden, funktionieren nicht mehr!!