Abarbeitungsreihenfolge der Logiken

[Drei92]

Ich habe mich die Tage damit beschäftigt über die Fritzbox die anwesenden Handys auszulesen.
Das hat alles sehr gut geklappt, bis auf die Tatsache das der LBS der der den String zerteilt Einträge nicht löscht.

Sonst programmiere ich SPSen da wird das Programm "von oben nach unten" abgearbeitet in der Reihenfolge in der die einzelnen Bausteine aufgerufen werden.
Daher ist es recht einfach einen wert zu initialisieren und dann neu zu beschreiben. Würde also in etwa so aussehen.

KO AB -> initialisieren
KO CD -> initialisieren

KO AB -> Wert zuweisen (wenn vorhanden)
KO CD -> Wert zuweisen (wenn vorhanden)

KOs im Programm verwenden.

So gehe ich immer mit den richtigen werden ins rennen, ich habe ähnliches jetzt auch bei dem String zerteiler gemacht, allerdings finde ich das etwas umständlich
da ich vorher Auswerte ob sich die Anzahl der Benutzer geändert hat.

[jonofe]

Und was genau ist die Frage?

EDOMI ist Ereignisgesteuert. Ein LBS reagiert auf ein Ereignis an einem Eingang oder zeitgesteuert, führt Aktionen aus und setzt dann ggf. Ausgänge.

[Drei92]

Meine Frage ist welcher Reihenfolge die Bausteine abgearbeitet werden,
Fängt es bei Logikseite 1 an und geht dann nach und nach alle Seiten durch.
Wie ist es auf der Seite, von oben nach unten links nach rechts? nach der Reihenfolge in der die Logikbausteine angelegt wurden?

[Brick]

es gibt da keine Reihenfolge... wenn auf Logikseite 15 was getriggert wird, dann wird das ausgeführt... das kann vor Logikseite 1 sein oder danach..
die Logikseiten sind eigentlich eher dafür da, das ganze zu gliedern um die Übersicht zu behalten...
Das hat nichts mit der "Ausführungsreihenfolge" zu tun...

[Drei92]

Ok, dann werde ich mal schauen und ausprobieren wie ich das übersichtlich hin bekomme.

[starwarsfan]

Hi

Ok, dann werde ich mal schauen und ausprobieren wie ich das übersichtlich hin bekomme.

Na das hat Brick doch schon geschrieben:

die Logikseiten sind eigentlich eher dafür da, das ganze zu gliedern um die Übersicht zu behalten...

[Drei92]

Hi



Na das hat Brick doch schon geschrieben:

Das habe ich schon verstanden, und irgendeine reihenfolge muss es ja geben, wenn ich X Bausteine alle zur selbenzeit trigger, z.B. jede volle Stunde
dann werden die doch nacheinander abgearbeitet, oder klappt das alles gleichzeitig?

Ich bin halt SPSen gewohnt, da ist das alles einfacher weil es eine feste Reihenfolge gibt.


Vielleicht hilft da nochmal ein kleines Beispiel, nehmen wir mal an ich möchte zählen wie viele Fenster offen sind, das wäre dann in meiner Logik (die nicht unbedingt richtig ist) so aussehen.

Trigger jede minute

KO anz_offen -> zu 0 schreiben

Fenster 1 offen?
ja +1 anz_offen

KO anz_offen = 1

Fenster 2 offen?
nein -> nichts machen

KO anz_offen = 1


Fenster 2 offen?
ja -> +1 anz_offen

KO anz_offen = 2

nachdem ich nun meine X Fensterabgefragt habe steht am ende im KO anz_offen wie viele Fenster geöffnet sind.
Diesen Wert, kann ich nun weiter verwenden für was auch immer.

nach einer Minute geht das Spielchen von vorne los, Wert nullen und aufaddieren.
Ohne nullen würde der Wert ja ins "unendliche" laufen.


Kann auch sein das ich ein Problem sehe wo gar keines ist, dann möge mir man das bitte verzeihen.

[OleDeluxe]

In Edomi würdest du nicht zyklisch alle Fenster abfragen, sondern beim Statuswechsel eines Fensters den Zähler entsprechend rauf oder runter setzten.
Zyklisch abfragen würdest du dann bei Bedarf nur diesen einen Zählerwert (ein iKo). Wobei du dir diesen dann auch eher bei einer Wert-Änderung ausgeben lassen würdest als zyklisch jede Minute, je nach dem wo du ihn verarbeitest (bspw. in der Visu).

So zu mindestens mein Verständnis von Eventbasiert.

Gruß, Sven

[Sonnengruesser]

Hallo Drei92
Die Abarbeitung funktioniert wie beschrieben ganz anders als in der SPS. Du wirst hier ein bisschen umdenken müssen.
Wenn eine neue GA Meldung kommt, wird die Logik getriggert und ausgeführt. Der Status bleibt dann so lange gleich, bis wieder ein Trigger kommt.
Du brauchst auch keine periodische Abfrage.

