Monatsrückblick Januar/Februar 2026 ist online!

[paul53]

@invidianer sagte: Meldung kommt mehrmals.

Starte mal die Javascript-Instanz neu.

[invidianer]

@paul53
Das mit dem Historiesieren und Anzeigen über Flot hatte ich schon gemacht, daraus kam ja der Wert 3 zustande.
Da er scheinbar die Fertig-Meldung am Ende alle 180 Minuten bringt, muß es ja wohl mit dem Timeout zu tun haben. Würde ich die Stromzufuhr nicht kappen, würde er vermutlich ewig alle 3 Minuten weitermelden.
Kann man nicht sagen, daß er nur EINMAL melden und dann aufhören soll?

[Homoran]

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

hatte ich schon gemacht

mit welcher Auflösung?

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

daraus kam ja der Wert 3 zustande.

und nie 2.9?

[invidianer]

@paul53
Hatte ich neulich nach einem Update schon gemacht, also alles komplett neugestartet (den ganz RaspberryPi).
War vorher und eben auch heute so.

[invidianer]

@homoran
Das weiß ich nicht mehr genau, war jedenfalls eine Riesenfummelei und will ich mir nicht nochmal antun ehrlich gesagt.
Kann man nicht einfach nach der ersten Meldung einen "break" einbauen?

[paul53]

@invidianer sagte: War vorher und eben auch heute so.

Überprüfe mal die Selektion der Timer-Variablen bei "stop timeout" und bei "nicht Verzögerung timeout". Eigentlich ist es nicht möglich, dass die Meldung ein zweites Mal kommt, bevor der Timer gestoppt wurde.
Schau mal in den erzeugten Javascript-Code, ob sich irgendwo ein Block versteckt hat.

[invidianer]

@paul53
Ah! Ich weiß, was Du meinst!
Bei "timeout_fertig" ist rechts daneben ein Pfeil nach unten, wo man es sozusagen auswählen kann. Aber an einer Stelle ist es nicht da, nämlich bei "Ausführen"! Da habe ich es wohl "per Hand" eingetippt, nicht ausgewählt.
Muß ich das korrigieren? Wie erreiche ich, daß da so ein "Auswahlmenü" kommt?

[paul53]

@invidianer sagte: an einer Stelle ist es nicht da, nämlich bei "Ausführen"!

Dort definiert man den Variablenbezeichner für den Timer.

[invidianer]

@paul53
Achso. Schade, dann ist es so ja wohl richtig :(
Wie meintest Du das mit dem eventuell versteckten Block, den man über Java-Skript sehen kann? Wie mache ich das?

[paul53]

@invidianer sagte: versteckten Block, den man über Java-Skript sehen kann?

Ich habe mal importiert: In Zeile 20 Javascript-Code steht

      timeout_fertig = null;

Der ist falsch und für dieses Verhalten verantwortlich.

[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.