OpenKNX Firmware-Update

[Ing-Dom]

Ich habe heute mal einen Taster von MDT aktualisiert, die schaffen das auf 6-7 Minuten. Kann mir nicht vorstellen, dass die eine Firmware von nur 35KB haben.

eine ganze FW evtl nicht, aber wenn man sein binary richtig strukturiert muss man ggf nur teile updaten.

Du könntest einfach mal den Busmonitor mitlaufen lassen, dann könnte man sehen wieviel ca. durchgeht.
Ich habe mit Extended Frames experimentiert, und ja, mit APDU Richtung 55, 56 (was das MDT IP Interface hergibt)

[abeggled]

Die Jalousie-Aktoren von Griesser können über den Griesser Device Updater komplett aktualisiert werden. Aus meiner Sicht machen sie genau so ein Chunk Modell wie oben beschrieben. Die Updates dauern je nach Umfang zwischen 1-3 Stunden. Zudem können die Pausen zwischen den Busübertragungen verändert werden. Je kürzer die Pausen, je höher der Durchsatz, jedoch auch die fehlerhaften Übertragungen, sprich es müssen zu Ende der jeweiligen Phasen mehr Chunks wiederholt werden.
Ich finde das System echt cool gemacht und trotz der Dauer akzeptabel. Man macht das ja nicht alle Tage.

[Ing-Dom]

sowas in der Art schwebte mir für OpenKNX auch schon vor.

Eine Updater App, mit der man erstmal am Bus alle OpenKNX Geräte findet. Dann HW und FW identifiziert und anzeigt.
Dann lädt man ein Update File und kompatible Geräte können dann für das Update ausgewählt werden und man kann das Update (auch mehrerer) Geräte starten.

Ich fand ja die Idee eines Broadcasts noch ganz nett, wenn man z.B. 10 identische OpenKNX-Geräte mit der selben FW updaten will - erstmal broadcastet die PC App alles auf den Bus und die Geräte hören nur mit - und wenn der Broadcast durch ist fragen sie den Master noch nach Wiederholungen, bis eben jedes Gerät die komplette FW hat und dann wird das eigentliche Update gemacht und Reset.

Nachteil: man müsste die Daten über GA-Telegramme senden, also mit max. 14Byte Nutzdaten. Das vergrößert wieder den Telegramoverhead gegenüber z.B. einem ExtendedMemoryWrite...

[willisurf]

Eine Updater App, mit der man erstmal am Bus alle OpenKNX Geräte findet. Dann HW und FW identifiziert und anzeigt.

Das klingt wirklich gut.

Die Variante das Protokoll auch gleich für mehrere Geräte parallel würde ich allerdings vermeiden. Ich denke -ohne es komplett durchdrungen zu haben- das wird kompliziert und fehleranfällig und der Mehrwert ist im Verhältnis zu Mehraufwand und Risiko m.E. nicht gegeben.
Selbst wenn ich mehrere gleiche Geräte habe, so sind diese dann in der Regel im produktivem Betrieb und ich würde tatsächlich immer nur sequentiell eines updaten und schauen ob alles läuft.

[mumpf]

Hmm, wenn wir soweit gehen, sowieso alles über eigene Apps zu machen, könnte man sich natürlich auch Gedanken zum Delta-Update machen.
Also ich weiß, welche Firmware auf dem Gerät ist, habe das Binary lokal vorliegen und berechne nur ein Delta-Paket, dass ich wirklich zum Gerät schicke.
Ich habe keine Ahnung, wie uf2-Firmwarefiles aufgebaut sind, aber meine Hoffnung wäre, dass die teile arduino, pico-earle und knx-stack quasi großteils gleich bleiben. Und wenn deren Binary auch gleich bleibt, wäre die zu übertragende Menge wesentlich geringer.

ich würde tatsächlich immer nur sequentiell eines updaten und schauen ob alles läuft.

Du musst hier update (also die übernahme der neuen Firmware in den produktiven Betrieb) gedanklich trennen von der Übertragung der Firmware. Es müsste keinesfalls so sein, dass das Gerät sofort nach der Übertragung auch ein Update macht. Das könnte man bei einer eigenen App explizit anstoßen.
Und dann könnte man übertragen, anschließend nur einem Gerät sagen "mach Dein Update", dann testen, und wenn alles gut war, den Update-Befehl an die anderen schicken, die aber schon beim ersten Mal bei der Übertragung mitgemacht haben.

Nachteil: man müsste die Daten über GA-Telegramme senden, also mit max. 14Byte Nutzdaten. Das vergrößert wieder den Telegramoverhead gegenüber z.B. einem ExtendedMemoryWrite...

Bist Du da sicher? Ich hatte Thomas so verstanden, dass man auch eigene Services in den Stack implementieren könnte... und das könnten doch dann auch Broadcasts mit einer eigenen Frame-Länge sein, oder?

Aber das sind alles Ideen, wenn ich sehe, wie langsam die Entwicklung mit der bereits vorhandenen Infrastruktur geht, weiß ich nicht, woher die Zeit für alternative Infrastrukturen kommen soll?

Gruß, Waldemar

[STSC]

Ich habe keine Ahnung, wie uf2-Firmwarefiles aufgebaut sind, aber meine Hoffnung wäre, dass die teile arduino, pico-earle und knx-stack quasi großteils gleich bleiben. Und wenn deren Binary auch gleich bleibt, wäre die zu übertragende Menge wesentlich geringer.

Wenn nur eine Zeile Code geändert wird entsteht normalerweise ein komplett neues Binary. Prinzipiell könnte man so ein Teilekonzept machen, aber das ist sehr aufwendig.
Ich denke das ein Compressed-Delta-Binary Konzept zw. vorhergehender und aktueller Firmware evtl. einfacher wäre. Für den ESP32 gibt es schon fertige Libs wie bsdiff/bspatch, aber das kenne ich auch nicht.

[willisurf]

Du musst hier update (also die übernahme der neuen Firmware in den produktiven Betrieb) gedanklich trennen von der Übertragung der Firmware.

Ja, das stimmt.
Ich würde es gefühlt aber trotzdem einfach halten und erstmal nur ein Gerät betrachten.
Kann natürlich sein, das ich nicht genug visionär oder risikobereit bin

[thilog]

eine ganze FW evtl nicht, aber wenn man sein binary richtig strukturiert muss man ggf nur teile updaten.

Ich hab' hier ein Firmware-Update für einen MDT Glastaster II Smart liegen. Das hat als Hex-File ~ 280 kB, binary auf der Leitung also entsprechend weniger. Im Hex-File sieht man ganz schön, dass das Update in mehrere Adressbereiche aufgeteilt ist, der Speicher also nicht komplett (und auch nicht immer sequentiell) neu geschrieben wird. Es würde mich wundern, wenn mit dem Update deutlich mehr Logik verbunden wäre. Allerdings ist da ist vmtl. aber der Aufwand für ein mögliches Partial Update zuvor in die Erstellung des Hex-Files reingeflossen.

[Ing-Dom]

Ich hatte Thomas so verstanden, dass man auch eigene Services in den Stack implementieren könnte... und das könnten doch dann auch Broadcasts mit einer eigenen Frame-Länge sein, oder?

So gut kenne ich den KNX Standard nicht, aber ich hätte jetzt gedacht dass man nicht einfach neue Telegramme "erfinden" kann.
Wer weiß welche Rückwirkungen das irgendwo hat.

Aber das sind alles Ideen, wenn ich sehe, wie langsam die Entwicklung mit der bereits vorhandenen Infrastruktur geht, weiß ich nicht, woher die Zeit für alternative Infrastrukturen kommen soll?

Think Big
Ja ne, erstmal haben wir dringendere Dinge zu lösen. Trotzdem darf man finde ich, über solche Dinge nachdenken und darüber diskutieren.

[Ing-Dom]

Ich habe keine Ahnung, wie uf2-Firmwarefiles aufgebaut sind, aber meine Hoffnung wäre, dass die teile arduino, pico-earle und knx-stack quasi großteils gleich bleiben. Und wenn deren Binary auch gleich bleibt, wäre die zu übertragende Menge wesentlich geringer.

Der Aufbau einer UF2-Datei ist relativ einfach.Das sind aneinandergereihte 512byte-chunks mit bis zu 476byte nutzdaten. Der Rest ist Metainfo.
Wenn man die Nutzdaten aus dem UF2 extrahiert bekommt man am Ende die Daten die auch im .bin stehen würden.
Das UF2 ist einfach nur ein Dateiformat dass sehr einfach geparst werden kann, mit kleinen BLern.

[thewhobox]

So gut kenne ich den KNX Standard nicht, aber ich hätte jetzt gedacht dass man nicht einfach neue Telegramme "erfinden" kann.
Wer weiß welche Rückwirkungen das irgendwo hat.

In der KNX Spec ist sogar ein Teil der APCI für Hersteller reserviert.
Somit sollten hier keine Konflikte entstehen, da auch die Verbindung immer nur zu einem Gerät ist.

image.png
Reserved USERMSG: ~45 APCI
Manu Specific Area: ~7 APCI

[thesing]

Ich vermute mal die verschiedene Libs fest im Flash haben. Beim ESP ist das auch so, dass bestimmte Funktionen im ROM sind und der Linker die entsprechende Adresse nutzt. Etwas Ähnliches könnte man sicher auch machen. Da müsste man aber die LInkscripte anpassen.