KNX Queue läuft voll

[gaert]

Wie wäre es damit:

Die Option "raushauen" bzw. "zeitkritisch" könnte ich relativ einfach in die KO-Eigenschaften einbauen, d.h. man legt diesen Parameter in der KO-Konfiguration fest. Dies gilt dann natürlich immer für dieses KO, ist also gewissermaßen ein Kompromiss. Aber da man ja vermutlich "zeitkritisch" nur bei einigen wenigen KOs wie dem berühmten Tor-Trigger benötigt (und dann ja auch immer), wäre das ja relativ komfortabel und sinnvoll!

Oder übersehe ich mal wieder was?!

[saegefisch]

vielleicht habe ich es nicht gut ausgedrückt: EIn System-KO, dass über den Füllgrad der Queue auskunft gibt; entweder als Anzahl/Wert oder/und einfacher, mit einem Grenzwert, ob "hinreichend leer". In einer Logik habe ich ja keine Kenntnis von der Router-Antwort und ist mir 100% und den meisten zu 99% auch egal, wann was raus geht, es soll nur immer "möglichst schnell sein". Aber für die 1%-Fälle...

Damit kann man in Logiken, die wenigen zeitkritischen (d.h. in bestimmten zeitlichen Abständen gewünschten Telegramme) erst dann auf den Weg schicken, wenn die Queue eine rasche Verarbeitung überhaupt erwarten lässt. Bis dahin würden diese Telegramme gar nicht erst in die Queue kommen, da in der Logik gar nicht getriggert. Also im Garagenbeispiel würde bei einer - aus welchem Grund auch immer - vollen Queue (z.B. Init) schon das erste Telegramm gar nicht senden, auf das unbedingt nach 1 sek ein Folgetelegramm folgen muss/soll. Es würde erst gesendet, wenn die Queue hinreichend leer ist, um dann die gesamte Telegrammfolge zeitlich korrekt senden zu können.

Alle anderen KO brauchen das nicht und gehen ASAP raus. Mit diesem Ansatz (zusätzliches System KO und Lösungsansatz über Logik/LBS, wie damals von Dir auch genutzt) kann die gesamte Telgramm-Verarbeitung immer ASAP machen, braucht keine zeitvergleiche oder sonstigen Klimbim und Du braucht dort schlicht nix ändern.

Oder ich stell's mir tatsächlich gerade zu leicht vor...

Nachtrag: Falls Du wirklich etwas ändern willst (Also obiges nicht reicht), dann wäre ein Flag am KO sicher gut aufgehoben. Bleibt aber die Frage der Verarbeitung, wegen des Vorgängers und des Zeit-Deltas zu diesem... Macht man diese Beziehung in der Logik oder in der KO-Definition (KOs zeiltich "klammern")? Ich denke, dass ist kein einfaches Unterfangen im Outbound der Queue-Verarbeitung. Dein damliger Ansatz kam aber ja auch ohne das aus...

Anders gefragt (in die Runde): Wie viele Anwendungsfälle gibt es wirklich, die nicht besser in KNX statt edomi gelöst werden können (Treppenhauslicht-Funktion,...)? Danach kann man eine Aufwand/Nutzen-Abwägung machen... will Dich doch nur schützen, Christian... Aber keinesfalls aufhalten, wenn Du davon überzeugt bist...

[hartwigm]

gaert
Falls jemand an einer schnellen (und unpräzisen) provisorischen Test-Lösung interessiert ist - ich könnte natürlich eine modifizierte proc_knx.php zur Verfügung stellen. Die würde dann die Queue einfach raushauen und keine Rücksicht auf Timestamps nehmen.

Gerne, dann kann ich wenigstens wieder Änderungen machen

[gaert]

Es würde erst gesendet, wenn die Queue hinreichend leer ist...

Das Problem ist nicht ein zu spätes Senden (dies wird aktuell auch nicht verhindert), sondern ein zu frühes Senden des "Folgetelegramms". Beim Garagentor ist ein gewisse Mindest-Triggerzeit erforderlich, damit der Antrieb überhaupt reagiert (zumindest bei meinem).

Momentan versucht EDOMI das zu verhindern, indem die Queue quasi angehalten wird (daher auch die Verzögerungen bei einigen hier).

Ein zu spätes Senden kann nicht sicher verhindert werden (zumindest aktuell nicht), da die Telegrammrate ja begrenzt ist und keinerlei Priorisierung von Telegrammen stattfindet.

Ich stürze mich als einen ersten Schritt mal auf ein "Flag" in der KO-Konfiguration... Man hat ja sonst nix zu tun