Wenn mehrere "Eingänge" die gleiche GA als trigger verwenden, dann wird es irgend eine Reihenfolge der Abarbeitung geben. Allerdings kannst du dich nicht auf diese Reihenfolge verlassen und z.B. einen Status setzen und "danach" wieder rücksetzen (um einen "Triggerpuls" zu erzeugen). Da musst du Verzögerungen verwenden oder die Logik ändern.

VG

[Drei92]

Vielen dank für eure Antworten, ich werde mich da mal durcharbeiten und ggf. nochmal Rückfragen stellen.

[jonofe]

Ich bin halt SPSen gewohnt, da ist das alles einfacher weil es eine feste Reihenfolge gibt.

Wenn alles einfacher ist, dann würde ich eine SPS verwenden, statt EDOMI.
SPS Verfahrensweisen lassen sich nicht auf EDOMI anwenden. Ist halt ein anderes Konzept. Wenn ein Fenster geöffnet wird, dann wird der LBS getriggert und berechnet die neue Summe. Bei der SPS würdest du im worst-case das offene Fenster erst eine Minute später mitbekommen. Bei EDOMI siehst du es sofort und es werden alle Logiken, die diesen Wert verwenden sofort getriggert.

Bzgl. Reihenfolge, ja die gibt es, aber ist aus Nutzersicht nicht zu beeinflussen. Ich vermute, dass sie durch die ID der LBS vorgegeben ist, welche du nicht verändern kannst, denn die LBS ID wird über alle LBS im Projekt linear hochgezählt. D.h. wenn du in ein LBS irgendwo in einen Logikstrang einfügen willst, dann kannst du es nicht in der Reihenfolge der bestehenden LBS dieses Strangs machen.

Falls du doch noch zur Erkenntnis kommst, dass EDOMI irgendetwas besser kann als eine SPS, solltest du versuchen die Funktionsweise EDOMI zu verstehen.

[Drei92]

Wenn alles einfacher ist, dann würde ich eine SPS verwenden, statt EDOMI.
SPS Verfahrensweisen lassen sich nicht auf EDOMI anwenden. Ist halt ein anderes Konzept. Wenn ein Fenster geöffnet wird, dann wird der LBS getriggert und berechnet die neue Summe. Bei der SPS würdest du im worst-case das offene Fenster erst eine Minute später mitbekommen. Bei EDOMI siehst du es sofort und es werden alle Logiken, die diesen Wert verwenden sofort getriggert.


Falls du doch noch zur Erkenntnis kommst, dass EDOMI irgendetwas besser kann als eine SPS, solltest du versuchen die Funktionsweise EDOMI zu verstehen.

Eine SPS ist dahin gehend einfacher dass die Reihenfolge festgelegt ist, aber ich glaube du willst mich nur ärgern
Für eine Hausautomatisierung ist eine SPS denkbar ungeeignet, darum habe ich mich ja für KNX und EDOMI entschieden, aber warum sollte ich bereits gelerntes nicht versuchen auf ein neues System anzuwenden, sofern es möglich ist.

Und genau weil ich EDOMI verstehen will habe ich ja hier nachgefragt

Das mit dem Minuten Trigger war nur ein Beispiel, eine SPS schafft das schon ein bisschen schneller.

[gaert]

Die Implementierung eines "sequentiellen Ablaufs" wäre viel einfacher gewesen - schließlich ist ein gewöhnliches PHP-Script ein gutes Beispiel hierfür: Zeile für Zeile wird einfach alles abgearbeitet und am Ende steht i.d.R. irgendein Ergebnis zur Ausgabe bereit.

Und genau hier kannst Du bei Bedarf ansetzen: Einfach einen eigenen LBS erstellen, der die gewünschte Funktionalität kapselt. Wenn dieser "Pausen" enthält (z.B. auf irgendwas warten soll), ist es erforderlich einen "EXEC-LBS" zu erstellen, denn dieser wird quasi im Hintergrund ausgeführt und blockiert somit nicht den Rest einer Logik.

[JonDonSponky]

Drei92 :

Um auf dein konkretes Beispiel aus Post #7 einzugehen, ich habe meine Fensterzählung folgendermaßen gelöst und es läuft

Unbenannt.PNG

PS: meine binären Kontakte schicken ca. alle 50sec. eine Statusmeldung auf dem BUS, macht mir momentan jedenfalls keinerlei Probleme.

[woda]

Krass...
Ich addiere nur die Fensterzustände zusammen.
1 + 1 + 0 + ....
Wobei die Fenster 1 bei "offen" senden.
Bei jeder Änderung wird der Additionsbaustein getriggert.