KnxFileTransferClient Hilfestellung

[Sisamiwe]

Hallo,

ich habe mich mal am KnxFileTransferClient versucht. Installation hat auf Windows funktioniert, Verbindung zum Bus wird auch hergestellt, aber es kommt immer zu einer Zeitüberschreitung beim Warten auf Antwort.

C:\Users\wenze\bin>KnxFileTransferClient open
Willkommen zum KnxFileTransferClient!!

Version Client:     0.2.1
Version Client.Lib: 0.1.0
Werte in Klammern sind default
Bei leerer Eingabe wird default übernommen
PA des Geräts (1.1.115):
(Auto|Search|Tunneling|Routing)
Verbindungstyp:  Search
01 Tunneling -> 192.168.2.11:3671       (1.0.0) [ABB IP-Router IPR/S           ]
02 Routing   -> 224.0.23.12:3671        (1.0.0) [ABB IP-Router IPR/S           ]
Es wurden 2 Gateways gefunden
Gateway Auswählen (Index): 01
Die Verbindung funktioniert möglicherweise nicht, da die Linien unterschiedlich sind.

IP-Adresse: 192.168.2.11
IP-Port:    3671
PA:         1.1.115

Info:  Verbindung zum Bus hergestellt
Error: Zeitüberschreitung beim Warten auf antwort

Kann jemand helfen bzw. Hinweise geben?
Vielen Dank.

[mumpf]

Es gibt 2 Parameter, mit denen man das noch beeinflussen kann:
--pkg 64 machst du die Pakete kleiner, die verschickt werden (Default ist 128)
--delay 200 macht die Pausen zwischen den Paketen länger (Default weiß ich nicht, ist aber sehr klein)

Ich würde mit --delay 200 Mal starten.

So wie ich das sehe, ist auch ein LK beteiligt, oder? Wir sind da selber noch am testen, ich habe festgestellt, dass es über einen LK hinweg nicht befriedigend funktioniert.

[mumpf]

Achso: --delay 200 meint 200ms Pause

[mumpf]

Sorry, war vorhin nur am Handy und hab Dein Log nicht richtig gesehen. Das ist nicht ein Problem, dass mit --delay gelöst werden dann, es kommt ja gar keine Verbindung zustande.
Du musst mal mit --pkg 23 versuchen und Dich langsam hocharbeiten. Dein LK lässt nur Pakete bestimmter Länge zu und die 128 (default) sind zu lang.

Hintergrund: Auf dem KNX-Bus spielt bei den Verbindungen die APDU eine Rolle. Die APDU gibt an, wie lang das längste Telegramm sein kann, dass dieses Gerät noch empfangen/senden kann. Bei Dir hat

• die ABB-Schnittstelle eine APDU, sagen wir mal 220 (ist nur ein Beispiel, ich weiß es nicht)
• der LK eine APDU, sagen wir mal 56
• unser OpenKNX-Gerät mit einer APDU von 250

Die ETS prüft beim Programmieren von Geräten am Anfang vom Programmieren mit kurzen (maximal 23 Byte langen Telegrammen, das müssen alle können) bei jedem Gerät, welche APDU es hat. Dann wird das Minimum genommen und damit programmiert. Im obigen Beispiel würden also Telegramme mit max. 56 Byte zum Proggen genommen werden.

Wir können das im FileTransferClient (noch) nicht, bei uns muss man die APDU vorgeben, indem man die Pakete klein genug macht.
Wenn Du mit --pkg 23 startest, muss es auf jeden Fall klappen, dass die Verbindung klappt. Falls nicht, dann kann das OpenKNX-Gerät noch keinen Filetransfer (da wäre dann die Version der OpenKNX-Firmware interessant, dann kann ich nachgucken).

Du kannst auch bei der Doku von Deinem LK nachschauen, welche APDU er hat, manche Hersteller schreiben das rein. Ansonsten "hochtasten", 63 ist z.B. eine Größe, die ich schon gesehen habe.

Gruß, Waldemar

[Ing-Dom]

Die ETS prüft beim Programmieren von Geräten am Anfang vom Programmieren mit kurzen (maximal 23 Byte langen Telegrammen, das müssen alle können) bei jedem Gerät, welche APDU es hat. Dann wird das Minimum genommen und damit programmiert. Im obigen Beispiel würden also Telegramme mit max. 56 Byte zum Proggen genommen werden.

Wir können das im FileTransferClient (noch) nicht, bei uns muss man die APDU vorgeben, indem man die Pakete klein genug macht.

Ich meine dass die APDU des Tunnel-Servers oder Routers geprüft wird vom KnxFileTransferClient, wenn nicht, wäre das relativ einfach machbar.
Auch das Zielgerät könnte man prüfen. Aber ein LK der dazwischen sitzt oder ein Repeater..
LK könnte man ggf. anhand der PA adressieren..

ABer bei Repeater fehlt mir jede Idee...

Theoretisch könnte man in den client eine Funktion einbauen, dass er immer automatisch einen "Ramp-Up" macht, also mit 23 beginnt und sich dann mit jedem Telegramm hocharbeitet bis es nicht mehr geht => zurück auf die letzte funktionierende Länge.

[mumpf]

Ich muss mich nochmals korrigieren: Ich dachte immer, die APDU gibt die maximale Telegrammlänge an, aber es ist die nutzbare Länge. Somit ist APDU 15 das kleinste, was alle können müssen. Ich glaube aber, dass dann --pkg die nutzbare Länge angibt. Also mit --pkg 15 sollte es auf jeden Fall klappen.

Belastbare Infos kann letztendlich hier thewhobox geben, er hat den FileTransferClient geschrieben.

Gruß, Waldemar

[thewhobox]

Genau die MaxApdu gibt die maximale Länge an Nutzdaten im Telegramm an + die 1/2 Bytes für die Apdu selbst.

Das minimum ist dabei 15, somit eig nur 13 Bytes an Daten wirklich selbst.
Wie Waldemar schon schrieb ist aber eig das was viele LK können so um du 55 Bytes.
Neuere können auch dann mal bis zu 255.


Ein Auslesen von LK dazwischen wäre evtl möglich, wenn man die Topologie berechnet.
Ich habe schon eine dev Version die zumindest dir Apdu der Schnittstelle ausliest und anpasst. Aber saß Dauer noch, bis das fertig ist.

Der default für delay ist übrigens 0.

Gruß Mike