@hartwigm
Kann noch ein wenig dauern - ich behalte es im Hinterkopf...

[saegefisch]

...ich nahm eigentlich auch nicht an, dass ein zu spätes Senden ein Problem ist, sondern immer der Abstand zum Folgetelegramm. Daher sollte das erste Telegramm erst gesendet werden, wenn (mit einer hinreichend leeren Queue) davon ausgegangen werden kann, dass das Folgetelegramm in einem verlässlichen/hinreichend genauen (nicht zu kurz oder zu lang) Zeitfenster wird folgen können. Ich verzögere lieber so lange das 1., bis ich vermuten darf, dass das 2./die Folgetelegramme korrekt ausgeliefert werden können (eben vermutlich nicht zu früh, nicht zu spät). Und das wäre m.E. (A = große Lösung) mit Änderungen an den KO (Flag und mehr, Datenmodell,...) und an der Ausgabelogik möglich und ist vermutlich die 5*-Version für die Anwender oder (B = kleine Lösung) Deiner damaligen Logik folgend einfach per Logik und einem neuen System-KO des Queue-Status. Da müsste sich dann jeder selber drum kümmern, wenn er es denn mal braucht.

Ich bin mir selbst nicht ganz sicher, was letztlich wirklich besser ist. Und ich weiß, das wird gut, egal in welche Richtung Du gehst. War nur ein Abwägungshilfe...aber sag' nicht, es hätte keine Alternativen zu einem so großen Umbau gegeben...

Okay, wenn Du die Herausforderung suchst, auf jeden Fall A)...

[gaert]

So ganz kapier' ich's nicht... Aber Hauptsache Du verstehst Dich

Was nützt mir eine Vermutung, dass die Queue möglicherweise leer oder fast leer ist?! Dies kann sich ja jederzeit ändern - auch während der zeitkritische LBS läuft (event-basiert und so). Wenn der LBS also glaubt/weiß, dass die Queue leer ist, kann sie quasi im gleichen Moment rappevoll sein, weil irgendein (EXEC)-LBS im Hintergrund Telegramme raushaut.

Klar, das ginge vermutlich in 1000 von 1001 Fällen gut - und einmal eben nicht. Und dieses eine Mal ist ausgerechnet irgendwas super-wichtiges - kennt man ja

Mein Gedanke ist daher viel simpler (und vermutlich robuster):

Alles wird grundsätzlich so schnell wie möglich rausgehauen. Was ja NICHT bedeutet, dass die Telegramme zeitlich völlig aus dem Ruder laufen, denn die Queue wird ja durchaus zeitlich korrekt befüllt.

Ein Zeitraffer-Effekt wäre also nur dann gegeben, wenn der KNX-Prozess lahmt (Router ist anderweitig beschäftigt, oder was auch immer) oder wenn die Queue schneller gefüllt wird, als die Telegrammrate es abarbeiten kann. Wir reden hier von Millisekunden, nicht von Minuten

Wenn's nun besonders genau sein muss (also keines Falls zu früh gesendet werden darf - Garagentor), gibt man dies dem KO (also der GA) in seinen Einstellungen mit auf den Weg. Wird nun ein Telegramm auf dieses KO gesendet, wird wie gehabt verfahren: Die Queue wird quasi angehalten, bis das KO raus ist. Das bedeutet aber nicht, dass während dessen keine *anderen* Telegramme rausgehen!

Soweit also die Theorie... Jetzt nur noch umsetzen...

[DerSeppel]

Braucht es denn wirklich beide Lösungen direkt in Edomi?
Viele Use-Cases fallen mir nicht ein, in denen es sehr zeitkritisch ist.

M.e. reicht es wenn Edomi immer alles so schnell wie möglich sendet. Den Rest kann man doch in Logik machen. Wenn man da eine Verzögerung von 500ms einbaut, dann muss doch schon einiges im Argen liegen, dass das Telegramm früher kommt. Und wenn eh immer "ASAP" gesendet wird, dann wirds auch auf VMs und irgendwelchen Krücken nicht viel später auf den Bus kommen. Oder verstehe ich eure Anwendungsfälle mit dem Garagentor nicht?

[saegefisch]

okay, wir sind beschlussfähig: So machen wir es...

[Winni]

