fwupdate per KnxFileTransferClient tut nicht

[jhaeberle]

Hi,

wie ihr vielleicht schon wisst🤣, versuche ich meine RoundTouches und Sensor-Bigs von AB-SmartHouse upzudaten.

Ich habe den langen Thread hierzu aus dem Juli 24 gelesen und versucht umzusetzen. Ich bekomme eigentlich immer eine Verbindung hin, aber der Transfer scheitert stets, weil das Gerät nicht connected ist…

Als Interface verwende ich einen Timberwolf Server, der eine APDU von 55 hat, laut ETS 6.2.2

KnxFileTransferClient.exe fwupdate --pa 1.2.43 ./firmware-AB-SmartHouse-PresenceMR16.uf2 --pkg 55 --delay 300

Open ■
┬────┴  KnxFileTransferClient
■ KNX

Version Client:     0.2.7
Version Client.Lib: 0.1.4
Werte in Klammern sind default
Bei leerer Eingabe wird default übernommen
(Auto|Search|Tunneling|Routing)
Verbindungstyp (search):
 1 Tunneling -> 192.168.178.62:3700  (1.0.1   ) [Timberwolf Server]
Es wurden 1 Gateways gefunden
Gateway Auswählen (Index): 1
Die Verbindung funktioniert möglicherweise nicht, da die Linien unterschiedlich sind.

IP-Adresse: 192.168.178.62
IP-Port:    3700
PA:         1.2.43

Info:  Verbindung zum Bus hergestellt
Info:  PA der Schnittstelle ist 1.0.3
Info:  Verbindung zum KNX-Gerät 1.2.43 hergestellt
Info:  Gerät MaxAPDU: 254
Info:  Verwende MaxAPDU: 254
Info:  Verwende Package: 55
Version Remote:     0.0.4
Info:  Die Firmware wird komprimiert übertragen!
Version UF2:    0xA012 5.1.5
Version Device: 0xA012 4.0.2
File:       Passe Firmware für Übertragung an...
Size:       635477 Bytes        (620 kB) original
Size:       420624 Bytes        (410 kB) komprimiert


Info:  Keine Wiederaufnahme
Info:  Dateigröße: 420624 bytes
Error (01): Zeitüberschreitung beim Warten auf Antwort
Error (02): The Device is not connected.
Error (03): Zeitüberschreitung beim Warten auf Antwort
Error (04): The Device is not connected.
Error: To many errors
Upload fehlgeschlagen. Breche Update ab​​

Egal, was ich mache, ich habe am Anfang immer die Verbinmdung zum KNX-Gerät xxx hergestellt und unten dann Zeitüberschreitung und Device is not connected…

Ich hab zuerst mit expliziten Parametern laut Help versucht laut Help, dann mit --config laut Wiki… keine Ahnung, ob sich hier jetzt irgendeine Default-Config einmischt, die nicht passt… was mir auffällt ist, dass am Anfang der Tunnel mit der PA 1.0.1 gefunden wird, später heißt es aber, PA der Schnittstelle ist 1.0.3 oder 1.0.4. Das stimmt aber mit den Einstellungen in der ETS überein. 1.0.1 ist die Host-PA und 1.0.3 oder 1.0.4 die PA

Bildschirmfoto 2025-10-31 um 16.30.18.png

Die ETS nutzt das GW auch, über alle Linien hinweg derzeit völlig problemlos. Der Timberwolf bietet haufenweise Tunnel, so dass es daran auch nicht liegen dürfte. Das dürfte aber erklären, warum die PA sich mal ändert…

Ich habe kein secure.

Was kann ich tun?

Danke, Gruß

Jochen

[willisurf]

Versuch mal eine kleinere Packagegröße (32 oder ggf. noch kleiner) einzustellen.
Die Übertragung benötigt noch etwas Overhead, sodaß Du nicht die maximale Größe des Interfaces verwenden kannst.

[jhaeberle]

