KNX Queue läuft voll

[Marha]

Immerhin bin ich schonmal nicht alleine mit dem "Problem" und es wurde bereits von mehreren beobachtet.
Ich habe nun mit entsprechenden Verzögerungen nach Systemstart aber auch mit dem System-KO2 direkt getestet. Nach Ablauf der Verzögerung wird wieder über den Oszillatorbaustein alle 250 ms eine GA beschrieben. Ich konnte beobachten, dass je länger die Verzögerungszeit nach Systemstart ist, umso länger dauert es nach Aktivierung des Oszillators bis die Queue beginnt vollzulaufen. Sobald die Queue beginnt vollzulaufen, wird die Queue nach Deaktivierung des Oszillators nicht mehr geleert. Es bleiben immernoch Telegramme in der Queue hängen, auch nach ca 30 min noch, obwohl die eingestellte Senderate noch lange nicht ausgenutzt wird. Siehe Bilder im Anhang.
gaert könnte da sicherlich Licht ins Dunkel bringen.

jonofe

Alle 250ms auf den KNX zu schreiben find ich schon sehr sportlich.

Wird nur zu Testzwecken benötigt, um eine hohe Buslast zu generieren und das Problem zu provozieren.
Allerdings würde ich mir über eine LED an einem Taster auf diese Weise "irgendetwas" anzeigen lassen können. Natürlich muss das nicht in dieser Geschwindigkeit sein. Für einen eleganteren Vorschlag bin ich natürlich offen.

[Marha]

Ich habe nochmal ein wenig experimentiert. Dabei habe ich herausgefunden, dass das Verhalten beim Start und das nicht mehr Leeren der KNX-Queue unter Umständen mit der maximalen Telegrammrate zu tun hat. Ich habe verschiedene Einstellungen in der edomi.ini ausprobiert (von 10 bis 40 Telegramme/sec). Bei der Einstellung mit 40 Telegrammen/sec kann der OszillatorLBS (250ms) bereits beim Hochfahren von Edomi aktiviert sein, ohne dass die Queue volläuft. Bei einer Einstellung von 20 Telegrammen/sec und "nachträglich" eingeschaltetem Oszillator läuft die KNX-Queue nach einer Weile (> einer Stunde) voll. Meine Schnittstelle zu KNX ist ein Enertex-Router. Vielleicht kann jemand Ähnliches nachstellen und seine Beobachtungen mitteilen. Vielleicht ist ja in der Verarbeitung der KNX-Queue etwas noch nicht ganz sauber, aber vielleicht deutet das auch auf schlecht erstellte Logiken (Schleifen, usw.) hin, vielleicht aber auch auf ein Problem/Unsauberkeit mit der KNX-Installation unter Last.

[phili]

Hallo Markus (Marha),
ich habe in der Küche einen RGB-Streifen, den ich dynamisch ansteuere. Dabei generiere ich alle 3 Sekunden für jede Farbe ein Telegramm (siehe Logik). In der Regel läuft dies unauffällig im Hintergrund ab. Manchmal fällt dann aber auf, dass der Bus über edomi nurnoch verzögert reagiert (1 Minute Latenz und mehr).
Dann ist wie bei dir die Queue leicht gefüllt (hier ca. 40 Telegramme).
Auch bei mir wird die Queue nicht zügig geleert, obwohl die vorgegebene maximale Telegrammrate bei weitem nicht erreicht ist.
Abhilfe schafft nur, die Telegrammrate deutlich zu senken (z.B. einen Telegrammsatz alle 10 Sekunden) oder den Generator ganz auszuschalten.

Besonders ärgerlich ist, dass es Momente zu geben scheint, in denen die Buslast so hoch ist, dass Telegramme in der Queue auflaufen, die dann aber nicht mehr versendet werden können. Warum ist das so?

An der oft beschriebenen internen "Schleife" sollte es nicht liegen. Ich habe mal die Anzahl der vom "MovingColors" Baustein erzeugten Telegramme gezählt. Die passt gut zur eingestellten Zeit von Telegrammgenerator und edomi-Laufzeit

Was können wir gegen dieses Problem tun?

Harware:
Router: Siemens IP-Router N 146/02
DALI-Gateway: ABB DG/S1.1 DALI-Gateway

[phili]

Hallo gaert,

[...] Es bleiben immernoch Telegramme in der Queue hängen, auch nach ca 30 min noch, obwohl die eingestellte Senderate noch lange nicht ausgenutzt wird.
gaert könnte da sicherlich Licht ins Dunkel bringen.

vielleicht magst Du hier nochmal etwas zu sagen. Wie lange beiben Telegramme in der Queue? Wann werden sie endgültig verworfen?

[hartwigm]

Ich kann das Verhalten bestätigen, wobei ich keinen ‚Telegrammgenerator‘ nutze.

Nach der Projektaktivierung liegen bei mir in der knx queue ca. 600 Telegraamme, diese werden dann abgearbeitet und sind in der Regel nach 5min bei 0!

In vielleicht 25% der Fälle bleibt die Queue aber bei 8 Telegramme. Tritt dies auf, dann habe ich keinen Spass mehr, d.h. alles ist ewig verzögert, und die Queue kann dann auch bis zu 1000 hochlaufen.