Tut mir leid, eventuell raff ich's einfach nicht. Was unbedingt erfüllt sein muss ist meiner Meinung nach die Reihenfolge der Werte (z.B. Tor auf, Stop -> sind ja 2 verschiedene KOs). Klar stimmt der Öffnungsgrad nicht, wenn der zeitliche Abstand nicht korrekt war. Das bedeutet aber auch, dass ich Gruppen angeben müsste, die diese zeitlichen Abstände einhalten. Wenn man nun solche Gruppen bildet und zukünftig eine Kleinigkeit übersieht, z.B. Tor auf - Licht an - Tor Stop - Licht aus würde praktisch Licht an und aus schnell durchgereicht, das Stop würde zeitlich korrekt ablaufen. Hm, ob da noch einer durchblicken wird? Definitiv wird sich dadurch die Reihenfolge der Telegramme verändern können, es ist eigentlich keine Queue mehr.
Die zeitlich Korrektheit nur immer für ein KO sicherzustellen bringt in meinen Augen nur in wenigen Fällen was. Was würde den passieren, wenn Signale auf dem Bus zu schnell kommen? Telegrammverlust?
Klar, beim Konzept von gaert , für den Edomi alles steuert kann ich den Ansatz nachvollziehen, ansonsten wird ein Telegramm ausgegeben, sofern der Bus es zulässt und nicht gewartet bis die gewünschte Zeitdifferenz es zulässt.
Ich bin gespannt, was letztendlich dabei rauskommen wird.

[DolcheVita]

Ich werfe noch mal meinen Gedanken in Richtung separate Ausgangsbox, die alles in einen "Zeitkritische QUEUE" mit Vorrang schickt, während alle anderen, also jetzigen, Ausgangsboxen ASAP raushauen.

[s01iD]

Die Thematik, dass FIFO bei Queues zum Teil nicht ausreicht, ist ja keine, die nur Edomi betrifft. Ggf. macht es Sinn, hier einmal über den Tellerrand zu schauen, um zu sehen, was die anderen so machen.
RabbitMQ hat z.B. Konzepte für Priority und Delayed Messages.
Beides für meinen Geschmack Konzepte die hier passen könnten.

Delayed Message: Nachricht darf auf gar keinen Fall vor erreichen des Timestamps konsumiert werden (Verzögerer).

Priority Message: Nachricht überholt einfach alle anderen und wird so schnell wie möglich ausgeführt.

Das könnte man dann z.B. über einen LBS steuern.

[gaert]

Inzwischen habe ich eine einfache Lösung (fast) fertiggestellt:

Die Queue wird stumpf alles raushauen, ganze ohne Timing. Aber man kann einzelne KOs bei Bedarf mit Priorität versehen, d.h. diese KOs werden dann einfach an den Anfang der Queue gestellt (wie s01iD schon vorschlug - sehe ich allerdings erst jetzt).

Der Effekt ist denkbar einfach:
Im Normalfall wird die Queue einfach schnellstmöglich abgearbeitet. Wenn z.B. ein Oszi 1000 Telegramme in die Queue schiebt, werden diese (natürlich in korrekter Reihenfolge) rausgehauen. Wird nun während dessen ein Prio-KO gesetzt, wandert dies an den Anfang der Queue und wird sofort gesendet, anschließend geht's wieder mit den Oszi-KOs weiter.

Natürlich muss man ggf. ein wenig aufpassen, falls die Reihenfolge wichtig ist (Race-Conditions). Dann darf das entsprechende KO natürlich nicht priorisiert werden.

[gaert]

@s01iD "Delayed Message" ist hier leider kontraproduktiv - dies ist quasi die aktuelle Zustand und sorgt ja gerade für Probleme. Aber Prio gefällt

[saegefisch]

prima, das hört sich doch gut UND recht einfach an. Und nachvollziehbar; zwischendurch hatte ich echt Sorge, dass das viel Gedöns für wenige Anwendungen gibt und edomi nicht durchssichtger gemacht hätte. Aber so hört sich simpel an und betrifft die meisten meistens nicht.

...muss aber trotzdem noch mal die Fangfrage stellen (weil ich's verstehen mag): Warum verwendest Du für Dein Tor keinen Aktor mit Treppenhaus-Funktion? Dann sendest Du nur ein Telegramm und der Aktor kümmert sich um "1 sekunde ON, dann wieder OFF".

[gaert]

Wollen wir's hoffen...

Ganz einfach: Mein Aktor (UK/S 32) kann's nicht, bzw. für andere Anwendungen nicht flexibel genug. Meine Haustür wird mit einem Eigenbau Motorzylinder per Arduino geöffnet - und weil ich so sparsam bin habe ich das Sketch so programmiert, dass es an einem Eingang kurz/lang erwartet (für auf/zu). Somit brauche ich nur 1 Aktorkanal.

Aber ich werde das ohnehin mal renovieren bei Gelegenheit - leider funktioniert das Schloss seit 5(?) Jahren problemlos. Hätte ich nicht erwartet... Blöd..