Anfängerfrage: Reihenfolge von Skriptausführung
-
@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
-
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.
-
Vielen Dank!!! Für die Antworten und die Geschwindigkeit der Antworten, das hilft mir!
-
@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
-
@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. -
@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.
-
@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
-
@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 erstesetStatein 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 dasgetStatein Zeile 3 noch einen alten Wert liest. -
@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.
-
@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). -
@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 -
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?
-
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:
- Wenn es klingelt öffne die Tür
- Warte bis die Tür sich öffnet und dann tue ...
jetzt drehe die unumstößlichen Befehle rum
Da wäre es doch besser:
- Wenn es klingelt öffne die Tür
- Wenn die Tür sich öffnet tue ....
-
@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:
-
@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.
-
Vielen Dank für Eure Rückmeldungen! Von Stil habe ich keine Ahnung
, aber auf Basis Eurer Infos habe ich jetzt zwei Varianten, die beide funktionieren...
oder
Das ist dann beides ok?
-
@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
-
@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.
-
Ich grabe das hier mal aus, da das Problem das gleiche ist. Die Reihenfolge der Aktionen unter einem Trigger läuft nicht sequenziell ab.
Ich habe einen Berechnungsscript in Blockly gebaut. Hier scheint es zu sein, dass die Berechnungsreihenfolge durcheinander läuft und der Volumetracker dadurch Fehlermeldungen produziert.
0_userdata.0.Benutzervariablen.Strom.Wert_Gespart wurde scheinbar resetet! Reset von 874.13 nach 874.11 passe alle Startwerte anhier ist der Blockly Block.
kann ich irgendwie Blockly dazu zwingen die Berechnungen nacheinander zu machen, oder macht er das eh und der Fehler liegt woanders?
-
@axmlm sagte: kann ich irgendwie Blockly dazu zwingen die Berechnungen nacheinander zu machen
Ja, verwende Variablen für Werte, die später wieder verwendet werden, denn "aktualisiere" wird asynchron ausgeführt, ist also beim Wiedereinlesen noch nicht fertig.
