Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[Wildbill]

@harald-ohne-nummer Es gibt da bei Blockly/Javascript kein von oben nach unten. Alle Trigger laufen quasi gleichzeitig ab. Ebenso wie alle Scripte, die parallel gestartet sind.
Du musst Dir also schon von Anfang an Gedanken machen, was genau wann passieren soll und dann für dieses wann eben den passenden Trigger verwenden. Das kann zeitbasiert sein, eine Reaktion auf einen Melder (Fensterkontakt, Lichtschalter), ein eigens angelegter Datenpunkt, was auch immer.
Du kannst auch 10x den geichen Trigger in 10 verschiedenen Scripten nehmen, die werden dann eben zeitgleich ausgelöst.

Gruss, Jürgen

[Harald-ohne-Nummer]

@thomas-braun So zum Beispiel (hat keinen tieferen Sinn, ist nur Test für mich). Die Blöcke außerhalb der Trigger werden bei Skript-Start einmal durchlaufen, dann nicht mehr. Die Trigger sind aber immer beide aktiv. Ich dachte wegen der graphischen Gestaltung (Puzzle), dass da eine Abfolge wäre.

[Wildbill]

@harald-ohne-nummer Jeder Trigger ist immer aktiv und reagiert, sobald seine Bedingung erfüllt ist, egal wo Du ihn in Blockly hinsetzt oder im Javascript-code hinschreibst. Ebenso wird alles, was außerhalb eines Triggers steht genau einmal bein Starten des Scripts (oder des ganzen JS-Adapters) ausgeführt.

Gruss, Jürgen

[Thomas Braun]

@harald-ohne-nummer

Du könntest den zweiten Triggerblock auch rechts neben den ersten Teil setzen.

Javaskript ist Ereignis-gesteuert, eintretende Ereignisse lösen also immer weiteres aus.

[Harald-ohne-Nummer]

@thomas-braun @Wildbill

Vielen Dank!!! Für die Antworten und die Geschwindigkeit der Antworten, das hilft mir!

[Wildbill]

@harald-ohne-nummer Wie Thomas schon schrieb ist das bei Javascript generell so. Ist also keine iobroker-Eigenheit, sondern gilt generell überall wo Javascript oder Blockly Verwendung findet.

Gruss, Jürgen

[ticaki]

@harald-ohne-nummer
Möchte noch anmerken, das nichts gleichzeitig abläuft, sondern immer nacheinander. Auch wenns so schnell ist, dass es nur für deinen Code/Blöcke einen Unterschied macht.

[paul53]

@harald-ohne-nummer sagte: wenn beide Blöcke den selben Trigger verwenden, werden dann beide gleichzeitig durchlaufen?

Nur "gefühlt" gleichzeitig. Tatsächlich unmittelbar nacheinander, wobei man nicht vorhersagen kann, welcher zuerst.

[Wildbill]

@paul53 @ticaki @Harald-ohne-Nummer Das ist eben wie beim Multitasking auf jedem Rechner. Jeder laufende Prozess schein zeitgleich mit den anderen laufenden Prozessen zu laufen. In Wahrheit laufen da je nach Anzahl der Prozessorkerne nur ein paar parallel und das wechselt immer durch. Da es aber erstens für den User nicht vorhersehbar ist, was als nächstes an die Reihe kommt und das so blitzschnell passiert, dass man es eh nicht mitbekommt, ist es für den User quasi gleichzeitig. Also ja, für Dich ist es beim Erstellen eines Blockly oder direkt Javascripts so, dass alle Trigger zeitgleich ablaufen. Das klitzekleine Nacheinander kannst Du weder beeinflussen, noch bekommst Du es mit.

Gruss, Jürgen

[Codierknecht]

@harald-ohne-nummer
Löse Dich von dem Gedanken einer prozeduralen Abarbeitung!

Jeder Trigger ist ein "Abonnement" auf ein Ereignis. Hast Du zwei Trigger auf das gleiche Event, werden beide auch (mehr oder weniger) gleichzeitig bearbeitet. Dabei ist die Reihenfolge nicht steuerbar.

Wenn Du auf ein bestimmtes Event in einer von Dir gewünschten Reihenfolge reagieren willst, darfst Du auch nur einen einzigen Trigger auf das entsprechende Event setzen.
Und selbst dann ist die Reihenfolge der Abarbeitung nicht in jedem Fall steuerbar, da vieles in ioBroker asynchron abläuft.

Nehmen wir mal ein ganz simples Beispiel:

Das erste setState in Zeile 2 könnte - aus welchen Gründen auch immer - etwas länger dauern.
Du kannst Dich also nicht zu 100% darauf verlassen, dass Zeile 2 bereits ausgeführt wurde, wenn Zeile 3 abgearbeitet wird.
Es könnte also passieren, dass das getState in Zeile 3 noch einen alten Wert liest.

[ticaki]

@codierknecht
mal abgesehen von dem schlechten Stil und dem hohen Ressourcenverbrauch(im Vergleich zu Variablen), wenn man einen Wert schreibt und unmittelbar wieder liest.

