KNX Queue läuft voll

[phili]

Anbei auch mal zwei meiner KNX-Logs. Das erste Log dokumentiert den gesamten Startprozess nach Aktivierung meines Arbeitsprozesses. Im Arbeitsprozess werden weiterhin mit einem Telegrammgenerator 4 Telegramme erzeugt und diese 4 Lichtkanälen zugewiesen. Edomi schreibt somit (mindestens) 16 Telegramme pro Sekunde auf den Bus. Dann beginnt die Queue vollzulaufen. Ich sehe allerdings im KNX-Log nicht den korrespondieren Zeitpunkt.

Schaltet man die Telegramme ab, so läuft die Queue weiterhin wieder leer (allerdings nicht mit der Geschwindigkeit, die edomi in der Startphase mit 20 TPS zeigt).

Das zweite Log zeigt der Verhalten am KNX, nachdem ich bei einer leeren Queue den genannten Telegrammgenerator (250ms) eingeschaltet habe. Telegramme häufen sich dann auch schnell in der Queue.
Was mir evtl. auffiel. Kurz bevor die Telegramme in der Queue auflaufen ist die CPU-Last auf 100%. Anschließend fällt sie ab. Die Send-Rate ist dann aber auch deutlich geringer.

Doof!
Achso: Die in der Queue auflaufenden Lichttelegramme haben die GAs 2/7/34 bis 2/7/37

[DerSeppel]

@gaert:
Wäre es eine Option, mal eine Edomi-Version mit zusätzlichen Debug-Ausgaben zu bauen? Die könnten dann zumindest mal die User laufen lassen, bei denen das Problem zuverlässig reproduzierbar ist. Die Logs bekommst du dann zur Analyse.

Die Queue wird ja scheinbar immer genutzt. Also alles geht in die Queue und der KNX-Prozess holt die Daten da ab.

Vielleicht kann man mal jeden Zyklus des Prozesses loggen, Zeitstempel, wieviele Telegramme der Prozess in der DB sieht, welche er sich zum Senden holt, welche ggf. nicht, etc.
Damit würde man sehen ob der Prozess vielleicht nicht oft genug dran kommt, oder intern aus irgendwelchen Gründen zum Schluss kommt er darf nicht senden (Telegrammbegrenzung, etc.).

[Marha]

Ich habe den Enertex -Router im Einsatz und recht wenig Probleme mit der Queue. Seit Sonntag läuft die Edomi-Version 1.60. Bisher sind keine Probleme aufgetreten. Um die 1.60 etwas zu testen, habe ich die Netzwerkverbindung zum KNX-Router getrennt. Die Queue läuft voll. Nachdem die Verbindung wieder hergestellt war, läuft die Queue sehr schnell leer ( von einem dreistelligen in einen einstelligen Bereich). So weit, so gut. Allerdings verbleiben ca 6 Telegramme in der Queue „hängen“ und die bereits erwähnten Verzögerungen am KNX-Bus treten auf. Habe das Ganze über Nacht laufen lassen. Selbst heute morgen ist die Queue noch nicht leer gelaufen. Es sind noch immer ca 6 Telegamme vorhanden. Nur ein Neustart hat Abhilfe geschaffen. Leider habe ich keine Logs dazu. Vielleicht hilfts ja trotzdem bei der Fehlersuche.

[gaert]

@Marha
Im Prinzip hilft mir das leider nicht weiter... Interessant wäre der Inhalt der Datenbank edomiLive.RAMknxWrite zum Zeitpunkt des Problems (also die 6 Telegramme) und natürlich das KNX-Log.

Wenn mir also jemand einen solchen Dump (einfach Copy&Paste oder so mit entsprechenden Tools) geben könnte...

[gaert]

Seid Ihr Euch eigentlich ganz sicher, dass Ihr nicht irgendeinen LBS nutzt, der z.B. an der Zeitzone manipuliert? Es gab in der Vergangenheit ein paar Kandidaten, die diverse PHP-Einstellungen verbogen haben - das mag EDOMI gar nicht! Wenn nämlich das PHP-Timing aus dem Ruder läuft, spielen Logiken/KNX/etc. natürlich verrückt...

[gaert]

Ha! Endlich kann ich das Problem mal nachstellen - mit einer max. Rate von 1/s passiert was hier... Ich bleibe am Ball

[Marha]

gaert
Brauchst Du dann das Log noch? Komme vor heute Abend nicht dazu.

[powell]

Mal als positive Info, ich habe mit dem MDT Router seither mit 1.60 kein Problem mehr.
Läuft bisher einwandfrei!

LBS mit Timingprobleme hab ich wohl nicht drin. Wenn ich alle Logiken die ins Datenarchiv schreiben(wie weiter oben gepostet) deaktiviere startet edomi sehr schnell.
Sobald ich diese aktiviere dauert es ein wenig länger und Logic Queued ist am Anfang recht lange rot.

Gruß
Patrick

[hartwigm]

Ich habe um 9:17 mein Projekt nochmals aktiviert (keine Änderungen)

Hier ein paar Hardcopies. Die Queue vom Start wird nach 40min immer noch abgearbeitet.

Was auffällt ist dass nicht ein Telegramm hängen bleibt, sondern dass hier kontinuierlich die ID´s nach oben laufen.

Insofern rechne ich damit, dass im Laufe des Tages die Queue wieder bei NULL ankommt. Während der Zeit läuft das KNX Timing nicht. Alle direkten KNX Kommandos laufen, aber die KNX Kommando aus Edomi kommen extrem zeitverzögert.

Meine Haustüre öffnet und schließt automatisch. Leider hat die Türe aber nur einen Trigger für Auf und ZU.
Abhängig vom Status führt das Triggern zum öffnen oder schließen. Da aber ein KNX Telegramm nun ein paar Minuten braucht bis Edomi dies verarbeitet, greift die Überwachungslogik in Edomi, welche die offene Türe nach 90sec wieder schließen will. Diese ist aber ZU nur das Telegramm noch nicht verarbeitet.

Edomi schickt dann einen Trigger raus, (ebenso zeitverzögert, aber kommt!) Dies führt dann dazu dass die Türe wieder geöffnet wird und wir einen Tag der offene Türe haben.

(so wird nun seit 50min endlich mal wieder durchgelüftet!)

Ich bin mir zwischenzeitlich ziemlich sicher, dass dieses Verhalten einfach ein Mengenproblem ist. Bei mir habe ich 7 KNX Linien und und 12 Wiregate Busmasterlinien mit mehr als 1000 Sensoren. dann noch 16 Kamera´s und vieles mehr.

Bei einer 2ten Installation mit 2 KNX Linie habe ich noch NIE 2min nach dem Start irgendwas in der KNX Queue gesehen.


Ergänzung: Bei der 1.59 und vorigen Versionen hatte ich dieses Verhalten auch, allerdings war das meist durch einen neue Aktivierung erledigt. Gefühlt führten 4 von 5 Aktivierungen zu einer leeren Queue innerhalb von 10min

Bei der 1.60 dürfte es umgekehrt sein, 4 von 5 Starts führen zu einer vollen KNX-Queue, allerdings scheint diese nach ewiger langer Zeit in Richtung NULL zu laufen.

Vielleicht hilft das ja gaert den Fehler zu finden

nach 10min.PNG


3 min später.PNG

weitere 3min.PNG


5..PNG

[gaert]

Also, es ist so:

Prinzipiell funktioniert das Alles wie ich es vorgesehen habe, jedoch steckt da wohl ein Denkfehler meinerseits drin...:

Angenommen wir senden 100 Telegramme per Oszi so schnell wie möglich in die Queue, sagen wir dies dauert pro Telegramm 1ms also 100ms insgesamt.
Bei einer versuchsweise definierten Telegrammrate von 1/s wird die Queue nun abgearbeitet, spricht die Telegramme werden innerhalb von 100 Sekunden(!) auf den Bus gegeben. Also natürlich viel langsamer, als vom Oszi vorgegeben - bei einer realistischen Rate von z.B. 20/s würde es immer noch 5 Sekunden dauern (statt 100ms).

Klar soweit?

Dies lässt sich natürlich nicht ändern, denn der Bus ist nunmal langsamer als der Oszi (in diesem Fall).

Was EDOMI aktuell macht ist folgendes:
Die Queue wird quasi in einer künstlichen Raumzeit abgearbeitet, d.h. entscheidend ist der zeitliche Abstand zweier Telegramme (dieser wird stets beibehalten, nur eben relativ zur gewünschten absoluten Zeit des Telegramms).

Beispiel: 3 Sekunden nachdem der Oszi fertig ist, soll ein weiteres Telegramm gesendet werden und landet 3 Sekunden später eben in der Queue. Beim Abarbeiten passiert nun folgendes: Nach dem die Oszi-Telegramme abgearbeitet wurden (also nach 100 Sekunden bei 1/s), wartet der Prozess 3 Sekunden lang, bevor er das o.g. weitere Telegramm absetzt. Denn sonst würde dieses ja u.U. zu früh gesendet werden - man denke an zeitkritische Trigger (Garagentor) oder ähnliches.

In Summa führt dies natürlich dazu, dass der gewünschte Zeitpunkt eines Telegramms immer weiter vom Zeitpunkt des tatsächlichen Sendens abdriftet... Jetzt muss ich mir eine Lösung einfallen lassen und das ist wohl garnicht mal so trivial. Die einfachste Option wäre natürlich: Einfach so schnell wie möglich die Queue abarbeiten - ohne Rücksicht auf irgendwelche Zeitstempel. Dies könnte allerdings dazu führen, dass in einer ungünstigen Konstellation die Telegramme zu schnell gesendet werden, so dass z.B. ein Garagentor-Trigger statt 1 Sekunde nur 0.5 Sekunden lang andauert...

Vereinfacht gesagt haben wir's hier mit 2 unabhängigen Timelines zu tun:
- in der Queue stehen quasi die gewünschten Zeitpunkte (relativ zu einander)
- der KNX-Prozess muss dies jetzt in eine reale Zeit umsetzen - je nach Rate, Busverkehr (empfangen!) etc. ist dies natürlich nicht zwangsläufig synchron zur Queue

Ich geh' mal in Klausur mit mir selbst...

[hartwigm]

gaert
Kannst Du nicht die Initialisierungqueue, die beim Aktivieren entsteht bis auf 0 abarbeiten, und dann auf den quasi Modus 2 umschalten und die Timestamps beachten.

[Meine Queue von Heute Morgen 9:17 ist jetzt immerhin schon bei der ID 1983 angekommen]

[gaert]

Ich könnte, aber wäre das wirklich eine Lösung? Das endet dann irgendwann in zig Ausnahmen etc. - und sowas möchte ich möglichst vermeiden.

Das Kernproblem bliebe ja bestehen:
Wie stelle ich sicher, dass die zeitliche Integrität meiner Telegramme erhalten bleibt - trotz naturgemäß langsamem Bus...? Die korrekte Antwort wäre: Das ist nur möglich, wenn die Telegramme auch nur mit einer max. Rate in der Queue landen... Und das will natürlich niemand.

Im Prinzip müsste man der Queue noch mitteilen, was man eigentlich will - handelt es sich um ein zeitkritisches Telegramm oder nicht. Also eine Art Priorisierung. Aber dies im Nachhinein einzubauen wäre schon hart...

Übrigens:
Mit ist das Problem nie aufgefallen, da ich keine zigtausend Telegramme hintereinander weg sende... InitScan sind rund 200 Stück - das dauert ein paar Sekunden. Ansonsten komme ich auf ein paar Hundert Telegramme am Tag (ausgehend).

[phili]

Aber dies im Nachhinein einzubauen wäre schon hart...

Aber schon wichtig. Es wäre schade wenn edomi nur korrekt arbeitet wenn bestimmte Voraussetzungen an erzeuge Telegramme erfüllt sind.
Wie können wir helfen? Könnte es helfen, wenn du die Datenstruktur und den Quelltext der KNX Anbindung bereitstellst?

[vento66]

Wie können wir helfen? Könnte es helfen, wenn du die Datenstruktur und den Quelltext der KNX Anbindung bereitstellst?

LOL der Teil ist der Grund warum EDOMI auf Centos6.5 läuft. Genau der Part ist mit den Bcompiler verschlüsselt

[saegefisch]

wäre dann der Default: "so schnell wie möglich" (ASAP) nicht sinnvoll, um möglichst rasch den Berg abzuarbeiten (ohne eine unerwünschte Init-Ausnahme)? Ich habe selber zwar auch kaum Probleme, aber manchmal hakt auch mal eine Lichtszene einen Moment, das sind bei mir auch ein ganzer Sack Telegramme. Zeitkritische Diagramme habe ich nach meiner Erinnerung gar nicht, das löse ich schon immer lieber dezentral im KNX-Aktor (Treppenlichtfunktion), denn da bin ich mir sicher, dass nix schief laufen kann. Beispiel: Türöffner; bei mir 2 Sekunden; wenn dann keiner gedrückt /geöffnet hat, bleibt die Tür zu.

Nur bei zeitlich kritischen Diagrammen - ich vermute hier mal nur wenige wirkliche Anwendungsfälle - kann man eine zeitkritische Verarbeitung festlegen. ggf. kann man das an/für einzelne LBS und Sequenzen auch eingrenzen und dort entweder optional oder fest verdrahten. LBS z.B. um bei Deinem Garagen-Beispiel die 1 Sekunde zu halten. Das Telegramm müsste bei der Abbarbeitung der "ASAP-Queue "nur" beim Abarbeiten an der richtigen Stelle eingereiht werden...
Beispiel: LBS Ein/Aus-Verzögerung 16000113 oder Triggerfolge 5-fach 130000023 oder sicher auch mal ein Customer-LBS 19xxx.

Nachtrag: Im Prinzip zwei Queues: Die Haupt-Queue verarbeitet ASAP, die zweite - bei den meisten vermutlich meist leer - kennt die wenigen zeitkritischen Telegramme in Bezug auf ein Vorgängertelegramm (in der Hauptqueue: tatsächlicher Sende-Timestamp auf den Bus) und sie werden bei erreichen des Zeit-Deltas in die Hauptqueue eingeschoben.

Annahme: zeitkritisch meint hier relativ zu einem Vorgänger, nicht absolut auf der Zeitachse. Letzteres kann man aus meiner Sicht überhaupt nicht sicherstellen, dafür ist edomi und ein solches Heimautomations-System insgesamt die falsche Lösung. Denn bei einem Haus sollten alle absolut geplanten Ereigenisse eigentlich auch +/- ein paar Minuten auch stets OK sein (Rolläden, Licht,...), den Vorrang hätten aus meiner SIcht stets das aktuelle Geschehen (jemand hat am KNX-Taster das Licht angemacht). Oder mir fehlt gerade die Phantaisie...