OpenKNX KnxFileTransferClient

[thewhobox]

Der CRC Fehler wurde am Ende ausgegeben. Da werden local und remote Datei verglichen.

Es gibt nun die 0.2.9
Da wurde das Problem behoben. War leider ein Bug.

[jhaeberle]

Es gibt nun die 0.2.9

Behebt die Version auch das Problem mit den drei abzuziehenden Bytes bei der Package-Size?

[thewhobox]

Nein. Dafür muss die Version Remote 0.1.5 sein (also auf dem Gerät).
Die habe ich am Wochenende für v1 freigegeben und wird nun mit den kommenden Updates der Geräte einzugerhalten.

Bis dahin muss man selbst noch 3 Bytes abziehen von der MaxApdu.

[mumpf]

Da ich - auf anderen Kanälen - gefragt wurde, warum das mit dem FileTransferClient so schlecht läuft und wir es nicht schaffen, ein "ordentliches" Update über den Bus zu machen, hier nochmal ein paar allgemeine Infos und die bekannten Problemstellen:

Damit wir Daten über den KNX-Bus außerhalb der ETS übertragen können, ist natürlich ein Programm notwendig, dass auf dem Rechner, der übertragen soll, auch installiert ist - das ist der FileTransferClient. Aber auch auf dem Gerät, dass die Daten von was anderem als der ETS empfangen soll, ist ein Programm notwendig, von uns einfach "Remote" genannt. Die Remote wird schon seit sehr langem mit der Firmware ausgeliefert (in den Versionen 0.1.0, 0.1.1, 0.1.2, 0.1.3, 0.1.4 und 0.1.5) und ist so geschrieben, dass sie möglichst wenige Updates braucht - aber man sieht, wir sind trotzdem inzwischen bei der 6. Version.
Der FileTransferClient ist in der gleichen Zeit bestimmt schon 20 mal aktualisiert worden, aber das ist auch OK, denn ein Programm auf einem Rechner zu aktualisieren ist einfacher als auf vielleicht 20 oder 30 OpenKNX-Geräten.

Der FileTransferClient versucht immer, mit allen Remote-Versionen klarzukommen, aber manche Neuerungen können erst wirken, wenn die passende Remote auf dem Gerät installiert ist. Und da beißt sich die Katze in den Schwanz, denn die neuere Remote kommt ja mit der Firmware, die ja erst mit dem FileTransferClient übertragen werden muss. Man bekommt also das Gefühl, dass sich da nichts getan hat und es noch "genauso schlecht" läuft.
Ähnlich verhält es sich, wenn man in seiner Anlage unterschiedliche OpenKNX-Geräte mit unterschiedlichen Remote-Versionen hat. Dann wirkt der FileTransferClient "unzuverlässig", weil es manchmal klappt und manchmal nicht.

Trotzdem haben wir aus den vergangenen Problemen sehr viel gelernt und stetig sowohl am FileTransferClient wie auch an der Remote gearbeitet. Inzwischen werden robust sehr viele Protokollfehler, die auf dem Bus passieren können, erkannt und korrigiert. Dazu zählen

• fehlende Antworten vom Gerät
• unterbrochene Kommunikation durch Timeout (vom Gerät oder beteiligten Schnittstellen/LK)
• falsche Telegrammreihenfolge (z.B. durch Wiederholungen)
• und viele andere Kleinigkeiten.

Der FileTransferClient 0.2.9 läuft in Verbindung mit einer Remote 0.1.3, 0.1.4 oder 0.1.5 auf einer Linie sehr robust, ich hatte im letzten Monat von meinen ca. 30 Updates keinen einzigen Abbruch, alle sporadisch vorkommenden Fehler konnten automatisch korrigiert werden.
Bei mehreren Linien (wenn die Telegramme durch einen oder mehrere Koppler müssen) haben wir noch nicht so viele Erfahrungen, hier ist aber erst eine deutliche Verbesserung zu erwarten, wenn die Remote die Version 0.1.5 hat.
Bei reinen IP-Clients (z.B. dem Router) funktioniert der FileTransferClient schlecht bis gar nicht. Hier bieten wir aber auch direkt ein OTA-Update über IP an (und nicht über KNX-IP), das ist klar der bevorzugte Weg, da dieser schnell und robust ist.

Ich hoffe, ich konnte hier etwas Licht ins Dunkel bringen,
Grüße, Waldemar

[Alloc]

Ich kann auch nur sagen: Bei den ganzen Updates die ich gemacht hab lief alles Problemlos. Top Arbeit!

[LostWolf]

Was soll man eigentlich bevorzugt für die Schnittstelle verwenden?
UDP oder TCP?
image.png

[mumpf]

willisurf hat (soviel ich weiß) intensiv mit dem X1 UDP getestet. TCP sollte auch gehen, da hab ich aber keine Erfahrung mit, hab keine TCP-Fähige Schnittstelle.

Gruß, Waldemar

[willisurf]

mit dem X1 UDP

ja genau, nimm einfach den

[thewhobox]

Auf dem Papier wäre TCP schneller und Stabiler.
Da unsere Probleme aber nie an nicht ankommenden IP Paketen lagen spielt das keine große Rolle.

Da das ACK wegfällt denke ich mal so ~2-5% schneller.

Aber ja tcp ist bisher noch nicht wikrlich getestet.

[habreli]

Hallo,
ich habe ein Problem mit der Meldung "Datei ist leer". Kann ich hier noch irgendwo drehen ?
image.pngDanke, Hans

[thewhobox]

Die 0.1.4 hat noch größere Probleme, weswegen die Datei bei einem Abbruch nicht gespeichert wird.
Deswegen ist die Datei halt leer und es wird von neu gestartet.

Wenn die Verbindung dauernd abbricht am besten das Gerät kurz ausbauen und per USB updaten.

Was hast du für einen IP Interface?

[habreli]

Ich habe von EIB-Markt die N000401.

[thewhobox]

EIB-Markt die N000401

Puh das ding sieht echt alt aus...
Ich vermute einfach, dass der keine APDU von 128 unterstützt.
Probier mal den Aufruf mit --pkg 15
Wenn das funktioniert kannst immer etwas höher mit dem Wert gehen, bis es nicht mehr funktioniert.

[habreli]

Danke das war die Lösung.
Welches IP-Interface wäre denn empfehlenswert ?
Mehrere gleichzeitige Verbindungen müssen möglich sein.
Und evtl. eine Secure Connection wäre auch nicht schlecht.

[thewhobox]

Welches IP-Interface wäre denn empfehlenswert ?

Natürlich der OpenKNX Router^^ Hat ja auch Tunneling.

Aber eig alles gut, was ne APDU von 240 und größer unterstützt.
MDT ist von der Geschwindigkeit her auch sehr gut.