KNX Telegramme mit FALCON mitlesen - wie erkenne ich "verlorene" KNX-Telegramme?

[FranzBeranek]

Hallo zusammen,

ich habe, auch mit Hilfe dieses Forums in VB.net (VS17) und Falcon 5.7.426 ein Programm realisiert, welches alle KNX-Telegramme am Bus mitliest.
Das System ist seit 2020 erfolgreich im Betrieb. Jetzt arbeite ich an den letzten Feinheiten...

Ich empfange die Telegramme asynchron mit "Sub BusOnGroupValueReceived(ReceivedValue As GroupValueEventArgs)" - nun such ich nach einer Lösung wir ich erkennen kann, dass Telegramme nicht schnell genug abgeholt wurden - in den Datenstrukturen "GroupValueEventArgs" finde ich nichts...

Kann mir da jemand einen Tip geben?

Danke, freundliche Grüsse
Franz Beranek

[Klaus Gütter]

Hallo Franz,

ich verstehe die Frage nicht. Was meinst du mit "abgeholt werden"? Von wem wo abgeholt?

Gruß, Klaus

[thewhobox]

dass Telegramme nicht schnell genug abgeholt wurden

Dadurch, dass KNX-TP mit seinen 19200 baud erheblich langsamer ist als IP, kann nie ein "Rückstau" (oder was auch immer du meinst) entstehen.

Jetzt frage ich mich aber, was meinst du mit "verlorenes Telegramm"?
Wenn die verloren sind (also auch schon nicht an der Schnittstelle ankamen), wie soll die Schnittstelle dir dann sagen können, dass eins verloren ging?^^

Gruß Mike

[Klaus Gütter]

Von IP hat er doch gar nichts gesagt?
(und TP ist auch nur 9600 bit/s)

[thewhobox]

Selbst USB ist doch deutlich schneller.
(ja Tatsache. Umso mehr wird dieser Fall nie auftreten ^^)

[FranzBeranek]

Hallo zusammen und Danke für Eure rege Beteiligung – ich versuche näher zu erklären:

Betrachten wir den Weg eines KNX-Telegramms in mein VB.net-Programm (genannt KNXlink)

KNX-Bus -> Interface -> Falcon -> KNXlink

Am KNX-Bus kommen die Telegramme in mehr oder weniger kurzen Intervallen an – am Bus gibt es kein Speichern von Telegrammen, alles funktioniert in Echtzeit

Das Interface (Weinzierl, KNX USB Interface Stick 332) – setzt diese KNX-Telegramme auf USB um – auch das passiert in Echtzeit

Falcon stellt die Verbindung vom Interface zur Software her – ob/was Falcon „speichert“ weiss ich nicht

KNXlink – ist mein Programm – es liest alle Telegramme mit und verteilt diese nach bestimmten Kriterien an Subscriber, dies erfolgt über IP (ist aber eigentlich unwichtig) - KNXlink arbeitet mit Multithreading, damit in einem Thread „jederzeit“ die asynchrone Empfangsroutine für ein KNX-Telegramm angesprungen werden kann – diese liest dann (aus Falcon) das Telegramm aus und gibt dieses Telegramm „pfeilschnell“ über eine Queue programmintern an einen anderen Thread zur „gemütlichen“ Verarbeitung (und Verteilung an die Subscriber).

Die Frage, die sich mir stellt: wie kann ich sicher sein, dass bei dieser Methode kein Telegramm verloren geht?

Meine Gedanken dazu: manchmal „prasseln“ die KNX-Telegramm ja regelrecht über den Bus, also auch (KNX-seitig über das Interface) an Falcon – Falcon ruft für jedes Telegramm die asynchrone Sub (in nenne sie asySub) „BusOnGroupValueReceived“ auf, als Daten wird die Struktur „GroupValueEventArgs" mitgegeben – dann weiter wie oben beschrieben: pfeilschnell in die Queue, gemütliche Verarbeitung in einem anderen Thread - soweit so gut...

Was aber passiert, wenn KNXlink zu langsam oder blockiert ist (warum/wie auch immer) – dann will Falcon die Telegramme abliefern, die asySub ist aber nicht bereit – dann „staut“ es sich – und eigentlich weiss ich nicht WO, in Falcon oder im Aufruf der async Sub – jedenfalls können dann Telegramme verloren gehen !

Ich habe dies getestet, indem ich KNXlink 10 Sekunden angehalten habe – nach den 10 Sekunden passieren dann in „Null-Zeit“ viele Aufrufe von asySub (in meinem Fall zB 15 mal) – aber ob diese zB 15 Telegramme alle sind kann ich programmtechnisch nicht erkennen...

Ich weiss aber, dass dabei Telegramme (am Weg vom KNX-Bus in mein KNXlink) verloren gehen – dies weiss ich deshalb, weil mein GIRA-HomeServer alle Telegramm in einem Ringspeicher ablegt und diesen lese ich dreimal Täglich aus und speichere die Telegramme in einer Datenbank – damit kann ich dann vergleichen...

Danke nochmals für Eure Unterstützung, freundliche Grüsse
Franz

PS @Klaus: Du hast mir damals, 2020, geholfen sodass ich KNXlink überhaupt machen konnte - und wie gesagt läuft seither tadellos - Danke auch dafür nochmals...

[Klaus Gütter]

Hallo Franz,

der Falcon 5.7 hat intern eine Queue von ich glaube 20 Telegrammen, beim Falcon 6 sind es eher sowas wie 1000. Wenn dein EventHandler die Daten sofort in eine eigene Queue schreibt und nicht minutenlang blockiert, ist sowieso alles gut. Da geht nichts verloren - solange nicht irgendwo in der Kette eine Verbindung abreißt.

Und mehr als so ca. 30 Telegramme/s kann der KNX ja sowieso nicht liefern. "Prasseln" würde ich das jetzt nicht nennen.

Gruß, Klaus

[FranzBeranek]

Hallo Klaus, danke für die rasche Antwort.

Dass Falcon eine Queue hat, habe ich zwar vermutet, aber keine Doku darüber gefunden – wo würde ich sowas finden? (ausser im Kopf eines KNX-Gurus)

20 Telegramme als Queue sind aus meiner Sicht doch eher wenig – bei mir kommen, wenn es „prasselt“, in der ersten Sekunde 15, dann 27, dann 36, dann 20 Telegramme, also fast 100 Telegramme in 4 Sekunden...

Welche Vorteile (ausser dem grossen Buffer) aber auch Probleme hätte ich bei einem Umstieg auf Falcon 6 zu erwarten? Ich parametriere meine KNX-Umgebung mit ETS4 und einige Aktoren mit ETS6 – ich plane in den nächsten Monaten auf ETS6 umzusteigen – hat dies irgendeine Bedeutung bzgl Falcon 6?

Ich weiss jetzt sehr viel mehr, trotzdem bleibt die Frage:
Wie erkenne ich, dass Telegramme verloren gingen?

Danke, freundliche Grüsse
Franz

[Klaus Gütter]

Du schreibst doch, dass du im Eventhandler bloß das Event in eine eigene Queue einfügst, das wird jeweils ein paar Mikrosekunden dauern. Da bist du doch bei 100 Telegrammen in 4 Sekunden meilenweit von einem Problem entfernt.

Ob du Falcon 5 oder Falcon 6 benutzt hast nichts damit zu tun, mit welcher ETS die Installation programmiert wurde. Es gibt in der Hilfe zu Falcon 6 ein Kapitel, wo die wesentlichen Unterschiede zu Falcon 5 aufgelistet sind. Auf mittlere Sicht ist ein Umstieg schon daher sinnvoll, weil Falcon 5 nicht mehr weiterentwickelt wird.

[FranzBeranek]

Danke Klaus, wieder viel gelernt.
Ich habe den ganzen Tag getestet und gemessen - natürlich hast Du recht – ABER...

Meine asySub braucht im Normalfall weniger als 1 Millisekunde – das wäre ja gut so – ABER – manchmal braucht sie 16 Millisekunden (Mindestabstand 4 Sekunden)! ganz selten sogar 31 – es passiert mit verschiedenen Gruppenadressen (welche empfangen werden) es passiert an unterschiedlichen Stellen in asySub (ich habe Teilabschnitte in der asySub gemessen) – undurchschaubar - i werd narrisch (der legendäre Ausruf des österreichischen Sportreportes Edi Finger beim Sieg von Österreich gegen Deutschland in der Fussball WM in Cordoba)...

