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

[maxpd]

@zahnheinrich said in Szenarien mit Variablen greifen nicht:

@maxpd
Generell fehlen in allen blocklys 'stop timeout'.
Wenn du einen timeout setzt solltest du ihn auch immer stoppen.

Einen Bewegungsmelder würde ich immer auf 'Aktualisierung' prüfen.

Ah cool. Danke. wusste ich nicht.
Timeout stoppen benötigt man doch nur wenn er aufgrund eines Events doch nicht starten soll, oder?
Warum ist Aktualisierung bei BWM besser?

@Homoran said in Szenarien mit Variablen greifen nicht:

@maxpd
ich weiss nicht ob ich verstehe was du da vorhast.
Aber im zweiten Beispiel werden die FALLS alle zum Zeitpunkt x geprüft.
Wenn der Timeout im ersten FALLS abläuft und die Variable geändert wird, bekommt davon der zweite FALLS Block nichts mehr mit, weil er bereits 60 Minuten vorher getriggert wurde

Also im 2. Beispiel:

Wenn sich Garagentor ändert, dann
falls Garagentor offen, schreibe nach 1 Stunde eine Nachricht und schreibe eine Variable.
falls Garagentor zu und Variable geschrieben, schreibe nach 1 Minute eine Nachricht und ändere Variable zurück.

[zahnheinrich]

Ah cool. Danke. wusste ich nicht.
Timeout stoppen benötigt man doch nur wenn er aufgrund eines Events doch nicht starten soll, oder?

Schau mal in die Suche: "Stop timeout", da findest du viele weiterführende infos.

Warum ist Aktualisierung bei BWM besser?

Weil es meist besser funktioniert, einfach ausprobieren.

Gruß Ulrich

[lutzer]

Schau mal hier rein, da hatte ich das selbe Problem mit dem Tor.
Auch wenn es anders beschrieben wurde: Mit dem Timeout verzögert man doch nur die Aktion und der Zustand kann ja in 60 min anders sein. Genau deswegen muss man das in 60 min noch mal prüfen.

https://forum.iobroker.net/topic/27404/meldung-wenn-tor-10-minuten-offen-ist/13

[maxpd]

@zahnheinrich said in Szenarien mit Variablen greifen nicht:

Ah cool. Danke. wusste ich nicht.
Timeout stoppen benötigt man doch nur wenn er aufgrund eines Events doch nicht starten soll, oder?

Schau mal in die Suche: "Stop timeout", da findest du viele weiterführende infos.

Warum ist Aktualisierung bei BWM besser?

Weil es meist besser funktioniert, einfach ausprobieren.

Gruß Ulrich

Also irgendwie komme ich nicht dahinter.

Den Timeout will ich ja gar nicht stoppen? Und zum Beispiel für den Fall nach 60 Minuten eine Nachricht zu schicken funktioniert er ja wunderbar.

Auch Änderung oder Aktualisierung macht keinen Unterschied beim BWM. Der BWM löst auch zur gleichen Zeit ein anderes Event aus.

@lutzer said in Szenarien mit Variablen greifen nicht:

Schau mal hier rein, da hatte ich das selbe Problem mit dem Tor.
Auch wenn es anders beschrieben wurde: Mit dem Timeout verzögert man doch nur die Aktion und der Zustand kann ja in 60 min anders sein. Genau deswegen muss man das in 60 min noch mal prüfen.

https://forum.iobroker.net/topic/27404/meldung-wenn-tor-10-minuten-offen-ist/13

Ich kann nach dem Timeout prüfen ob das Event/die Bedingung noch gültig ist. So ist es ja in der Nachricht nach 60 Minuten Timeout gebaut. Damit er mich nicht benachrichtigt, wenn das Tor in den 60 Minuten schon geschlossen wurde. Funktioniert.

Im anschließenden Fall, mich zu benachrichtigen, wenn das Tor wieder zu ist, ist diese zusätzliche Prüfung obsolet, da wenn diese nicht mehr erfüllt wäre, ich auch keine Nachricht bekommen soll.

[maxpd]

Ich habe es nun mit Stop Timeout probiert. Die Garage meldet dennoch keine Info, dass das Tor geschlossen wurde.

[FredF]

@maxpd Das Stop timeout for das ausführen timeout setzen

[maxpd]

@FredF danke dir. probiere ich aus. aber welcher logik entspringt das? Denn in diese schleife geht er ja nicht mehr, da das Tor zu ist. Also landet er im Sonst Fall. Dort soll er die Nachricht senden.

[Homoran]

@maxpd sagte in Szenarien mit Variablen greifen nicht:

aber welcher logik entspringt das?

Damit noch laufende alte Timeouts gelöscht werden

[FredF]

@maxpd Genau wie @Homoran schrieb.
und nochwas: Die zweite Falls abfrage brauchst du nicht.
also so:

[paul53]

@maxpd sagte:

mit Stop Timeout probiert. Die Garage meldet dennoch keine Info, dass das Tor geschlossen wurde.

Zum Ende der Verzögerungszeit zu stoppen, macht keinen Sinn. Außerdem sollte nur ein Trigger verwendet werden und zwar der, dessen Wert geprüft wird.

[maxpd]

Habe mal versucht alle eure Vorschläge einzubauen. Aber er will immernoch nicht Bescheid geben, wenn das Tor wieder zu ist:

[paul53]

@maxpd sagte:

Habe mal versucht alle eure Vorschläge einzubauen.

Hast Du nicht ! Die Bedingung für stop timeout ist eine andere.

[maxpd]

Du hast Recht! und ich schäme mich :(
Nochmal angepasst. Aber auch damit gehts nicht.

[maxpd]

Ich habe mir jetzt nach jedem Step eine Nachricht senden lassen.

Und bis zur roten Linie kommt das Script, aber obwohl beide Bedingungen für den letzten Step erfüllt sind. is open=falsch und variable = true, geht er in diese Schleife nicht rein.

[paul53]

@maxpd sagte:

Bedingungen für den letzten Step erfüllt sind. is open=falsch

Sicher ? Bau mal als erstes eine Log-Ausgabe ein:

[maxpd]

Jup:

[maxpd]

Es gibt ja immer mehrere Wege zum Ziel, deswegen bin ich bislang auch immer gut ohne Stop Timeout und ähnliches durch gekommen.

Blockly ist da ja sehr kulant.

Aber das hier ist wirklich ein Rätsel. Die Debugausgabe deckt sich exakt mit den Vorgaben der Bedingung und dennoch geht er nicht in die Bedingung rein.

[maxpd]

Problem gelöst.

Das Auslesen der Variable hat so auszusehen: