Größe der KNX-GA Queue auslesen

[tobo]

gaert ich habe immer wieder mal Probleme mit der GA-KNX-Queue - irgendwann läuft die voll.

Gibt es einen Weg die Anzahl der Telegramme in der Queue in ein System-KO zu schreiben? Dann könnte ich eingrenzen in welchen Situationen die Queue anfängt vollzulaufen und vielleicht endlich dem Fehler auf die Spur kommen.

EDIT: Und ein System-KO mit Name oder Nummer der zuletzt getriggerten Logikseite wäre ein Traum.

Danke!

[eXec]

Moin,

versuche mal deine Logiken zu deaktivieren und aktiviere diese nach und nach wieder. Bei mir war es eine Schleife die ich gebaut hatte. Ich hatte einen Ausgang ohne sendbychange in einen Eingang geschrieben, was zu ein stetig steigenden Queue führte.

[tobo]

Hi eXec,

danke, aber den Tipp kenne ich, das Spiel habe ich schon diverse Male durch. Nur bringt das nichts, wenn eine Logik erst dann Amok läuft nachdem sie getriggert wurde. Manche Logiken laufen sporadisch, einige nicht jeden Tag. Da dauert die Fehlersuche Wochen.

[tobo]

So, den Fehler habe ich gefunden: ausgelöst von einem Taster (RGB im Büro, sehr selten benutzt) wurde eine Logikschleife gestartet. Meine monatelange Fehlersuche beinhaltete neben dem anfänglichen Deaktivieren aller Logiken eine komplette Neuinstallation des Edomi Servers, das Zurückspielen unterschiedlicher Backups, Installation von knxd und das Testen anderer Hardware. Zwischendurch hatte ich schon mal fast akzeptiert dass ich den Server eben ein oder zweimal die Woche durchstarten muss.

[jonofe]

Normalerweise kann man das doch ganz gut im Monitoring Tab sehen. denn dort sollte dann doch das KNX GA sehr oft auftauchen und über die GA kann man dann durch Dereferenzierung auch die möglichen Logikseiten herausfinden. So habe ich zumindest i.d.R. meine Logikschleifen gefunden.

[tobo]

Du hast vollkommen recht, das geht. Hat mir aber nicht geholfen: Denn dieses Licht (RGB im Büro) mache ich nur hin und wieder abends mal an, wenn ich nichts mehr am Rechner mache. Da fällt es mir dann auch nicht sofort auf dass die Queue voll läuft. Und niemand kann mir erzählen dass er Stunden später oder am nächsten Morgen wenn die Rolläden mal wieder unten geblieben sind und die Familie es leid wird in aller Ruhe die Queue anschaut anstatt die Kiste einfach schnell durchzustarten

Das kann doch jedem passieren, was spricht also dagegen mit System-KOs für die Größe der Queue und der letzten aufgerufenen Logik die Fehlersuche zu vereinfachen?

[Brick]

ging da bei deinem Fehler CPU Leistung oder ähnliches auch nach oben ?? wenn ja hätte ich ne Logik gebaut, die mich per Mail (Telegramm) benachrichtigt
wenn das passiert... dann wär der Zeitpunkt zumindest schon mal deutlich eingeschränkt..

Gruß Martin

[tobo]

Nein, die CPU-Auslastung geht dabei nicht spürbar hoch, dafür hat die Kiste zu viel Luft nach oben. Die Idee an sich ist gut, allerdings habe ich bei aktivierten MQTT LBS eh immer Peaks in der CPU-Auslastung. (Ja, ich weiß, man könnte jetzt eine Logik bauen mit Durchschnitt über Zeit und so... )

Seht ihr denn Nachteile bei meinem Vorschlag? Ich finde es grundsätzlich gut wenn es die Möglichkeit gibt solche Informationen einfach vorzuhalten (ich speise das MONLOG und bei Bedarf auch die anderen Logs in Elasticsearch ein) um bei Bedarf eben auch rückwirkend schauen zu können was da passiert ist.

gaert - was meinst Du, wäre es machbar dass bspw ein KO alle X Sekunden mit der Größe der GA-KNX-Queue zu füttern und eines mit dem Namen oder der Nummer eine Logik wenn sei getriggert wird?

Gruß

[steffen79]

Wäre es für soetwas nicht sinnvoll, wenn Edomi jeden getriggerten LBS in einem speziellen Debug loggen könnte?
Natürlich nur optional, weil der Log auch im normalen Betrieb schnell vollaufen würde....

[tobo]

Letzte Nacht lief wieder die Queue voll. Entweder habe ich noch ein anderes Logikproblem, oder irgendwas stimmt grundsätzlich nicht. Ich habe keine Idee mehr was ich noch unternehmen kann ausser wieder Logiken abzuschalten und tagelang zu warten was passiert. Das ist unendlich frustrierend.

Schade dass gaert sich nicht zu meinem Featurewunsch äussert, ich wüsste gern ob das Warten auf eine kommende Version lohnt.

[gaert]

Mein Vorschlag wäre: Die verdächtige Logik "isolieren" und unabhängig von anderen Logiken testen. Ein Loggen von Logikaktivitäten steht durchaus auf meiner Liste - Dein Wunsch ist mir ein wenig zu speziell...

[tobo]

Hi gaert,

das Problem ist, alle Logiken sind verdächtig, oder keine. Ich habe sie alle schon stundenlang angestarrt, über Wochen hinweg einzeln und in Gruppen deaktiviert - es ist kein Muster erkennbar und ich sehe nicht wo ich weitersuchen kann weil ich immer nur mit Stunden Verzögerung mitbekomme dass es wieder losgeht.

Ehrlich gesagt verstehe ich nicht was an meinem Wunsch speziell ist. Der Wert für die aktuelle Größe der Queue ist doch schon vorhanden (er wird ja schliesslich angezeigt), kann man den nicht einfach z.B. einmal pro Minute in ein (System-) KO schreiben?

Kannst Du mir einen anderen Weg nennen den Zeitpunkt einzugrenzen, vielleicht übersehe ich ja einfach was.

[steffen79]

Tobo, nur als Idee: kann eins deiner geräte die buslast auslesen und auf den knx bus legen? Das wäre doch die von dir gewünschte Funktion oder?
Mein netzteil kann sowas z.B.

[tobo]

Hi Steffen,

die Anzahl der Telegramme auf dem Bus und in Edomi-KO kann ich mittels Elasticsearch nachvollziehen, das befülle ich mit den Daten aus dem MONLOG.

Bildschirmfoto 2017-09-13 um 12.56.41.png

Das gibt mir aber keinen Aufschluss darüber wann die Edomi-interne Queue ansteigt. Das erste sichtbare Peak zwischen 5 und 8 Uhr, da sind wir aufgestanden. Die Queue war da aber schon wieder bei knapp 5000 - in der Nacht vorher ist nicht zu sehen dass die Buslast steigt.

[gaert]

Du kannst Dir einen LBS basteln und die Anzahl in der Queue sodann auslesen:

select s0 from edomiLive.RAMsysProc where id=3

liefert den aktuellen Wert der Spalte "s0" (dort wird die Anzahl abgelegt).