HS/FS HS Processing von repeated Telegrammen

[swenga]

Hallo zusammen,

kann es sein dass dem HS eine Logik zum Erkennen von repeated Telegrammen fehlt? Ab und an werden bei mir Telegramme repeated, sie rappeln halt doch ueber ein paar Segmente (IP, TP). Manche der Telegramme loesen Aktionen aus, die Dank Nils's Baustein auch geloggt werden. Und dabei ist mir aufgefallen, dass im Repeat-Fall die Aktion 4mal hintereinander geloggt wird!

Gibt es eine elegante "Entprell"-Möglichkeit? Eine Idee wäre ein Binärauslöser als Erstverarbeiter des Telegramms, bei dem "Telegramm-Intervall" aktiviert wird. Die Online Hilfe gibt mir bloss grad wieder Puls:
Experte - Logikbaustein Eigenschaften
Telegrammintervall
Ja: Nach dem Senden eines Telegramms über einen Ausgang ist dieser (und NUR dieser) Ausgang für den eingestellten Zeitraum gesperrt. Die Zeit wird in Sekunden angegeben. Der Minimalwert ist Null, was bedeutet, dass der Baustein KEINE Zeitsperre hat.
Nein: Der Baustein besitzt keine Zeitsperre.

Die Aktion ist pro Baustein zu setzen, nicht pro Ausgang. Werden jetzt dann alle Ausgänge des Bausteins so behandelt?

mfg

[NilsS]

Ich hätte da eine Möglichkeit auf Telegrammebene einzugreifen

Ist dann aber sicher nicht "ganz" so supported, aber fürs proof of concept sicher möglich.

Es gibt die Möglichkeit in die Eibempfangsqueue einzugreifen. (ab FW >2.4)
dann kann man die ADPU's direkt auswerten, und so halt auch repeated NICHT an die eigentliche QUEUE weiter reichen.

Ich wollte da nämlich schonmal nen Busanalyzer basteln.

[swenga]

Hallo Nils,

gute Idee. Jedoch sollten wir nicht den Ansatz wählen einfach alle Telegramme mit repeated Flag rausschmeissen. Manchmal ist das erste eben wirklich auf dem Segment flöten gegangen und wird daher repeated. Idelaerweise wäre also ein Telegrammpuffer zu implementieren:
Telegramm mit bekanntem KO kommt an und wird verarbeitet, zeitgleich wird im KO-Katalog ein Vermerk gesetzt. Kommt jetzt ein Repeated-Telegramm innerhalb Zeitspanne X, dass mit dem Erstverarbeiteten identisch ist, wird es verworfen. Idealerweise wuerde natuerlich auf dem TP geacked werden, aber das tut er wohl nicht, unser HS....

mfg

[NilsS]

Idealerweise wuerde natuerlich auf dem TP geacked werden, aber das tut er wohl nicht, unser HS....

Liegt aber AFAIK nicht nur am HS, sondern an der Schnittstelle (FT1.2 und USB glaub ich auch), die ist ja im Modus Busmonitor in der nicht geacked wird. die Gruppenaddressen in die BCU zu laden wird wohl eher nicht passen.

Beim KNX/IP sollte das aber drinnen sein.
vielleicht ließe sich das ja auch implementieren mit nem Baustein.

Telegramm wird empfangen, wenn iKO mit GrpAddr vorhanden, senden wir ein ACK. Das Problem ist aber.... das was da an der Queue ankommt ist ein HEX Telegramm und ich hab kein Bock das jetzt komplett auszuwerten und auch an anderer Stelle eins mit XOR CHKSUM & Co neu zu basteln.

Wenn du da Lust zu hast, gebe ich dir gerne eine passende Logikvorlage.

[swenga]

Och, bevor ich da in der Tiefe rumfrickele, stelle ich die Schnittstelle doch auf IP-Routing um ;-)

Da setze ich ja mit meinen Tools an, und da sehe ich auch Repeated-Telegramme. Vermutung, die werden wegen Kollisionen auf irgendeiner TP-Strecke wiederholt und gelangen damit auch als Repeated auf das IP-Segment. Meinst Du die werden im cEMI/IP-Stack des HS abgefangen? Wuerd mich wundern....

mfg

[NilsS]

Nein, die werden nicht abgefangen, ich meinte damit das FT1.2 und USB das nicht können und daher das sicher auch nicht für KNX/IP gemacht wurde, sondern hier wohl nur der cEMI entfernt wurde und der Rest wie gehabt ausgewertet wird.

[swenga]

Ich fände das auch ehrlich gesagt albern, das auf den Spardosen-ATMEL in der Schnittstelle abzuwälzen. Sowas ist Übertragungssicherung und gehört daher in der Auswerteebene, also dem Stack gemacht. Das sehe ich durchaus als ein Defizit, wo DACOM mal ran muesste.

Als Anwender erwarte ich "bereinigten" Datenverkehr, von einem TCP-Socket sehe ich auch nicht die Repeatings sondern nur die Nutzdaten, im duemmsten Fall loest sich z.B. der Socket wegen Timeout auf. My 2 cents....

Insofern danke fuer Dein Angebot Nils, ich werds erstmal mit dem Workaround Telegrammintervall probieren.

mfg

[NilsS]

Kurz aufgegriffen,
ist kein Busanalyzer, sondern nur mal eben zusammen geklatscht.