KNX Queue läuft voll

[jonofe]

Hast du den Taster mal resetted? Funktioniert der Taster den Grundsätzlich?
Hast du Linienkoppler zwischen Taster und Edomi IP Interface?
ggf. mal mit der ETS monitoren, ob die Telegramme auf den Bus gesendet werden.
Und vielleicht mal die Logikseite deaktivieren und schauen, ob sich dann etwas ändert.

[DerSeppel]

Die Kommunikation mit dem Taster sieht gut aus und er funktioniert auch genau so wie erwartet. Ich habe ihn trotzdem gestern Abend mal resettet. Das Problem tritt weiterhin auf.
Linenkoppler habe ich keine im Einsatz.
Edomi kann den Router auch pingen.

Cross-Check mit der ETS werde ich heute Abend mal versuchen. Allerdings sieht das, was im Monitor-Log, bzw. im Debug-Log vom KNX-Prozess steht erst mal gut aus. Aber das ist ja nur die Edomi-Sicht.

Hatte das deaktivieren der Seite erst mal verschoben, weil ich gestern spät Abends noch was gefunden habe. Das hat sich aber auch nicht als Ursache herausgestellt.
Hab sie dann eben doch mal deaktiviert und grade im Büro nochmal geprüft: Problem immernoch da. Die Theorie habe kann man vermutlich auch verwerfen. Es fallen auch andere Funktionen aus, die von Edomi aus gesteuert werden.

gaert Kannst du mal kurz erläutern, was es mit dem Initialized auf sich hat? Vielleicht ergibt sich da ja doch ein Ansatzpunkt?
Hast du noch einen Vorschlag zum debuggen?
Hast du eine Erklärung warum die Queue sich trotz durchgehend niedriger Senderate aufbaut?

Ich will Edomi jetzt nicht einfach so neu aufsetzen, wenn man den Fehler vielleicht vorher fangen kann, werde das aber schon mal vorbereiten.

[gaert]

Zum Beispiel sorgen Schleifen dafür, dass die LBS nicht initialisiert werden können - hier eine simple Schleife, meist ist's natürlich komplexer

Bildschirmfoto 2018-04-19 um 08.30.30.png

Kurz gesagt scheitert die Initialisierung immer dann, wenn es "keinen Anfang" einer Logikkette gibt - so wie eben in einer Schleife: Da EDOMI ja eventbasiert arbeitet, weiß die Logikengine nicht, wo die Schleife beginnt und wo sie endet (ist ja keine for-next-Schleife...).

Grundsätzlich ist es zwar nicht schlimm, wenn einige LBS nicht initialisiert werden können (Schleifen sind ja prinzipiell erlaubt). Aber es ist i.d.R. ein guter Hinweis darauf, dass irgendwas ungewolltes im Gange ist...

[DerSeppel]

Danke für die Erklärung. Kann man diese Schleifen irgendwo anzeigen lassen?
Kannst du kurz erklären wie die Queue funktioniert? Wann landet eine Botschaft da drin und wann wird sie wieder "entfernt"?

Älteres Backup behebt das Problem nicht.
ReNice des proc_knx, ... auch nicht.
Mir gehen die Ideen aus ...

[Brick]

Grundsätzlich ist es zwar nicht schlimm, wenn einige LBS nicht initialisiert werden können (Schleifen sind ja prinzipiell erlaubt). Aber es ist i.d.R. ein guter Hinweis darauf, dass irgendwas ungewolltes im Gange ist...

D.h ich sollte hier mal schauen, was bei mir nicht passt ?


Bereich.png

[gaert]

Die Queue funktioniert ganz einfach: Ausgehende Telegramme landen in der Queue, diese wird zyklisch (je nach Telegrammrate) ausgelesen und dabei nach Zeitstempel priorisiert (vereinfacht gesagt), dann wird auf das ACK vom Bus gewartet und der Eintrag gelöscht.

Die Zeitstempel sind wichtig, da z.B. ein Timer-Baustein priorisiert werden muss: Angenommen der Timer ist abgelaufen und sendet z.B. eine 0 auf eine GA. Zuvor sind jedoch 1000 GAs in der Queue gelandet (von irgendeiner anderen Logik o.d.G.). EDOMI sorgt dann dafür, dass die GA des Timers noch vor den anderen GAs gesetzt wird - sonst würde es ja zu sekundenlangen Verzögerungen kommen. Alles vereinfacht ausgedrückt, also bitte nicht festnageln

Stimmt vielleicht mit Deiner Systemuhr etwas nicht? Es kursieren ja noch immer diverse LBSe, die irgendwelche Zeitzoneneinstellungen verbiegen etc...

