KNX Queue läuft voll

[jp2008]

Ich sag' mal so: Bei allen anderen Usern scheints ja zu funktionieren...

Moin, ich finde leider momentan keine Zeit für eine umfangreiche Analyse.

Aber auch bei mir scheinen seit den letzten Updates uralte und unveränderte Logiken plötzlich für eine erhöhte CPU-Last zu sorgen. Zuletzt war ich statt bei unter 10% bei ca. 20% und seit gestern bin ich bei 40% CPU Last - ohne neue Logiken erstellt zu haben. Die 100% CPU-Last konnte ich gestern nur durch das Einfügen von vielen SBC-Bausteinen auf 40% reduzieren - in Verschattungs-Logiken, welche ich seit letzten Sommer nicht mehr bearbeitet habe (noch nicht einmal die Design-Änderugen sind dort verarbeitet).

Würde mich daher freuen, wenn sich hier eine Lösung findet oder zumindest Lösungsansätze... Wie gesagt, ich kann zeitlich leider aktuell nicht viel beitragen - ich bin aber jetzt wieder auf die komplexe Beschattungslogik angewiesen.

[gaert]

Werfe doch mal einen Blick auf die Changelogs - an der Logikengine habe ich seit einigen Versionen nichts verändert.

[jp2008]

Werfe doch mal einen Blick auf die Changelogs - an der Logikengine habe ich seit einigen Versionen nichts verändert.

Moin Christian,

ich glaube dir gern! Und sehr wahrscheinlich liegt der Fehler bei uns Anwendern, aber den Fehler immer pauschal auf Logikschleifen zu schieben, finde ich nicht zielführend - insbesondere wenn diese offenbar bei mindestens 2 Nutzern nicht neu entstanden sind.

EDOMI bleibt die perfekte Logik-Lösung, die vielleicht noch etwas perfekter wäre, wenn sich "dumme" Anwenderfehler leicht(er) auslesen und analysieren lassen.

Ich würde ja mit meinen gewonnenen Kenntnissen auch einfach nochmal bei 0 anfangen, aber dazu fehlt einfach die Zeit (und das Verständnis bei der Familie, dass gewohnte Automatiken nicht mehr funktionieren). Zudem würde ich auch vorher einen EDOMI Workshop begrüßen - dann machen zumindest mehrere den gleichen Fehler :-) ...

[jonofe]

wenn diese offenbar bei mindestens 2 Nutzern nicht neu entstanden sind

Edomi ist ja bekanntermaßen eine Ereignis gesteuerte Logikengine, d.h. du kannst auch eine Logikschleife bauen, die vielleicht lange Zeit nicht zum tragen kommt, da die enstprechenden Auslöse Ereignisse nicht in einer speziellen Konstellation aufgetreten sind. D.h. auch ältere Logiken können die Ursache für Logikschleifen sein.

Was hat denn die Analyse des Widgets rechts von der Adminseite ergeben. Normalerweise sieht man dort, wenn iKOs in einer Schleife gesendet werden.

Wachsende Archive und regelmäßige Generierung von Diagramme, etc. haben natürlich auch einen steigenden Einfluss auf die CPU Last.

Ohne ein wenig Aufwand in eine Analyse zu stecken, wird es schwierig der Ursache auf die Spur zu kommen.

[jp2008]

Was hat denn die Analyse des Widgets rechts von der Adminseite ergeben.

mittlerweile ist die CPU Last wieder runter auf 20% (ohne Neustarts).

Hier das aktuelle Widgetansicht: edomi1.png

Bis auf die Systemzeit ist dort kein Balken durchgehend voll, aber sind jetzt halt auch nur noch 20% CPU Last... Die Widgetansicht bei 100% CPU Last kann ich gerade nicht generieren.
edomi2.png
edomi3.png

[DerSeppel]

Also in meinem - ursprünglichen Fall - hat die Ansicht keine weiteren Erkenntnisse gebracht.
Es ist auch definitiv keine Schleife. Die Logik ist nur:

Trigger (Minütlich) > Uhrzeit LBS > Ausgangsbox auf GA.
Diese GA wird auch nirgends verwendet. Die Uhrzeit taucht im Widget auf. Aber wie gesagt, nicht auf dem Bus. Erst stark verzögert.

[starwarsfan]

