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

[paul53]

@chris-1 sagte: Also viele viele "kurze" Skripts statt wenigen mit allen möglichen Fallunterscheidungen

Callback-Funktionen können sehr umfangreich sein (mit vielen Fallunterscheidungen).

[Chris 1]

@homoran Ich fange an, den Ansatz zu verstehen.

Ich greife einen Trigger ab und verändere daraufhin A

Ich arbeite nun nicht in dem Skript mit A weiter,
sondern erstelle ein seperates Skript welches A als Trigger hat

Seh ich das so richtig?

[Chris 1]

@codierknecht Was ist DP?

[paul53]

@chris-1 sagte: Was ist DP?

Abkürzung für Datenpunkt.

[Chris 1]

@codierknecht said in Zählen eines Zustandes:

Zum Zeitpunkt 3.) hat der Trigger noch nicht gefeuert und der Code darin wurde noch gar nicht ausgeführt.

Das irritiert mich jetzt - ist was für morgen

[Homoran]

@chris-1 sagte in Zählen eines Zustandes:

Seh ich das so richtig?

nein!

Du kannst alles in einem Skript machen.
nur nicht außerhalb des Triggerbausteins.

@Codierknecht hat es korrekt gesagt.
Dein Skript meldet beim Start wegen deines ausgewählten Datenpunktes (DP) im Trigger beim iobroker Controller an, dass es von diesem über jede Änderung dieses DP informiert werden will.
DANN startet dein Trigger alles, was innerhalb des Triggerbausteins an Befehlen steht

[Codierknecht]

@chris-1 sagte in Zählen eines Zustandes:

Also viele viele "kurze" Skripts statt wenigen mit allen möglichen Fallunterscheidungen

Nicht unbedingt (eher gar nicht).
Du musst in Ereignissen denken. Man braucht 'ne Weile, bis man sich daran gewöhnt hat.
Der Dreh- und Angelpunkt ist eigentlich immer, den richtigen Trigger zu definieren. Der legt fest, zu welchem Zeitpunkt das Ganze überhaupt loslegt. Und das ist oft gar nicht so einfach.
Der Rest kommt dann innerhalb ...

[Homoran]

@chris-1 sagte in Zählen eines Zustandes:

Das irritiert mich jetzt

ich glaube das ist aber der Knackpunkt für dein (fehlendes) Verständnis für Javascript

[Chris 1]

@homoran Ich beginne ja gerade das System dahinter zu verstehen :-)

Es ist keine andere Welt,
sondern nur ein anderer Ansatz :-)

[Codierknecht]

@chris-1 sagte in Zählen eines Zustandes:

ist was für morgen

Vielleicht fällt uns bis dahin ja noch ein schöner Vergleich ein, an dem man event-driven-development irgendwie anschaulicher erklären kann :grin:

[Chris 1]

@codierknecht Ich glaube, ich habe dies, zumindest im Ansatz, bereits verstanden - danke :-)

Anstatt in zyklischen Skripten zu denken,
reagiere ich auf einen Trigger A und setze zB X auf false

In einem Andere Skript reagiere ich auf Trigger X und agiere dann abhängig davon, ob auf true oder false gesetzt/geändert/... wurde

[haselchen]

@Codierknecht
@paul53
@Homoran

Fachfrage an die Experten.
Gibt es eine definierte Zeit (1ms….1sek….?) in der die Bedingungen erfüllt sein müssen ?
Beispiel , ein Blockly mit vielen Und / Oder Bedingungen.

[Chris 1]

@haselchen Gemäß oben "gelerntem?" dürfte es keine bestimmte Zeit geben, da (erst) nach Abarbeitung alles unmittelbar ausgeführt wird.

[Codierknecht]

@haselchen sagte in Zählen eines Zustandes:

Gibt es eine definierte Zeit (1ms….1sek….?) in der die Bedingungen erfüllt sein müssen ?
Beispiel , ein Blockly mit vielen Und / Oder Bedingungen.

