KNX Queue läuft voll

[vento66]

Sehe ich auch so. Nan kann ja auch den Taster ein paar mal hintereinander drücken... das sollte extern abgesichert werden. Ausserder wue oft startet ihr euer Liveprojekt, nach dem alles läuft?

[gaert]

Ich denke (fürchte), dass der einzige richtige Weg in der Tat der ist, dass man JEDEM Telegramm ein Flag mit auf dem Weg in die Queue gibt:
- "sende mich so schnell wie möglich"
- "sende mich zeitlich korrekt"

Abgesehen von der Implementierung meinerseits gibt's dabei allerdings den Mehraufwand für Euch, dass Ihr in den entsprechenden Logiken (ggf. auch Sequenzen, etc.) händisch Änderungen vornehmen müsstet - z.B. beim erwähnten Garagentor-Trigger. Natürlich sprechen wir hier i.d.R. von Millisekunden, aber die können durchaus entscheidend sein bzw. sich potenzieren.

Gut... Dann habe ich ja wieder eine schöne neue Aufgabe..... Einwände?!

[DolcheVita]

aber dann die "zeitlich korrekt" Angabe als optional bzw. so "schnell wie möglich" als default Wert., oder als separate neue Ausgangsbox, die den Inhalt entsprechend indexiert.

edit: was passiert denn bei "zeitlich korrekt" wenn man ein einen heftigen backlog an Telegrammen hat? dann verkommt es doch auch irgendwie zu "so schnell wie möglich"?!

[Winni]

Ob hier schwarz weiß möglich sein wird. Wahrscheinlich ist es immer eine KO Gruppe bei der die zeitliche Reihenfolge wichtig sein könnte.
Was passiert wenn auch der Router puffert? Der wird solche Logiken nicht haben und die Werte möglichst schnell weiterschieben.
Für mich: Ich sehe Nutzen/Aufwand nicht im Verhältnis

[saegefisch]

Abgesehen von der Implementierung meinerseits gibt's dabei allerdings den Mehraufwand für Euch, dass Ihr in den entsprechenden Logiken (ggf. auch Sequenzen, etc.) händisch Änderungen vornehmen müsstet - z.B. beim erwähnten Garagentor-Trigger.

Ich denke, der Default sollte überall "ASAP" sein. Wenn es also irgendwo Optionen gibt (LBS, Sequenzen,...?) dann sollte zeitlich kritisches dort markiert werden können. Damit hätte auch niemand arbeit, solange er solche Anforderungen nicht hat oder außerhalb von edomi löst. Bei den LBS wäre auch denkbar, bei den wenigen sinnvollen statt eines zusätzlichen Paramters einen "Zeitkritisch-Zwilling" anzubieten, den man dann nutzt, wenn man es braucht. Die Markierung im LBS und Sequenz scheint mir hinreichend, ich sehe daneben gerade kein Bedarf, selber ein Telegramm zu markieren; die Wahl des entsprechenden LBS/Sequenz sollte reichen, die zeitliche Abhängigkeit erwächst mE. implizit durch die Wahl dieser Werkzeuge.

Ich stimme Dir zu, dass vermutlich jedes Telegramm intern etwas braucht. Mir scheint es aber auf den ersten Blick ausreichend, wenn es ein Voränger ist und die Wartezeit zu dessen tatsächlichem Sende-Zeitstempel. Beides wird bei den meisten wohl leer bleiben.

[gaert]

Ich wäre auch für eine einfache Lösung zu haben - aber es gibt keine. Entweder die Queue wird einfach so schnell wie möglich abgearbeitet (also immer) oder ich muss den erwähnten Parameter implementieren. Kompromisse wie "nur den InitScan schnell abhaken und dann wie gehabt zeitlich korrekt" mag ich irgendwie nicht...

[gaert]

saegefisch
Vollkommen richtig. Nur wäre ich dann eher für eine generelle Option, anstelle von LBS-Zwillingen. Zumindest auf den ersten Blick.

BTW: Wie macht das eigentlich z.B. der HS?! Würde mich mal interessieren. Oder auch andere Systeme...

[vento66]

Wenn der HS seine QUEUE leert, gibt es Blinklicht im Zimmer. Der feuert einfach alles raus.

[saegefisch]

Zumindest auf den ersten Blick.

tatsächlich finde ich eine Lösung, die implizit festlegt, ob zeitkritisch oder nicht, eigentlich gut und in der Anwendung einfach. Andererseits sind LBS-Zwillinge immer doof, weil doppelter Pflegeaufwand. Es gibt LBS, die sind ohne Zeitbezug nutzlos, daher implizit zeitkritisch. Aber wenn es ein zusätzlicher Eingansparameter ist, der im Default "ASAP, nicht zeitkritisch" sagt; auch fein. Bei den Sequenzen sähe ich ein Flag, dass von default "zeitkritisch" auf "ASAP" umschalten lässt; entweder global für die Sequenz oder je Schritt darin.

Am Anfang steht aber die Frage: Wäre es denn überhaupt nötig (lohnt es den Aufwand oder ist es eher "uff die Liste")? und: Ist es technisch "hinten" überhaupt lösbar? Vorher stellt sich die Frage nach der Kennzeichnung nicht so sehr...

[gaert]

D.h. wenn ich beim HS z.B. ein Verzögerer von 500ms mache, kommt hinten alles denkbare von 0ms bis 2000h raus?! Mh... Kann ich kaum glauben?!

@saegefisch
Möglich ist alles - ist ja "nur" Software Die Frage ist eher (abgesehen vom Aufwand des Implementierens, aber das ist ja meine Sorge), ob sich das nicht irgendwie smarter lösen lässt, als mit einer Zusatzoption. Ich mag' ja im Grunde so überfrachtete Dialoge nicht... DAS ist mein eigentliches "Problem" an der Sache - im Idealfall soll EDOMI selbst wissen, wann's zeitkritisch ist und wann nicht.

Da ist Dein Vorschlag mit Zwillings-LBSen natürlich nicht schlecht, aber das genügt mir noch nicht - dat muss noch besser gehen

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.

[gaert]

Übrigens: Ganz früher haute EDOMI die Queue ebenfalls einfach raus - aus dieser Epoche stammt noch der LBS 16000109 "Impuls/Trigger (präzise)". Bei diesem LBS habe ich das Problem ganz einfach gelöst: Der Timer wartet quasi auf ein Status-KO und läuft erst dann los.

Es geht also auch ganz einfach....

[saegefisch]

vielleicht ist einfach das beste?

* immer ASAP raushauen
* Es gibt ein KO, das gesetzt wird, wenn Queue leer ist (oder von mir aus einen Grenzwert, z.B. "<10" Telegramme unterschreitet,also das Senden neuer Telegramme sehr wahrscheinlich rasch klappen wird)
* Wer zeitkritisches will: Vorgänger eines zeitkritischen Prozesses mit dem LBS 16000109 solange abwarten lassen, bis die Queue sie verarbeiten kann (z.B. Garage öffnen) und dahinter kann man sich per LBS sein Folge-Telegramm zeitversetzt schicken. Damit sollte (fast) immer alles in Butter sein. Risiko: Wenn edomi mal klemmt (beim Init???!), kann man halt mal einen Moment keine Garage aufmachen. So what? Aber wenn sie auf geht, wird (fast) zuverlässig der Folgeimpuls gesendet. Restrisiko, dass in der Zwischenzeit... egal, Leben ist Risiko...
* Alles andere bleibt, wie es ist
* Du hast fast nix zu tun, außer "alles muss raus und tschüß!" und das neue System-KO muss gesetzt werden nach Queue-Status (immer, nicht nur beim Init; wir wollen ja keine Sonderlocken)

...schön einfach, oder?

[Brick]

+1

[trollmar]

Mir würde ein Button an den Ausgangs lbs gefallen der zeitkritisch flaged der Rest asap

[gaert]

Diese "Queue-leer-KO" ist überflüssig, denn die Router-Antwort (tunneling-request L.con) setzt erst das entsprechende KO (welches man gesendet hat) im internen Prozessabbild. Somit weiß man, dass das KO jetzt tatsächlich auf dem Bus gelandet ist.

Dies ist übrigens auch der Grund für die zeitlichen Abweichungen im Monitor-Log:
Wenn ein KO z.B. per Logik um 000 gesetzt wird, erscheint es im Monitor-Log z.B. erst um 023 (fiktive Zeitangabe...). Denn erst jetzt wurde es auf den Bus gesendet und v.a. auch vom Router geacked (L.con).

Ihr seht schon - ist alles im Detail etwas komplizierter