KNX Queue läuft voll

[powell]

Wo genau seh ich denn wie alles abgearbeitet wird?

[phili]

Ich hoffe, dass das Problem dann behoben ist - versprechen kann ich's nicht.

Wenn nicht jetzt, dann später. Es wird mit Sicherheit eine Lösung geben. Das Wissen, dass ein Softwareproblem vorliegt /vorlag, ist auf jeden Fall schon mal gut.

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

Ja, wird sie. Wenn ich keine der "kritischen" Telegramme mehr erzeuge, dann läuft die Queue leer. Ein paar Telegramme bleiben aber anscheinend ewig stehen (z.B. Datum und Zeit an den Bus).
Wenn ich alle Einträge in ramKNXWrite mit meinem Datenbanktool einfach knallhart lösche ist sofort alles wieder gut!

[phili]

Wo genau seh ich denn wie alles abgearbeitet wird?

Ich nutze dazu DBBeaver (https://dbeaver.io/) und lasse die Tabellen im Sekundentakt auslesen.

[powell]

Ich nutze dazu DBBeaver (https://dbeaver.io/) und lasse die Tabellen im Sekundentakt auslesen.

Ah ok, dann muss ich das auchmal probieren.
danke!

[gaert]

Könnte es sein, dass das Problem nur bei Telegramm-Wiederholungen auftritt (auf KNX-Ebene)? Wäre hilfreich, wenn jemand mal das KNX-Logging in der INI aktiviert und so vielleicht das Problem einkreisen könnte. Wie gesagt trat das Problem bei mir noch nie auf, trotz aller Bemühungen...

[hartwigm]

gaert Mache ich am Montag

[phili]

Habe KNX-Logging auch aktiviert, aber obwohl ich nur für die RGB-Beleuchtung nun 8 Telegramme /sek erzeuge ist der Fehler seit 24 Stunden noch nicht aufgetreten.

[gaert]

Ich implementiere das KNX-Gateway momentan quasi komplett neu (strukturell) - da stecken noch einige kleinere Timing-Fehler drin, mit u.U. großer Wirkung... Das nächste Update könnte also spannend werden

[DerSeppel]

Könnte es sein, dass das Problem nur bei Telegramm-Wiederholungen auftritt (auf KNX-Ebene)? Wäre hilfreich, wenn jemand mal das KNX-Logging in der INI aktiviert und so vielleicht das Problem einkreisen könnte. Wie gesagt trat das Problem bei mir noch nie auf, trotz aller Bemühungen...

Hallo Gaert,
kannst du kurz erklären, wie der von dir beschriebene Fehler auftritt, bzw. was der Fehlermechanismus ist?
Ich habe hier ein System, auf dem das Problem auftritt und eins auf dem es nicht passiert. Kann ggf. die Leistung des Systems den Fehler beeinflussen?

[gaert]

Ja, das ist durchaus möglich, dass die Leistung schuld ist - aber dies sollte in 1.60 dann (hoffentlich) kein Problem mehr sein.

[trollmar]

Ich implementiere das KNX-Gateway momentan quasi komplett neu (strukturell) - da stecken noch einige kleinere Timing-Fehler drin, mit u.U. großer Wirkung... Das nächste Update könnte also spannend werden

Fließen da eigentlich auch die MDT Erkenntnisse mit ein ? Du hast immer noch nicht erzählt was dabei rausgekommen ist

[gaert]

Nein, zur Zeit noch nicht - aber indirekt könnte das Problem evtl.(!) dennoch behoben sein. Wir werden sehen...

[powell]

Auch wenn es hier nicht direkt passt möchte ich nochmal auf die Frage mit den Datenarchiven zurück kommen. Wie genau sehen da bei euch Logiken aus, die direkt KNX Werte in ein Datenarchiv für ein Diagramm schreiben.
Diese verursachen bei mir eine lange Wartezeit nach einer Projektaktivierung(Logic Queued ist rot). Totzeit habe ich nicht auf 0.

Wäre für einen Tipp dankbar, da ich damit schon öfters Probleme hatte.

Gruß
Patrick

[phili]

Ich quäle den Bus (nach Update auf 1.60) seit heute Mittag mit 12 Telegrammen/s, die edomi mindestens generiert. Bisher sieht alles gut aus. Queue steht meistens bei Null. Treten Telegrmme in der Queue auf, läuft sie wieder leer.

[gaert]

Hört sich doch schonmal gut an. Die Statusseite gibt den Zustand natürlich nicht in Echtzeit wieder, sondern u.U. einige Sekunden verzögert bzw. zusammengefasst. (dies nur am Rande)