Probleme den KnxFileTransferClient zu installieren

[jhaeberle]

Hi,

ich hab's nicht so mit Windows und mit der PowerShell nun so gar nicht. Aber die Linux-Konsole ist mein Freund ;-)

Ich kriege den KnxFileTransferClient unter Win 11 nicht zum Laufen. PowerShell habe ich aktualisiert. Das Zip laut README entpackt und den Skript mittels Kontextmenü mit der PowerShell ausgeführt. Das Terminal-Fenster kommt kurz hoch, man sieht was rotes, das man aber nicht lesen kann, weil's gleich wieder weg ist. Bei weiteren Versuchen, den Installer-Skript nochmal laufen zu lassen, passiert nix.
Aufruf von

KnxFileTransferClient help

dauert beim ersten Mal lang, ergibt einen Not Found Error, der bei weiteren Aufrufen sehr schnell kommt…

Also probier ich's mit dem Kommando aus dem README:

PowerShell.exe -ExecutionPolicy Bypass -File .\Install-OpenKNX-Tools.ps1

Das klappt auch
Bildschirmfoto 2025-10-30 um 21.19.51.png Allerdings bleibt der Fehler. Auch in einem weiteren, neuen Terminal-Fenster bleibt das so.

Muss ich da vielleicht irgendeine DB updaten, dass das Kommando gefunden wird?

Danke, Gruß
Jochen

[willisurf]

Ist nichts kompliziertes, wahrscheinlich musst Du nur einmal dauerhaft die Restrictions setzen, siehe

P.S.: Falls eine falsche Firmware auf ein Gerät geflasht wurde, ist es möglich, das Du nur noch über Bootloader und USB flashen kannst.

[jhaeberle]

Hallo Bernhard,

funktioniert leider nicht. Bei mir gibt es Einstellungen > System > Erweitert > Entwicklermodus - das habe ich an gemacht:Bildschirmfoto 2025-10-30 um 21.43.21.png
Dann gäbe es da noch die PowerShell Ausführungsrichtlinie, aber die scheint mir die "verbotene" Einstellung CurrentUser = RemoteSigned zu erzeugen - jedenfalls geht das mit den angegebenen Shell-Komandos immer hin und her aktiv - nicht aktiv…

Aber das Ergebnis bleibt leider:
Bildschirmfoto 2025-10-30 um 21.43.41.png

[jhaeberle]

Falls eine falsche Firmware auf ein Gerät geflasht wurde, ist es möglich, das Du nur noch über Bootloader und USB flashen kannst.

Eine "falsche" Firmware? Meine Geräte laufen so weit alle, haben aber unterschiedliche Versionen, so ist jetzt endgültig der RaumController der Grund, dass ich die mal updaten will.
Oder willst du mich warnen, dass ich blos nicht die falsche Firmware auf ein Gerät schiebe???

[thewhobox]

Unter Powershell musst du ein Skript mit einem direkten Pfad aufrufen.
Wenn du also im selben Verzeichnis bist:

.\KnxFileTransferClient.exe help

Das "." ist wichtig.

Außerhalb des Installationspfads hab ich es selbst noch nicht probiert. Evtl fehlt die Dateiendung?

[Ing-Dom]

prober doch mal den Aufruf aus dem richtigen Verzeichnis mit dem vollständigem Dateinamen ? Könnte ein Suchpfad Thema sein.Screenshot 2025-10-30 221415.png

[willisurf]

Oder willst du mich warnen, dass ich blos nicht die falsche Firmware auf ein Gerät schiebe???

Ja, denn wir haben doch gerade diskutiert das die RaumController Software nicht auf dem RoundTouch läuft. Hätte ja durchaus sein können, das Du diese bereits geflasht hast.

[jhaeberle]

Hätte ja durchaus sein können, das Du diese bereits geflasht hast.

Danke für die Warnung. Aber mir ging es zunächst darum, meine RoundTouches alle auf die gemeinsame Version 1.2.1 zu bringen. Dan hätte ich darin den RaumController gesucht. Da ich den nicht gefunden hätte, wäre es dann weiter gegangen.

[jhaeberle]

prober doch mal den Aufruf aus dem richtigen Verzeichnis mit dem vollständigem Dateinamen ? Könnte ein Suchpfad Thema sein.Screenshot 2025-10-30 221415.png

So funktioniert es. Danke!

[jhaeberle]

Ich habe ein Skript gebaut, das den Suchpfad anpasst. Dann kann man in das Verzeichnis gehen, wo die Firmware liegt und erhält einen übersichtlicheren Programmaufruf… vielleicht hilft das mal noch jemand…

In Zeile 2 den Pfad auf die eigenen Gegebenheiten anpassen und als PowerShell-Skript (bspw setenv.ps1) abspeichern. Das Skript holt sich, wenn nötig die Admin-Berechtigung in einem neuen Terminal und fügt den Pfad, wenn nicht schon vorhanden, an den Suchpfad an. Nicht sehr schön, aber vlt. hilfreich.

# Den neuen Pfad definieren, der hinzugefügt werden soll
$newPath = " C:\Users\joche\bin\"


if (-NOT ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator"))  
{  
  $arguments = "& '" +$myinvocation.mycommand.definition + "'"
  Start-Process powershell -Verb runAs -ArgumentList $arguments
  Break
}

# Die aktuelle PATH-Umgebungsvariable für den Computer abrufen
$currentPath = [System.Environment]::GetEnvironmentVariable("Path", [System.EnvironmentVariableTarget]::Machine)

# Überprüfen, ob der neue Pfad bereits in der PATH-Variablen enthalten ist
if ($currentPath -notlike "*$newPath*") {
    # Wenn der neue Pfad nicht in der PATH-Variablen enthalten ist, ihn hinzufügen
    $newPathValue = "$currentPath;$newPath"

    try {
        # Die neue PATH-Umgebungsvariable setzen
        [System.Environment]::SetEnvironmentVariable("Path", $newPathValue, [System.EnvironmentVariableTarget]::Machine)
        Write-Output "Der Pfad wurde erfolgreich hinzugefügt."
    } catch {
        Write-Error "Fehler beim Setzen der Umgebungsvariable: $_"
    }
} else {
    Write-Output "Der Pfad ist bereits in der PATH-Variablen enthalten."
}​

Gruß
Jochen

[thewhobox]

Ich habe ein Skript gebaut, dass den Suchpfad anpasst.

Das brauchst du nicht.
Da der KnxFileTransfer im bin im Userverzeichnis liegt reicht ein einfaches:
"~\bin\KnxFileTransferClient --parameter xy --parameter zz"

Ich werde das mal ins Readme übernehmen.

[jhaeberle]

Das brauchst du nicht.
Da der KnxFileTransfer im bin im Userverzeichnis liegt reicht ein einfaches:
"~\bin\KnxFileTransferClient --parameter xy --parameter zz"

Ich werde das mal ins Readme übernehmen.

Mir ist das lieber. Ein Pfad weniger zum merken. Das Kommando ist schon schwer genug zu merken ;-) Außerdem kenne ich das so von Unix, da hantiert man öfter mal mit seinem Pfad.

Ich habe das auch gemacht, weil es in der Doku so aussah, als ob es „normal“ wäre, dass es zum Aufruf keine Pfadangabe bräuchte. Wenn dem nicht so ist, wäre das m.E. ein Ansatz für die Doku.

Noch eine Bitte zur Doku des Skriptes: Sollte man nicht aufnehmen, dass es zu Beginn hilfreich ist, den interaktiven Modus zu nutzen, um die Parameter zu ermitteln, die man für den Aufruf braucht. Und dann die Schritte zu erklären, welche Params es braucht, damit der interaktive Modus nicht aufgerufen wird. Und dann kann man seine Update-Orgien für die Nacht Skripten.

Klar bin ich irgendwann auch so drauf gekommen, aber ein paar Worte wären echt hilfreich gewesen.

Ein paar Worte zum Config-Pram wären noch cool, das wird zwar in einem Beispiel verwendet, aber nicht erklärt.

Danke, Gruß

Jochen

[traxanos]

Aber die Doku kennst du? Da stehen die Pfade

https://openknx.atlassian.net/wiki/s...-Dateitransfer

Ein paar Worte zum Config-Pram wären noch cool, das wird zwar in einem Beispiel verwendet, aber nicht erklärt.

der ist eigentlich für uns intern und weniger für anwender direkt.

Und dann kann man seine Update-Orgien für die Nacht Skripten.

das ist nett gedacht aber eine schlechte idee. du musst ja nach dem update in der Regel in der ets noch programmieren. sonst hast du im schlimmsten fall x geräte mit der 15.15.255.

[Alloc]

das ist nett gedacht aber eine schlechte idee. du musst ja nach dem update in der Regel in der ets noch programmieren. sonst hast du im schlimmsten fall x geräte mit der 15.15.255.

Hm, das bringt mich aber auf die Frage: Wäre es denkbar, dass der KnxFileTransferClient die (optionale?) Funktion bekommt, eine PA zu schreiben? Im Prinzip ist das ja
ein Standardablauf: Firmware-Update auf alte PA, danach in der ETS die alte PA wieder herstellen über die 15.15.255. Da das Programm aber die alte PA eh kennt und die "neue" auch, wäre es natürlich ideal, wenn es die alte PA dann einfach wieder herstellen könnte.
Ggfs. dann zur Absicherung vor dem Beginn des Update-Vorgangs an sich dann sogar noch prüfen, ob aktuell irgendein Busteilnehmer bereits auf die 15.15.255 hört, damit man dabei keine Konflikte bekommt - letzteres wäre eventuell sogar unabhängig von der anderen Funktion sinnvoll, damit man nicht aus Versehen mehrere Geräte auf einmal aktualisiert und dann die PA nicht mehr einfach geändert bekommt. Auch dann nicht zwangsweise als Abbruch, aber zumindest als Warnung und "Wollen Sie dennoch fortfahren?".

[willisurf]

Es macht keine Sinn, die Scripte weiter aufzubohren oder zu automatisieren. Dabei kann zu viel schief gehen.
Aus meiner Sicht bleibt es bei der Trennung Script für Entwickler oder als Fallback, aber mit der bisherigen Funktionalität.
Wir verzetteln uns sonst.

Für komfortable Firmwareupdates wird es eine Weiterentwicklung der Toolbox geben.