In meiner Welt (Windows) nicht.
Zumindest gibt es da keine "vorgegebene" Zeit.
Ist natürlich auch ein bisschen abhängig von der Rechenleistung des Systems und ein paar anderen Faktoren, aber solche Vergleiche sind normalerweise in wenigen Mikrosekunden berechnet.
Da musst Du Dich schon extrem anstrengen und wirklich viel ineinander verschachteln, um das überhaupt messen zu können - geschweige denn zu bemerken.
Das "vorgegeben" habe ich bewußt in Anführungszeichen gesetzt: Wenn man's tatsächlich extrem übertreibt, könnten die Berechnungen so lange dauern, dass in der Zwischenzeit das Event schon ein weiteres Mal ausgelöst wird. Aber solche Dinge wie "Datenbankverbindungen innerhalb von Schleifen öffnen/schließen", "Dateien laden" und ähnliche Schweinereien machen wir ja hier eher nicht :-)
Das ist aber alles eher theoretisch zu sehen. In der Praxis tritt der Fall nicht auf (berühmte letzte Worte)

[Metamorph]

@chris-1 sagte

Anstatt in zyklischen Skripten zu denken,
reagiere ich auf einen Trigger A und setze zB X auf false

In einem Andere Skript reagiere ich auf Trigger X und agiere dann abhängig davon, ob auf true oder false gesetzt/geändert/... wurde

Du denkst noch zu aufwändig. Wenn du in Trigger A den Wert von X änderst, kannst du sofort dahinter abhängig von der Änderung weiter machen. Dies muss aber im Trigger und hinter der Variablenänderung geschehen.

Als Beispiel ein Lichtschalter, der bei jedem Drücken die Helligkeit der Lampe um 20% erhöht:

1. Trigger A wartet auf das Drücken des Schalters.
2. Löst der Trigger aus, erhöhst du den Wert von X (Helligkeit) um 20%.
3. Wenn X größer 100%, dann reduziere ihn auf 0%
4. Übertrage den Wert X in die Lampe.

Die Punkte 2-4 sind aufeinanderfolgende Schritte, die aber alle innerhalb des Triggers liegen. Im Prinzip kannst du dutzende Aktionen reinschreiben, die dann alle nacheinander ausgeführt werden, sobald ein Ereignis den Trigger auslöst.

[haselchen]

@codierknecht

Diese Frage schwebt schon Ewigkeiten in meinem Kopf.
Trigger wird ausgelöst und manche andere Bedingungen in dem Blockly werden erst in 3,4 oder 5 Sekunden erfolgen .
Und da ist die Frage wie lange das Blockly wartet bis alles erfüllt ist nachdem der Trigger ausgelöst hat .

[Codierknecht]

@haselchen sagte in Zählen eines Zustandes:

Bedingungen in dem Blockly werden erst in 3,4 oder 5 Sekunden erfolgen

Was sollte so lange dauern?
Doch nicht etwa ein Trigger im Trigger? ;-)

[haselchen]

@codierknecht

Die Auslösung eines BWM zum Beispiel.

[Codierknecht]

@haselchen sagte in Zählen eines Zustandes:

@codierknecht

Die Auslösung eines BWM zum Beispiel.

???? Die Auslösung ist doch in der Regel der Trigger :question:
Und in der Behandlung desselben wird dann noch eine Reihe von Prüfungen durchgeführt, oder?

[Homoran]

@haselchen sagte in Zählen eines Zustandes:

Und da ist die Frage wie lange das Blockly wartet bis alles erfüllt ist nachdem der Trigger ausgelöst hat .

gar nicht.
Da musst du sogar aufpassen dass du ni ht in die asynchron Falle läufst und due Werte in dem Moment wo sie abgefragt werden (im DP) auch schon geschrieben sind.
Deswegen empfiehlt es sich immer mit Variablen zu arbeiten, die direkt nach dem Triggern gestzt werden, i Falle von der "Trigger variable" Wert sogar mit dem Wert arbeitet die zum triggern geführt hat.
Ansonsten werden bei Vergleich mit Wert von ID diese immer genau dann angefordert wenn das Skript an dieser Stelle ankommt.
Letzteres wird nur Millisekunden nach Triggerung sein, aber bis der Wert ankommt dauert etwas länger.