Fälschlicherweise mehrfache Ausgabe einer Meldung verhindern
-
@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.
-
@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 = truewenn 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 -
@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.
-
@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.
-
@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 Variabletimeoutauftaucht. -
@paul53 Und das findest Du wirklich logischer als das aktuelle Verhalten?
-
@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
-
@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. -
@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.
-
@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.
-
@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... -
@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... -
@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 aktivHmm, 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?
-
@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!!
-
@haus-automatisierung sagte: Aktuell heißt es, dass kein Timeout läuft.
Das macht beim Entprellen Sinn und war schon immer möglich.
-
@paul53 sagte in Fälschlicherweise mehrfache Ausgabe einer Meldung verhindern:
Einige Blockly-Skripte, die vorher erstellt wurden, funktionieren nicht mehr!!
Ja, das ist richtig. Aber wenn es jetzt zurück geändert wird, funktionieren auch ggf. einige nicht mehr. Wie gesagt, aus meiner Sicht wurde
- damit ein Bug gefixt und
- das Verständnis für Timeouts vereinfacht (weil es ja keine "setze Timeout auf null" Block gibt)
Die Änderung wurde damals in einem PR durch Bluefox freigegeben.
Aktuell ist ein Großteil der Nutzer schon auf einer Version
>= 7.0.5 (2023-06-06). Das heißt, die meisten Nutzer haben schon die neue Logik.
Wenn man das nun zurückschraubt, müsste man konsequenterweise ja
- wieder einen Major-Release mit Breaking Change erstellen,
- die Dokumentation anpassen,
- neue Blöcke erstellen für "setze <timeout> zurück" und
- das alles erklären.
Nur um dann eine kompliziertere Logik mit mehr Erklärungsbedarf zu haben als jetzt. Sorry, aber da bin ich raus.
-
@haus-automatisierung sagte: das Verständnis für Timeouts vereinfacht
Es entspricht aber nicht mehr dem Verhalten von Javascript, die Timer-Variablen betreffend.
@haus-automatisierung sagte in Fälschlicherweise mehrfache Ausgabe einer Meldung verhindern:
neue Blöcke erstellen für "setze <timeout> zurück"
Das halte ich für die bessere Lösung. Es funktionierte ja schon mit dem normalen Variablen-Block - wenn auch etwas trickreich (dummy-Variable, Javascript-Ansicht).
-
@paul53 sagte in Fälschlicherweise mehrfache Ausgabe einer Meldung verhindern:
Das halte ich für die bessere Lösung.
Dann halte ich Dich nicht auf das umzusetzen
Ich werde mir die ganze Arbeit nicht (für ein aus meiner Sicht schlechteres Ergebnis) machen. Aber dafür ist es ja Open Source.@paul53 sagte in Fälschlicherweise mehrfache Ausgabe einer Meldung verhindern:
Es funktionierte ja schon mit dem normalen Variablen-Block
Ja, das ist doch aber komplett unschön und sollte am besten gar nicht so sein. Ich wäre sogar dafür, einen Prefix (wie
t___vor die Timeout-Variablen zu generieren, damit diese nicht mit den manuell angelegten kollidieren. Aber das hätte man schon viel früher machen müssen, damit man gar nicht in die aktuelle Situation reinläuft... Jetzt wäre das wirklich zu extrem, da das leider recht viele nutzen und hier ja öfter verbreitet wurde, statt einfach Blockly-Bausteine dafür zu entwickeln... -
