Ankündigung

Einklappen
Keine Ankündigung bisher.

Serialisieren von Schreibzugriffen in Datenarchive

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    Serialisieren von Schreibzugriffen in Datenarchive

    Hallo zusammen,

    wie ist die Ausführungsreihenfolge der Operationen einer Logik? Von links nach rechts, von oben nach unten, vom ersten LBS-Ausgang zum letzten LBS-Ausgang, etc.?

    Hintergrund: ich möchte Werte von verschiedenen LBS-Ketten nach einem einzelnen Trigger in einer bestimmten Reihenfolge in ein Datenarchiv schreiben. Dabei möchte ich keine künstlich erzeugte Taktung (z.B. mit LBS "Triggerfolge" oder "Schaltfolge") verwenden.

    So viel habe ich bereits selbst rausgefunden: Das Setzen der LBS-Ausgänge in einer bestimmten Reihenfolge ändert nicht die Ausführungsreihenfolge. Die Aktionen an den LBS-Ausgängen scheinen immer entsprechend der aufsteigenden Ausgangsnummer getriggert zu werden.

    Viele Grüße
    toggle

    #2
    Dies wurde bereits tiefgehend erläutert - ich weiß aber nicht mehr wo genau...

    Nur soviel: Ereignis-gesteuert (dürfte klar sein). Was die Ausgänge betrifft: Die werden gesetzt, wenn sie gesetzt werden (im LBS) - der entsprechende Funktionsaufruf setzt den Ausgang unmittelbar auf seinen Wert. Im Detail ist's natürlich komplizierter - wie gesagt habe ich das schon irgendwo ausführlich erläutert.
    EDOMI - Intelligente Steuerung und Visualisierung KNX-basierter Elektro-Installationen (http://www.edomi.de)

    Kommentar


      #3
      Ich konnte leider keine passende Antwort finden.

      Wie gesagt, der Wert vom LBS-Ausgang 1 landete bei mir im Datenarchiv immer vor den Werten der Ausgänge 2/3/4 des gleichen LBS unabhängig davon, in welcher Reihenfolge die Ausgänge im LBS gesetzt wurden. Gibt es vielleicht einen Zusammenhang mit der Reihenfolge, in der die Verbindungen zwischen den LBS-Ports gezogen wurden?

      Kommentar


        #4
        Eine fest definierte Reihenfolge gibt es m.E. nicht (weiß ich aus dem Kopf selbst nicht so genau zu sagen). Vom Prinzip her dürfte dies aber auch keine Rolle spielen, denn die Logiken arbeiten wie gesagt Event-getriggert - ein LBS-Ausgang kann ja nicht zeitlich gezielt gesetzt werden, sondern wird "willkürlich" gesetzt sobald der LBS eben seine Berechnungen durchgeführt hat. Dies gilt natürlich für alle Ausgänge eines LBS gleichermaßen.
        EDOMI - Intelligente Steuerung und Visualisierung KNX-basierter Elektro-Installationen (http://www.edomi.de)

        Kommentar


          #5
          Kann es sein dass die Ausgänge 1 bis n nach der Reihe einen Wert erhalten weil diese im LBS (PHP-Code) zeilenmäßig auch meistens 1 bis n „abgearbeitet“ werden ?
          Danke und LG, Dariusz
          GIRA | ENERTEX | MDT | MEANWELL | 24VDC LED | iBEMI | EDOMI | ETS5 | DS214+ | KNX/RS232-GW-ROTEL

          Kommentar


            #6
            Klar, im Prinzip ist das so. Aber da es in Wahrheit garkeine Ausgänge gibt, spielt das effektiv keine Rolle (sobald ein "Ausgang" gesetzt wird, werden intern alle verbundenen Eingänge auf diesen Wert gesetzt).
            EDOMI - Intelligente Steuerung und Visualisierung KNX-basierter Elektro-Installationen (http://www.edomi.de)

            Kommentar


              #7
              Müsste es nicht darum gehen in welcher Reihenfolge die Logikengine die LBS abarbeitet? Da es ja eigentlich keine Ausgänge gibt, wäre interessant, wie nach dem Setzen der Ausgänge der nächste LBS ermittelt wird. Spielt hier die ID ein Rolle? Und wie werden die anderen Aktionen die man einem Ausgangs-LBS definieren kann in die Abarbeitung der Logik Engine eingebunden?

              Kommentar


                #8
                Eine genaue Erläuterung folgt demnächst in der Hilfe

                Prinzipiell: Event-getriggert... Es gibt nicht "die" Reihenfolge.
                EDOMI - Intelligente Steuerung und Visualisierung KNX-basierter Elektro-Installationen (http://www.edomi.de)

                Kommentar


                  #9
                  Ich muss das Thema noch mal "ausgraben". Dass die Vorgänge in EDOMI event-getriggert sind ist mittlerweile bekannt.
                  Wie kann man Vorgänge an verschiedenen LBS-Ausgängen trotzdem synchronisieren?

                  Hintergrund:
                  Ich möchte von einem externen Rechner (smarthome.py mit Network-Plugin) Strings mit Format <name>:<value> per UDP empfangen und den Wert (<value>) den KOs und Datenarchiven entsprechend dem Namen (<name>) zuweisen. Dafür habe ich einen LBS, der UDP-Pakete empfängt, zerlegt und die Pärchen <name> & <value> getrennt auf A2 bzw. A3 ausgibt.
                  PHP-Code:
                            printLog("Message: $reply");
                            
                  setLogicLinkAusgang($id1$reply);

                            
                  $param explode(":"$reply2);
                            
                  setLogicLinkAusgang($id3$param[1]); // value
                            
                  setLogicLinkAusgang($id2$param[0]); // name 
                  Im Trace-Log sehe ich, dass die Strings ankommen und korrekt zerlegt werden. Allerdings ist mir nicht klar, wie ich nun auf den Namen triggern kann, um den dazugehörenden Wert dem KO/DA zu übergeben. Denn der "naive" Ansatz funktioniert wegen der event-orientierten Implementierung nicht. UdpListener.PNG


                  D.h. wenn der Vergleicher glaubt, dass der Name passt, kann nicht gewähleistet werden, dass der dazugehörige Wert am Eingang des ensprechenden LBS-Wertauslöser anliegt. Wie könnte man so etwas richtig umsetzen?

                  Darüber hinaus werden manche Namen nicht immer erkannt (der KO ändert sich minutenlang nicht), obwohl der Name mit verschiedenen Werten im Trace-Log mehrfach zu sehen ist. Läuft irgendeine Event-Queue über, wenn UDP-Pakete im Millisekundentakt (Bursts) ankommen?

                  Gruß
                  toggle

                  Kommentar


                    #10
                    Es gibt keine Event-Queue (EDIT: für EXEC-LBS!). Soll heißen: Wenn ein KO (oder eine Verbindung zw. LBS) "zu schnell hintereinander" geändert wird, werden diese Events verschluckt. "Zu schnell" bedeutet im Normalfall ca. 10ms (abhängig von den Einstellungen in der edomi.ini). Daher muss der UDP-Listener-LBS ggf. queuen, denn dieser arbeitet ja als EXEC-LBS unabhängig(!) von der Logik-Engine und daher vollkommen asynchron.

                    Beim Vergleicher sieht's so aus: Wenn A2/A3 vom UDP-LBS "gleichzeitig" gesetzt werden würden, würde der Vergleicher wie erwartet funktionieren. Aber auch hier gilt wieder: EXEC... Asynchron... Abhilfe ist nur möglich, indem der UDP-LBS komplexer aufgebaut wird: Der EXEC-Teil müsste die UDP-Telegramme verarbeiten und per Variablen (V#...) an den LBS-Teil übermitteln - dort müssten dann die Ausgänge gesetzt werden usw.
                    EDOMI - Intelligente Steuerung und Visualisierung KNX-basierter Elektro-Installationen (http://www.edomi.de)

                    Kommentar

                    Lädt...
                    X