Abhilfe ist dann nur das Projekt zu stoppen und wieder zu starten.

Super wäre hier eine Möglichkeit den Inhalt der Queue zu sehen, so dass hier das Problem gezielt angegangen werden könnte

[gaert]

Ich fürchte, dass dies mein Fehler war/ist... Ich habe eben mal die entsprechenden Funktionen genauer untersucht und einen Fehler festgestellt: Diverse Zeitstempel werden falsch berechnet, nämlich in Millisekunden anstelle von Mikrosekunden. Dadurch kommt es quasi zu "Rundungsfehlern" bei schnell hintereinander gesendeten Telegrammen und dies verwirrt die Abarbeitung der Queue.

Natürlich habe ich den Fehler korrigiert (im nächsten Update) - nur leider kann ich das nicht richtig testen, da ich das Problem noch nie hatte. Mag aber daran liegen, dass ich recht sparsam/selten irgendwas auf den Bus sende (eher so im Sekundentakt, wenn überhaupt).

Voller Hoffnung sage ich mal "sorry" und behaupte, dass das Problem demnächst behoben ist

[coliflower]

Keine Ahnung woher das kommt aber ich hatte auch zum ersten Mal ein Problemchen ... Nach Neustart war der "Fehler" weg ...

Bildschirmfoto 2018-08-03 um 15.38.13.png

[gaert]

Die Logic-Queue ist ungewöhnlich voll... Schleife?

Was die KNX-Queue betrifft: siehe #51

[coliflower]

Schleife

Nein

[phili]

Super wäre hier eine Möglichkeit den Inhalt der Queue zu sehen, so dass hier das Problem gezielt angegangen werden könnte

Steht in edomiLive.RAMknxWrite
Die "Übersetzung" der gaids zu den zugehörigen KOs liefert edomiLive.RAMko

Welche Bedeutung hat die Spalte "mode" in RAMknxWrite?

[powell]

Ich hatte schon in einem anderen Thread (Archive) geschrieben, mir ist es auch aufgefallen das die Visu teileweise nicht oder sehr verzögert reagiert.
Mir ist hier ebenfalls aufgefallen, dass dies passiert wenn zuviel über den Bus gesendet wird.
Aber dann wird das Problem ja bald gelöst Danke!

Ebenfalls ist bei mir das Logic Queued öfters mal rot, was bei mir die selben Auswirkungen wie zuviel Bus Traffic hat. Dies kommt bei mir von einfachen Logiken die einen Wert in ein Datenarchiv schreiben. Trotz Einstellung von Totzeit von 2-60s.
Sobald ich die Logikseiten, welche ich zum aufzeichnen von Temp, Luftfeuchte, ... verwende deaktiviere ist alles gut und Edomi startet schnell und die Visu reagiert direkt.

Wie zeichnet Ihr Werte z.B. Wirkleistung oder sonstiges auf um dies für ein Diagramm in der Visu zu verwenden?

Gruß
Patrick

[phili]

Mag aber daran liegen, dass ich recht sparsam/selten irgendwas auf den Bus sende (eher so im Sekundentakt, wenn überhaupt).

Da entwickelst DU so ein hammer Produkt und schreibst dann hier in der Art: Meinen Bus nutze ich "eigentlich kaum".

[gaert]

Ich nutze meinen Bus durchaus, aber eben "mit Bedacht" KNX ist ja nicht gerade flott...

Die Queue-Implementierung ist komplexer, als man zunächst glaubt: Der KNX-Prozess ist ja ein asynchroner welcher, aber die zu sendenden Telegramme müssen zeitlich korrekt verarbeitet werden.

Beispiel: Ein Wert soll auf 1 und nach 1 Sekunde auf 0 gesetzt werden (z.B. per Logik). Zwischenzeitlich trudeln noch weitere Telegramme in der Queue ein, z.B. von anderen Logiken. Das Timing (1 Sekunde) soll jedoch so präzise wie möglich eingehalten werden, unter Berücksichtigung der Telegrammrate etc. Also muss der KNX-Prozess beim Verarbeiten der Queue etwas mitdenken und die Queue-Einträge passend priorisieren... Da könnten sich durchaus noch Fehler eingeschlichen haben, die man erst in "Extremsituationen" bemerkt. Natürlich teste ich EDOMI auf alle möglichen Szenarien, aber gerade in solchen asynchronen und event-basierten Applikationen ist dies nicht immer einfach

[jp2008]

Voller Hoffnung sage ich mal "sorry" und behaupte, dass das Problem demnächst behoben ist

Klasse!

Bei mir tritt das Problem auch regelmäßig auf und geht erst nach weiteren Neustarts weg - ich warte jetzt mal (geduldig) auf die 1.60

DANKE für deine unermüdliche Weiterentwicklung

[gaert]

Ich hoffe, dass das Problem dann behoben ist - versprechen kann ich's nicht. Meine Tests verlaufen positiv, aber ich kann natürlich nicht jede Konstellation abbilden.

Wird denn die Queue bei Euch (im Kontext des Problems) dennoch abgearbeitet - nur sehr langsam?