Es sieht für mich so aus, als ob diese Verzögerung „irgendwie von aussen“ kommt – ich habe dann KNXlink solo auf einer Maschine gestartet – keine Änderung – ich habe KNXlink die höchte Priorität gegeben (obwohl solo auf der Maschine ) – keine Änderung – was Windows10 da alles im Hintergrund herumwurschtelt weiss ich natürlich nicht – i werd... (siehe oben)

Wie weiter?
Ich stelle meine Versuche jetzt ein, bevor i wirkli narrisch werd – ich werde (so wie) bisher damit leben dass dieser Telegramm-Verlust höchstwahrscheinlich nicht auftritt – ich werde mir Falcon6 anschauen...

Unbefriedigend ist für mich, dass ich immer noch nicht weiss ob bzw wie ich erkennen könnte, dass Telegramme verloren gegangen sind? Aber darauf scheint auch der Guru keine Antwort zu haben.

Danke jedenfalls, freundliche Grüsse
Franz

[thewhobox]

pfeilschnell in die Queue, gemütliche Verarbeitung in einem anderen Thread

Wenn das hier korrekt ist, dann kann doch eig nur das einfügen in die Queue blockieren?

(ich habe Teilabschnitte in der asySub gemessen)

Was meinst du dann allerdings mit Teilabschnitten? Das ist ja nur ein Befehl: "queue.push(GroupData)"
Alles andere wie Filtern oder sonst was sollte dann im anderen Thread passieren.

Wenn ich ein Event in C# habe, dann wird jedes Event mit der Funktion aufgerufen. Ganz egal ob das vorherige Event schon abgearbeitet war oder nicht.
Die Funktion an sich ist ja asynchron (leite ich mal aus dem Methodennamen ab).

Ohne hier den Source Code zu kennen, wird es nahezu unmöglich weiter zu helfen.

ob bzw wie ich erkennen könnte, dass Telegramme verloren gegangen sind

Gar nicht. Und selbst wenn, was willst du danach machen?
Du kennst weder den Absender, noch um welche GA es sich gehandelt hätte.


Gruß Mike

[FranzBeranek]

Also ganz so einfach ist die asySub nicht:
1. die mitgelieferten Daten auslesen
2. diese minimal aufbereiten
3. in die Queue schreiben
das meinte ich mit Teilabschnitten

Und ich erwarte gar nicht zu erkennen WAS verloren ging, sondern nur OB etwas verloren ging.

Gruss Franz

[thewhobox]

Das Auslesen und aufarbeiten gehört einfach nicht in ein Event, was auf Geschwindigkeit angewiesen ist.
Pack das in den anderen Thread und du hast keine Probleme.

Es gibt keine Möglichkeit zu erkennen, ob oder wie viele Telegramme du nicht bekommen hast.

Gruß Mike

[Klaus Gütter]

Die von dir gemessen Zeiten sind unglaublich hoch. Wie hast du das gemessen? Nicht alle Methoden sind brauchbar. Siehe auch https://stackoverflow.com/questions/...me-of-a-method.

Und wie Mike schon sagt: Es gibt keine Möglichkeit zu erkennen, ob oder wie viele Telegramme du nicht bekommen hast.

[FranzBeranek]

Hallo Zusammen,

Danke, jetzt weiss ich warum ich keine Möglichkeit gefunden habe zu erkennen, OB Telegramme verloren gegangen sind - weil es keine gibt! ist halt so...

klaus Danke für Deine fortgesetzte Hilfe - ich habe die Messung jetzt geändert (von now() auf Stoppuhr) - bringt im Prinzip dieselben (besser gesagt ähnliche) Werte - aber keine neuen Erkenntnisse - ich mach jetzt Schluss mit den Messungen - wieder was gelernt, Danke.

Ich fühl mich jetzt auch sicher, dass ich im Normalbetrieb kein Telegramm verpasse.

Mit Grüssen aus Krems
Franz