@Brick: Wie gesagt ist es i.d.R. kein Drama, daher wird's auch gelb dargestellt und nicht rot. Manchmal lässt sich das Nicht-Initialisieren nicht vermeiden - auch wenn ich meine Logiken grundsätzlich so anlege, dass dies nicht passieren kann.

[Brick]

kannst du mir einen Tipp geben woran das jetzt liegen könnte ? also wie geh ich das jetzt an ? es sind ja doch 50 Stk..
Soll ich einen eigenen Thread aufmachen ?

[gaert]

Wenn alles wie erwartet funktioniert würde ich garnix machen Nochmal: Es ist keine Fehler oder so, nur ein Hinweis!

[DerSeppel]

Also alle anderen Funktionen von Edomi gehen, ohne Probleme.
Es ist wirklich nur das raussenden der KNX Botschaften.
Ohne dass die CPU überlastet wäre. Bus ist auch "frei".
Würde bei fehlendem ACK nicht die Botschaft aus der Queue fliegen?

proc_knx ist vermutlich auch verschlüsselt/obfuskiert, oder? Da ist nichts mit rein-debuggen ... :/

[gaert]

Ich sag' mal so: Bei allen anderen Usern scheints ja zu funktionieren... Also wird's entweder an Deiner KNX-Installation liegen oder an irgendeiner Logik o.d.G... Ich würde also an Deiner Stelle mal systematisch alle suspekten Logiken ausknipsen und beobachten.

[DerSeppel]

Alle "neuen" Logiken habe ich ja schon aus. Obwohl die jetzt mehrere Wochen ohne Probleme liefen.

Es ist ja nicht so dass die Queue schnell voll läuft. Im Falle einer Schleife würde ich ja erwarten, dass die Queue quasi bei Überschreiten der maximalen Senderate puffert.
Ich habe leider keinen Zugriff auf die Logs im Moment. Wenn es an der KNX Installation liegt (Reset des MDT Routers werde ich mal versuchen nachher!) dann sollten die GAs ja zumindest im Monitor-Log und/oder im Proc_Knx.log auftauchen?

Oder gibt es Fälle, in denen eine GA in der Queue landet, aber nicht im Monitor-Log als zumindest ein Sende-Versuch?

[gaert]

Aktiviere doch einfach mal sämtliche Logs, also auch das KNX-Debug-Log usw. Vielleicht sind dann Auffälligkeiten vorhanden.

[DerSeppel]

Die Logs sind schon alle an.
Habe das hier gerade gesehen:

Nach Neuaktivierung des Arbeitsprojekts war erst mal wieder eine Weile alles in Ordnung.
Dann ist KNX-Receive plötzlich hoch gegangen. Wenn ich da ins Monitor-Log schaue, dann sehe ich, dass mein sehr mitteilungsfreudiger Stromzähler mal wieder eine Salve Messwerte abgeschossen hat.
Die kommen alle hintereinander innerhalb ca. 1 Sekunde.

Was man dann auf dem Screenshot sieht ist komisch. Im Busmonitor war zu sehen, dass nach dem Paket an Messwerten vom Zähler wieder nur gelegentlich etwas auf dem Bus kam. Edomi hat allerdings weiterhin eine hohe Empfangsrate angezeigt. Auf dem Bus war aber nichts los. Gleichzeitig ist die Queue hoch gesprungen. Die Werte des Zählers gehen auf eine Logik, aber nur zum Wegeschreiben der Werte in eine Datenbank. Da werden keine KNX Telegramme gesendet.

Kann es sein, dass eine zu hohe Telegrammrate den KNX Prozess abschießt? Irgendwann hat sich das wieder "geheilt". RX ist wieder auf einen normalen Wert runter und die Queue ist hoch gesprungen.

edomi.png

[gaert]

Kann es sein, dass eine zu hohe Telegrammrate den KNX Prozess abschießt?

Nein

Was sagen denn die Logs nun? Irgendwie stochern wir im Nebel... Im KNX-Log müsste eigentlich alles zu finden sein, was so auf dem Bus passiert.

[DerSeppel]

So, ich konnte die Logs jetzt mal checken.
Die Elemente in der Queue tauchen weder im Monitor-Log noch im KNX-Log auf.
Auch in der ETS sehe ich kein Telegramm.

Ich nehme an, ein fehlgeschlagener Sendeversuch (ohne ACK) wäre ja im KNX-Log sichtbar, oder?

Erst später irgendwann, wird das Telegramm gesendet und ist dann in ETS, Monitor-Log und KNX-Log sichtbar.