Na dann setz doch mal eine zweite Edomi-Instanz auf und importiere ein Backup. In der ersten Instanz nun diese Logik deaktivieren, in der zweiten Instanz alle anderen Logiken deaktivieren und jetzt beide Instanzen laufen lassen und schauen, bei welcher sich die Queue füllt.

[DerSeppel]

Habe aktuell auf einer Backup-Box eine zweite Instanz laufen.
Da habe ich das Backup eingespielt, ohne irgendwas zu deaktivieren. Dort läuft es ohne Probleme.

Edit: Ist oben vielleich etwas unter gegangen. Aber es betrifft alle Telegramme von Edomi. Nicht nur bestimmte Logiken.

[Marha]

Hallo,

ich habe nun auch mal einige Versuche unternommen, herauszubekommen warum meine KNX-Queue neuerdings vollläuft. Dahinter gestiegen bin ich leider noch nicht. Ich kann aber meine Beobachtungen teilen, vielleicht hilfts weiter.
Zu Testzwecken beschreibe ich mit einem Oszilatorbaustein (LBS16000111) alle 250 ms eine KNX-GA. Wenn ich diesen Oszillator starte, nachdem das Projekt aktiviert wurde und Edomi gestartet ist, funktioniert es problemlos. Die KNX-GA wird alle 250 ms beschrieben und die Queue läuft nicht voll (Testzeitraum ca 30 min).
Wenn der Oszillatorbaustein bereits während der Projektaktivierung /Start von Edomi aktiviert ist, läuft die Queue sofort voll. Selbst ein Deaktivieren des Oszillators in der Liveansicht schafft es nicht, die Queue leer laufen zu lassen. Es befinden sich immernoch (Testzeitraum ebenfalls ca 30 min) Telegramme in der Queue, obwohl aktuell nichts auf den KNX-BUS zu senden ist. Siehe Bild.
Kann jemand damit etwas anfangen bzw. sieht einen Zusammenhang mit einer Logikschleife?

[jonofe]

Alle 250ms auf den KNX zu schreiben find ich schon sehr sportlich. Welche Daten brauchst du denn in dieser Frequenz auf dem KNX Bus?
Ich könnte mir vorstellen, dass es irgendeinen Nebeneffekt mit dem Initscan Prozess gibt und der KNX komplett überlastet wird. Aber das ist nur Spekulation.

Passiert das auch wenn du den Oszillator mit dem System-KO2 (Systemstart) startest?

[saegefisch]

es ist auch meine Wahrnehmung: daemon-LBS (Beispiel mit usleep 1000*1000), die mit 1 sofort starten, scheinen die Queue eine kurze Weile volllaufen zu lassen nach Aktivierung/Neustart. Setzt man erst später den Trigger auf 1, geht der lBS im Grundrauschen unauffällig unter. Habe noch nicht tiefer analysiert (gegenprobe), aber subjektiv teile ich diese Erfahrung.

Nachtrag: Vielleicht müsste man im LBS vor EXEC-Aufruf eine Pause von ein paar Sekunden einbauen, bevor er startet. Aber das am Besten nur, wenn der Aufruf durch Neustart kommt

[jonofe]

Es könnte ja noch sein, dass durch die hohe Last beim Initscan und bei zusätzlichen KNX Telegrammen vom Oszillator, Pakete verlorengehen, bzw. das ACK nicht zurückkommt. Ggf. verzögert EDOMI dann die erneute Aussendung, je öfter dies vorkommt. Somit könnten sich Telegramm in der Queue sammeln, zu denen es kein Ack gibt und welche dann nach einer definierten Wartezeit nochmal gesendet werden. Evtl. kann gaert etwas dazu sagen, wie KNX Telegramme bei fehlendem ACK behandelt werden.

[saegefisch]

Vielleicht wäre eine system-Funktion sinvoll, die das Auslösen beim Neustart einen Moment verzögert und das auch noch per Zufall etwas in 1-2s variiert, damit es sich bei den LBSen etwas verteilt - auch wenn die Verarbeitung von edomi selbst bei Hochlast nix verliert und das variieren nicht unbedingt nötig wäre.

[jonofe]

Man könnte es ggf. so machen:

Screenshot from 2018-05-04 13-06-29.png

[wintermute]

Geht auch damit