KNX Queue läuft voll

[DerSeppel]

Seit dem ich Edomi vor einer Weile neu aufgesetzt habe, läuft es eigentlich sehr zuverlässig.
Ich musste allerdings vor zwei Tagen den Server neu starten und seit dem läuft mir die KNX Queue voll.

Leider habe ich in der Hilfe keine genaueren Informationen zu der Queue gefunden.
Mein Verständnis ist, dass Edomi darin eigentlich alles Puffern sollte was > eingestellter max. Telegrammrate ist.

Was mich vor allem wundert: An sich kommt Edomi zum Senden an den Bus und Send/s dümpelt zwischen 0 und niedrigen einstelligen Werten herum.

Die Queue läuft nicht stetig steigend voll, sondern der Wert sinkt zwischendurch auch mal.

Wenn ich das Arbeitsprojekt neu starte oder Edomi, dann ist es auch erst mal für ein paar Stunden gut, dann tritt der Fehler aber wieder auf.

Hat jemand eine Idee?

2018-04-18 07_51_50-EDOMI · Administration - MX5 5.1.3.2000 - max5.png

[JonDonSponky]

Woran erkennst du in deinem Screenshot dass die Queue voll läuft?

[eXec]

JonDonSponky Gute Frage!
Forum-Suchfunktion nutzen oder Logicschleife entfernen

[DerSeppel]

Auf dem Bild sehe ich, dass aktuell 26 Nachrichten in der queue sind. Maximal waren es mal 30. Der gleiche Screenshot 2h später zeigt 300.
Logikschleife erschließt sich mir nicht weil:

- Das Problem ohne Änderung am Projekt nach einem Neustart aufgetreten ist.
- Die Queue ja auch gelegentlich wieder kleiner wird

Mich wundert, dass die Queue selbst im 2stelligen Bereich nicht schneller abgearbeitet wird bei irgendwas zwischen 0-5 telegrammen pro Sekunde, i.d.R. eher 0-1.
Eingestellt sind max. 20.

Wenn die Telegramme denn wenigstens schnell rausgehen würden, dann könnte man im GA Monitor ja vermutlich sehen, wo das Problem her kommt.

[MuckiLegden]

Moin,

ich hatte gestern exakt das gleiche Problem: Queue war bei ca. 600, mal knapp drunter, mal drüber, Senderate bei 0-1. Ich hatte vorgestern eine Schleife eingebaut Die betreffende GA wurde aber nur ca. alle 4-5 sek. gesendet...

[Brick]

Bisher waren es in allen "Queue läuft Voll" Threads immer irgendwelche Schleifen...

Hast du evlt. mal was vor Tagen/Wochen geändert und seitdem nicht mehr aktiviert ? evlt. ist das dann erst durchgeschlagen, also du
das jetzt nachgeholt hast...

[gaert]

Die Last wird nicht zwangsläufig gleichmäßig zw. den Prozessen verteilt, d.h. wenn z.B. eine Logikschleife für Auslastung sorgt (auch kurzzeitig in Intervallen) wird für den KNX-Prozess nicht genug CPU-Leistung etc. übrig bleiben und er "lahmt". Die CPU-Last von 32% wäre ja durchaus ein Indikator dafür, dass irgendeine Logik ziemlich aktiv ist

[jonofe]

Ich würde auf dem ersten Widget rechts von der Edomi Admin Startseite mal beobachten welche iKOs dort oft aktualisiert werden. Das könnte einen Hinweis auf die Logikschleife geben.

[DerSeppel]

Eine verspätete Änderung kann ich ausschließen. Habe an der Visu gearbeitet und daher die letzten Tage regelmäßig neu aktiviert..Ohne Änderungen an der Logik.
Habe trotzdem mal heute Mittag die neusten Logiken deaktiviert. Keine Besserung.

32% sollten aber noch Luft haben oder?
Auf der Kiste laufen noch andere Sachen. Die normale Auslastung ist ja auch idR geringer, zumal auch das sich ja nicht geändert hat. War vorher auch schon so.

gaert Kann ich die KNX Queue irgendwo einsehen? Ist die im RAM oder in der DB?
Dann könnte man das Problem vielleicht eingrenzen.

[jonofe]

In deinem Screenshot sieht es übrigens so aus, als wäre EDOMI noch gar nicht komplett gestartet, denn es sind erst 315/330 LBS initialisiert. Bei mir sind diese beiden Werte gleich, wenn das EDOMI Quadrat den grünen Rand hat.

[gaert]

Nein - es werden nicht immer alle LBS initialisiert, aus diversen Gründen.

Die Queue kannst Du einsehen in der DB edomiLive.RAMknxWrite.

[DerSeppel]

Das mit den LBS ist mir auch schon aufgefallen. Habe ich auch vorher so nicht gesehen.
Habe mal in die Queue rein geschaut.
Es handelt sich in der Queue immer um die gleichen zwei GAs:

• Eine ist die aktuelle Uhrzeit, ein Output aus dem LBS16000130.
• Die zweite ist der Präsenzwert eines PMs, der auf eine Ausschaltverzögerung geht. (Zur Steuerung der Hintergrundbeleuchtung eines MDT GT Smart II)
• Ein Ausreißer war dabei: Die aktuelle Außentemperatur als GA.

Beide Logiken sind "uralt" und ewig nicht mehr angefasst worden.
Die Inputs sind jeweils komplett unterschiedlich
Definitiv keine Schleifen.

Einzige Gemeinsamkeit: Alle drei GAs werden von dem o.g. MDT Glastaster "konsumiert"...?

[gaert]

Konsumiert denn der Glastaster auch? Will sagen: Wenn vom Bus kein ACK kommt, wird die entsprechende GA erneut gesendet (und die Queue entsprechend anwachsen). Grob gesagt

Das ist kein "fire and forget", sondern ein bidirektionaler Prozess.

[jonofe]

Hast du evtl. in der ETS in letzten Zeit etwas an den Flags des Tasters geändert?

[DerSeppel]

Nein, ETS war lange nicht im Einsatz.
Der GT konsumiert nicht. Weil er die Chance gar nicht bekommt.
Sieht so aus, als kämen die Botschaften gar nicht erst auf den Bus. Sieht man schön daran, dass die Uhr auf dem Taster nachgeht.
Grade ist noch eine GA in der Queue aufgetaucht, Tag/Nacht Status. Geht ebenfalls an den GT, aber nicht nur an den.
Die GAs haben noch etwas gemeinsam, sehe ich gerade: Alle kommen von der gleichen Logikseite.

Kann das mit dem Initialized Wert zusammenhängen?