Bei 2000 Durchläufen war setState(wertA) == getState(wertA)

setState schreibt das afaik nur in den Cache und getState liest es daraus, oder? Das wirkliche schreiben läuft dann async ab.

offtopic: Womit hast du den screenshot gemacht, der gefällt mir. :)

[Codierknecht]

@ticaki sagte in Anfängerfrage: Reihenfolge von Skriptausführung:

Womit hast du den screenshot gemacht, der gefällt mir

SnagIt von TechSmith.
Ist aber nicht gerade billig (sponsored by company).

[arteck]

@ticaki sagte in Anfängerfrage: Reihenfolge von Skriptausführung:

Bei 2000 Durchläufen war setState(wertA) == getState(wertA)

bei eigen angelegten ja...

bei Geräten nicht.. da wird auf ack gewartet.. da kann schon mal passieren das das Gerät noch nicht das ok gesendet hat und du schon den mit getState abholst...

dafür gibts die

setStateAsync
getStateAsync

[Harald-ohne-Nummer]

Ich muss das Thema nochmal aufmachen. So ganz egal scheint die Anordnungs-Reihenfolge doch nicht zu sein.

Ich habe eine ZigBee-Steckdose. Diese sendet zyklisch irgendwelche Statusmeldungen (z.B. "LinkQuality") über ZigBee. Auf dem KNX-Bus will ich die Info haben, ob die ZigBee Steckdose grds. "da" ist, d.h. aktiv im ZigBee sendet. Das habe ich so gelöst wie unten dargestellt. Das klappt auch. Alle 10 Minuten kommt ein Telegram auf den KNX-Bus. Und wenn binnen der 10 Minuten von der ZigBee-Steckdose ein Signal gesendet wurde, ist das KNX-Telegram "wahr", sonst "falsch".

Wenn ich aber den Trigger und die Endlosschleife in Blocky tausche, wird zyklisch ein "falsch"-Telegram auf den KNX-Bus gesendet. Der Trigger wird nie ausgelöst, es gibt auch keinen Debug-Output.

Wenn in Blockly/Javascript die Anordnungs-Reihenfolge aber egal ist, dürfte das Verhalten doch nicht verschieden sein?

[ticaki]

@Harald-ohne-Nummer

Für Ereignisse und Zeitplan stimmt das alles, aber natürlich wird bei
a= 3+2
a = a * 3
die Reihenfolge eingehalten.

Dein while(1) blockiert alles was danach kommt und ist ganz schlechter Stil. Nimm dafür Zeitplan oder Intervall

Alles was du unter Trigger/Timeout findest läuft asynchron alles andere* synchron.

*Funktionen(Reiter Funktionen) ohne Rückgabe sind asynchron, die mit synchron

Aber natürlich laufen nur Programmfunktionen die aufgerufen werden und wenn du mit while (1) oder ähnlichem die Ausführung stoppst, werden sie nie gestartet.

Einfaches Beispiel:

1. Wenn es klingelt öffne die Tür
2. Warte bis die Tür sich öffnet und dann tue ...

jetzt drehe die unumstößlichen Befehle rum :)

Da wäre es doch besser:

1. Wenn es klingelt öffne die Tür
2. Wenn die Tür sich öffnet tue ....

[paul53]

@ticaki sagte: ist ganz schlechter Stil. Nimm dafür Zeitplan oder Intervall

Auch eine zyklische Abfrage ist kein guter Stil. Besser prüft man, ob mind. alle 10 Minuten getriggert wird:

[ticaki]

@paul53
Als Ersatz ist das guter Stil.

Auf das Problem bezogen würde ich bei Erstellung des Telegramms prüfen, ob einer der Zeitstempel jünger als now() -10 Minuten ist. Hätte ich die Zeit vom letzten Telegram würde ich between prüfen. Mit der jetzigen Version sollte die Erstellung oder Versand des Telegrams den Wert auf false setzen und nicht ein Timer.

[Harald-ohne-Nummer]

Vielen Dank für Eure Rückmeldungen! Von Stil habe ich keine Ahnung :blush: , aber auf Basis Eurer Infos habe ich jetzt zwei Varianten, die beide funktionieren...

oder

Das ist dann beides ok?

[ticaki]

@harald-ohne-nummer
Ich hab damit nur ein Problem die Zeitlinie:

0:00 Telegram nachricht
0:01 Skript check
0:08 Zigbee hat sich seit 10 Minuten nicht gemeldet
0:10 Telegammnachricht
0:01 Skript registriert Zigbee
0:20 Telegrammnachricht 12 Minuten zu spät.

nur zur Info: ein/dein Interval startet das erste mal nach 10 minuten und dann alle 10 Minuten

[Harald-ohne-Nummer]

@ticaki Für meinen Anwendungsfall ist es egal, ob der "Funkausfall" ein paar Minuten früher oder später bemerkt wird. Das ist ein Ereignis, das ohnehin nicht oder nur sehr selten vorkommen sollte und dessen Auswirkungen nicht kritisch sind. D.h. es reicht, wenn ich das dann ggf. ein paar Minuten "zu spät" bemerke.