Versuch mal eine kleinere Packagegröße (32 oder ggf. noch kleiner) einzustellen.
Die Übertragung benötigt noch etwas Overhead, sodaß Du nicht die maximale Größe des Interfaces verwenden kannst.

Super, danke. Damit bewegt sich was… mit 95 B/s 😫

[willisurf]

sehr schön, und ja, es gibt bessere Interfaces.

[traxanos]

da wirst du dir mal ein vernünftiges interface zulegen müssen. eine apdu von 55 ist schon echt schlecht für updates.

[thewhobox]

Da ist leider noch ein Bug drin, bei dem die mögliche pkg falsch berechnet wird.
Du musst die pkg 3 kleiner als die MaxAPDu angeben.
Ein "--pkg 52" sollte bei dir also klappen.

Aber ja, für deutlich kürzere Zeiten solltest du ein Interface mit mehr als 55er maxAPDU verwenden

[FrankMaier]

Was für Datenraten kann man denn erwarten? Bei mir waren es glaube ich 200 Byte/s.

[willisurf]

Je nach IP Interface und Buslast bis zu 500 Byte/s

[jhaeberle]

Was für Datenraten kann man denn erwarten? Bei mir waren es glaube ich 200 Byte/s.

Das ist immerhin gut doppelt so schnell, wie bei mir…

[mumpf]

Ich bekomme in der Spitze 550 B/s, durchschnittlich sind es dann 520 B/s. Alles MDT-IPIF. Unser Router liegt bei ca. 330 B/s.
Sind aber alles Versionen, an denen wir testen, die sind noch nicht freigegeben.
Das wäre nur die Perspektive, wo wir hin wollen.

Gruß, Waldemar

[henfri]

Hallo,

ich hänge mich hier mal an. Ich habe gerade etwas mit dem knxfiletransferclient gekämpft - und bisher bin ich nicht durch.
Wäre es möglich, wenn die Update-Skripte die Parameter "durchreichen"? zumindest habe ich es nicht geschafft mit
./KNX-Upload-Firmware.ps1 --pkg 50 einen upload zu starten und musste mir die Syntax selbst zusammensuchen.

Ein anderer Punkt der echt komisch war: In 9 von 10 Fällen wurden meine Eingaben (das was ich getippt habe bei den interaktiven Fragen) nicht angezeit. Ich musste blind tippen. Ich meine das eine Mal, wo es ging, war eine cmd statt powershell, die ich geöffnet hatte

Gruß,
Hendrik

[thewhobox]

Ich denke das ist zu viel Aufwand.
Man müsste für die Skripte die gleichen Parameter anlegen wie für den Client.
Dann checken ob Parameter übergeben wurden oder default sind.

Du kannst das Powershellskript ja auch bei dir lokal anpassen und dann ausführen.

[henfri]

In Linux kann man die Kommandos ja durchreichen...

Geht das in PS nicht?

[traxanos]

generell kann man auch eine "~/bin/KNXFileTransferClient.ps1" anlegen mit den wunschsettings und kann dann weiter normal mit rechte maustaste das update starten

Write-Host "Executing KnxFileTransferClient.exe fwupdate --connect Search --pkg 207 --delay 100 $firmwareName"
~/bin/KnxFileTransferClient.exe fwupdate --connect Search --pkg 207 --delay 10 $firmwareName​

wenn man sowieso auf der konsole unterwegs ist macht der aufruf des ps1 keinen sinn, dann kannst du das filetransfertool direkt aufrufen.

[henfri]

Hallo,

ja, die richtige syntax wäre mir aber jetzt nicht geläufig gewesen... aber der Tipp ist gut.
thewhobox verbessert ja gerade eh die Kommunikation und --pkg wird dann zukünftig ausgelesen?
Ansonsten wäre es auch eigentlich sinnvoll den letzten --pkg Wert als default zu speichern, oder? Das würde das Problem ja auch lösen.

Gruß,
Hendrik