Monatsrückblick Januar/Februar 2026 ist online!

[ParaChris82]

@xadox Du musst statt Intervall einen TimeOut nutzen. Intervall wiederholt in deinem fall dass der Switch alle 15 Minuten ausgeschaltet wird. Wichtig ist beim TimeOut dass du in stoppst , sonst bauen sich schleifen auf und das System kann in die Knie gehen.
Noch was für das Optische... benutze statt zweimal "Falls" einmal "Falls" und "sonst Falls"

ps. bin auch kein Profi aber bei mir laufen alle kleinen Licht Skripte seit zwei Jahren so.!

[jensven]

so sieht mein blockly aus um da Licht bei Bewegung einzuschalten. Nach 5 Minuten fängt er an die Helligkeit alle 1 Sekunden um 1 zu reduzieren.

Um den Timeout oder den Intervall bei Bewegung erneut zu starten sollte direkt am Anfang ein Stop dieser Befehle gesendet werden.

[paul53]

@xadox sagte:

15 Minuten an bleiben, es sei den es wird erneut eine Bewegung registriert.

Wichtig ist das Stoppen der Ausschaltverzögerung bei erneuter Bewegung. Wert findet man unter "Trigger".

[jensven]

@ParaChris82
statt "falls wert von Objekt ID Raucherzimmer presence" = wahr reicht auch ein
falls "wert" siehe Blockly von paul53

[jensven]

@paul53
wobei @xadox auch beim Trigger direkt statt "wurde geändert" auf "ist wahr" umstellen. So wie mein blockly. Somit spart man sich die erneute abfrage von dem Wert

[paul53]

@jensven sagte :

"wurde geändert" auf "ist wahr" umstellen. So wie mein blockly. Somit spart man sich die erneute abfrage von dem Wert

Der Unterschied liegt im sonst-Zweig: Ausschaltverzögerung, wenn keine Bewegung mehr.

[ParaChris82]

@jensven Vielen Dank :) versuche ich mir auch gerade an zu gewöhnen :)

[jensven]

@paul53
das stimmt. Man kann mit dem Trigger "ist wahr" natürlich keine "sonst falls -> nicht wahr" abfrage schalten.
Aber wenn er bei Bewegung das Licht für 15 einschalten will und dann wieder aus, ist dies ja mit nem Timeout zu realisieren.

Sollte dabei der Bewegungsmelder umschalten auf "false" passiert da ja nix. Sollte aber innerhalb der 15 Minuten eine erneute Bewegung erkannt werden, Triggert ja der "ist wahr" fall wieder und die 15 Minuten starten von vorne

[ParaChris82]

@paul53 Macht es bei so "kleinen" Skripten einen unterschied außer dass man eben mehr zusammen klicken muss bei Blockly? CPU und RAM sollten ja kaum in Anspruch genommen werden egal bei welcher weiße.
Wie ist deine Erfahrung? :)

[paul53]

@ParaChris82 sagte:

Macht es bei so "kleinen" Skripten einen unterschied außer dass man eben mehr zusammen klicken muss bei Blockly?

Der Unterschied im Ressourcen-Verbrauch ist minimal bzw. bei einem stark optimierenden Compiler nicht vorhanden. Ich würde allerdings nicht auf die Idee kommen, einen booleschen Wert, der nur false oder true liefert, auf true zu prüfen.

[ParaChris82]

@paul53 Vielen Dank für das Feedback. Und ja, genau so einen Fall hatte ich vor einer Woche mal probiert, Katastrophe !

[jensven]

@paul53
Weil ?
Ich will hier jetzt kein Konflikt oder ähnliches starten.
Ich bin auch erst seit ungefähr einem Jahr hier dabei, somit immer noch am lernen was blockly angeht ;)

[paul53]

@jensven sagte:

Weil ?

?? Was: Weil ?

[xadox]

Vielen Dank für die ganzen Tipps. So langsam wird es klarer. Aber ich muss erstmal verstehen was ihr da geschrieben habt.
Momentan habe ich es nun so:

Allerdings geht das Licht nicht mehr aus.

[jensven]

@paul53 said
Ich würde allerdings nicht auf die Idee kommen, einen booleschen Wert, der nur false oder true liefert, auf true zu prüfen.

Weil ?

[ParaChris82]

@xadox Wie lange hast du gewartet? Der Sensor muss zuerst False melden , das kann bei manchen Sensoren schon etwas dauern. Dauer nicht wundern wenn statt 30 Sek mal 60 Sek werden. Teste es doch mal mit einem kleineren Wert. Geh komplett aus den Raum und warte

[paul53]

@jensven sagte:

Weil ?

Weil das Ergebnis eines jeden Vergleiches true oder false ist. Das liefert der boolesche Wert bereits.

[xadox]

Würde sowas ebenfalls funktionieren:

Falls Schalter auf True prüfe ob Bewegung vorhanden ist und schalte Schalter off falls nicht.

[Asgothian]

@xadox

Nein.

Dieser Teil wird NIE so funktionieren wie du das erwartest.

Innerhalb eines Bausteins aus dem "Trigger" Bereich ist generell KEIN weiterer "Falls Objekt" Baustein aus dem Trigger Bereich sinnvoll.

Du kannst statt dessen einfach einen weiteren "falls" Baustein aus dem Logik Bereich nehmen, und darin den Baustein "wert von Objekt" aus dem System Bereich abfragen.

A.

[xadox]

@Asgothian Also eher so: