KNX Queue läuft voll

[s01iD]

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

In dem Fall dachte ich auch eher eine Kombination aus beidem. Mit Priorität auf Position 1, aber auf keinen Fall vor erreichen des Timestamps verarbeiten.

Vielleicht ist das aber auch eine Umdrehung zu viel. Ich hätte dafür momentan keinen konkreten Use Case.

[gaert]

So... Der Hilfetext ist hoffentlich einigermaßen verständlich?

• Priorisierung: ermöglich ein bevorzugtes Senden (bzw. Abfragen, also das Absetzten eines Read-Requests) auf den KNX-Bus
  • KNX-GAs werden grundsätzlich in einer Queue zwischengespeichert, die vom KNX-Gateway nach dem FIFO-Prinzip abgearbeitet wird (also streng chronologisch)
  • diese Option ermöglicht es, eine zu sendende KNX-GA (bzw. eine Read-Request-Anforderung) mit höchster Priorität in der Qeueu einzureihen - so kann mit hoher Wahrscheinlichkeit sichergestellt werden, dass das entsprechende Telegramm sehr zeitnah auf den Bus gesendet wird (z.B. bei zeitkritischen Anforderungen wie einem Trigger mit präziser Impulslänge)
  • Hinweis: Je mehr KNX-GAs von dieser Option Gebrauch machen, desto geringer wird u.U. der gewünschte Effekt sein, da diese KNX-GAs in der Queue ggf. miteinander konkurrieren.

Ich teste noch fleissig - dann könnte das Update rausgehen. Oder wir warten noch auf weitere Features? Mir egal

[gaert]

s01iD
Klar, aber das würde genau zu den unerwünschten Effekten der "Queue-Verlangsamung" führen - denn dann müssen alle anderen Telegramme warten, da sonst die zeitliche Integrität nicht mehr gewährleistet ist. Oft hängen die Telegramme von einander ab (z.B. Sequenzen oder komplexe Logiken). Natürlich verhindert dies die reine Priorisierung auch nicht, aber diese sollte man auch nur mit Bedacht einsetzen (ich werde das nutzen müssen, s.o.).

Prinzipiell ist der Bus ja schnell genug, um z.B. einen 500ms-Trigger auch ohne Prio halbwegs korrekt zu verarbeiten. Nur wenn man kurz zuvor eine Szene mit 1000 Lampen anwirft, wird's natürlich eng: Die Queue ist dann zunächst prall gefüllt und der Trigger muss warten - und landet mit 0 und 1 (500ms später) in der Queue. Da macht es dann Sinn, das entsprechende KO mit Prio zu versehen (intern), damit dieses die anderen Telegramme in der Queue "überholt".

[saegefisch]

...hört sich für mich nachvollziehbar, plausibel und gut an und da 'opt-in', stört es den Bestand nicht.
Für mich gesprochen: Mir pressiert's nicht, daher schau' doch mal uff der Liste nach Update-Beifang, sofern Du keinen Termin am Strand oder im Baumarkt hast...

[Brick]

höchster Priorität in der Qeueu einzureihen

des würd ich noch ändern.. der Rest ist aber verständlich...
Da ich das auch nicht brauche, kann es für mich warten.. das sehen einige aber sicher anders.

Gruß Martin

[gaert]

Guter Tippp

In der Tat habe ich gleich noch einen Baumarkt-Termin... Ich hasse streichen... Aber wat mutt...

Achso:
"Opt-In" ist es schon, aber die Queue verhält sich natürlich nun anders als zuvor - dies *kann* durchaus Anpassungsarbeit nach sich ziehen.

[ggt]

"Opt-In" ist es schon, aber die Queue verhält sich natürlich nun anders als zuvor - dies *kann* durchaus Anpassungsarbeit nach sich ziehen.

Könntest du bitte die „Anpassungsarbeiten“ für diejenigen, die diese Probleme nicht haben bzw. das Feature nicht benötigen näher beschreiben.

[gaert]

Werde ich im Changelog ausführlich erläutern.

Im Grunde ergibt sich die Erklärung aber im Kontext dieses Themas hier bereits in aller Ausführlichkeit Kurz gesagt: Wenn Du keine hoch-präzisen Anforderungen an den Zeitpunkt des Sendens eines Telegramms hast, brauchst Du nichts weiter zu tun.

[ggt]

Wenn Du keine hoch-präzisen Anforderungen an den Zeitpunkt des Sendens eines Telegramms hast, brauchst Du nichts weiter zu tun.

Ok

[hartwigm]

ich würde mich über ein kurzfristiges Bugfixing freuen, ansonsten muss ich ein downgrade machen.
Meine eigenen Bugs kann ich sonst nicht mehr fixen, jedesmal 6Std warten bis die Queue bei 0 ankommt ..

[gaert]

Ein Bugfixing ist es ja nicht wirklich, denn das jetzige Verhalten ist kein Bug, sondern so gewollt

Ungeachtet dessen: 6h? Da muss aber noch irgendwas anderes faul sein?!

[gaert]

So, Update ist draussen - viel Erfolg!

[Winni]

Ich hab's gewagt, obwohl ich übermorgen in Urlaub fahre. Kann nur sagen: Wow. Innerhalb von Sekunden ist bei mir jetzt immer die Queue leer, ob's auch negative Seiteneffekte haben wird, werden wir sehen

[gaert]

Glückwunsch Das wird schon passen... Schönen Urlaub!

[hartwigm]

wow!
gaert - vielen Dank!

In der 1.58 ging es 10min bis meine InitQueue bei 0 ankam, die 1.60 brauchte 6 Std.

die 1.61 ist vielleicht für 10sec aktiv und dann bei Null.