Compilerfehler bezüglich "Versionierung von Modulen (OFM): #fehler-vom-compiler

[MAKERWOLF]

Hi Leute!

Während ich auf die Geräte von Dom warte habe ich mir einen ESP32 Gateway aus teilen die ich schon habe gefrankensteint und soweit läuft das ding jetzt. Hab den OAM-IP-Router gecloned undd die v0_2_lwip branch ausgecheckt. Am schwierigsten war das LAN8720 Modul zur Kooperation zu überreden, aber auch das hab ich mit einer manuellen Konfiguration in der HardwareConfig->REG1.h hinbekommen, und diese mit einer neuen Umgebung in der platformio.custom.ini implementiert. Konnte das auch mehrmals neu compilieren bis es eben lief. Das Gerät bekommt nun eine IP und die ETS findet den IP Router, soweit so gut.

Nun habe ich das SEN-UP1-8xTH mit der v1 branch gecloned, einen pipico ebenso konfiguriert, dass er die notwendigsten geräte dran hat, compiled geflashed, soweit so gut.

Wenn ich jetzt aber den gleichen code von meinem IP Router repo kompillieren will kommt ein Fehler, und ich kann mir eigentlich nicht wirklich erklären warum. Versuche ihn natürlich (spoiler: erfolglos) zu beheben, aber schritt für Schritt, der Fehler:

You need to >>> INCREASE YOUR <<< ETS ApplicationVersion and manually synchronize op:verify of Common to 18

(see https://github.com/OpenKNX/OpenKNX/wiki/Versionierung-von-Modulen-(OFM)#fehler-vom-compiler )

Und hier beginnt der Spaß, ich find mir jetzt die einzelteile nicht mehr so leicht zusammen. Zuallererst frage ich mich, warum ist das INCREASE YOUR so wahnsinnig fett hervorgehoben. Die Frage ist natürlich sinnfrei, stellt sich mir aber dennoch in den Weg 😅
Also weiter zur ETS ApplicationVersion und den Link lesen:

1. im OAM-Haupt-XML die Applikationsversion des OAM zwingend erhöhen, damit in der ETS eine neue Version geladen werden muss.

ähh ok, wofür stand OAM nochmal? Es hagelt bei diesem Projekt nur so mit Abkürzungen, langsam wirds, aber es dauert, egal weiter -> wir brauchen die "OAM-Haupt-XML", da sind 6 stück, ich schätze die HauptXML wird die ohne Zusatz sein, also IP-Router.xml, Tatsächlich, die hat eine ApplicationVersion="5.0", machen wir 5.1, easy.

2. im OAM-Haupt-XML die ModuleVersion im op:verify-Tag auf die Version setzen, die in der Meldung angegeben wurde (im Beispiel 25)

Das muss dann in meinem Fall wohl hier sein:

  <op:define prefix="BASE" ModuleType="10" >
    <op:verify File="../lib/OGM-Common/library.json" ModuleVersion="1.3" />
  </op:define>​

Aber warum aus 1.3 jetzt 18 machen? Ich hab da bestimmt was übersehen, nur was? Egal, wir folgen erstmal blind der Anweisung!

Und jetzt wirds Spannend:

3. Mit dem OpenKNXproducer eine neue ETS-Applikation bauen und anschließend das Projekt neu compilieren.

Ok jetzt bin ich raus, ich hab jetzt nochmal versucht die Dokumentation, in der ich mich offengesagt eh schon eher schlecht zurecht finde, etwas darüber zu finden, wie ich mit dem OpenKNXproducer eine neue ETS-Applikation bauen soll, die doch schon längst gebaut sein müsste? Ich kann mit diesem Teil gerade leider gar nichts anfangen, und bin wieder zurück bei der Ausgangsfrage: Ich habe keinen Code geändert, ich habe nur noch einmal den Build-Button gedrückt, warum muss ich plötzlich so viel Tun, damit einfach eine neue Binary aus dem gleichen Code gebaut wird? Da muss doch irgendwo etwas anderes passiert sein, das ich nicht mitgeschnitten hab?

Bitte um Hilfe! Ich bin sicher, wenn ich das überstanden hab verstehe ich die Architektur einen großen Batzen besser 😅

[Ing-Dom]

aufgrund des modularen Ansatzes von OpenKNX ist es entscheidend, dass die verwendeten OFMs und OGMs (Definition siehe WIki) zum OAM passen.
Die OFMs und OGMs werden in der dependencies.txt definiert und über symlinks in lib projekt gezogen.
Das übernehmen aber die restore skripte. Steht im Wiki: wie baue ich...
Nach einem Aufruf von restore_depencies.ps1 sollte OAM-IP-Router ohne Änderungen durchbauen.

wie ich mit dem OpenKNXproducer eine neue ETS-Applikation bauen soll,

die meisten OAMs haben dafür einen Task (oder zwei.. füe die normale und die Beta Applikation)

Wichtig ist, dass du so ein OAM am besten in einem eigenen Ordner clonst - denn sonst bekommst du Wechselwirkungen zwischen den Repos. Das könnte bei dir der Fall sein. Ich arbeite daher so - damit hat jedes "Projekt" seinen eigenen clone von common, stack, etc..

[MAKERWOLF]

Ach du ... ich verstehe. Das bin ich so nicht gewöhnt. Tatsächlich musste ich nur die restore dependencies powershell laufen lassen. Ich hab mir das ja schon gedacht.

Alle größeren Projekte an denen ich bis jetzt gearbeitet habe, hatten ein solches Problem von vornherein nicht, gerade mit Platform.io geht die dependency verwaltung an sich wahnsinnig Elegant und plattformübergreifend. Gut zu Wissen, dann werd ich meine Denkweise entsprechend anpassen.

aufgrund des modularen Ansatzes von OpenKNX ist es entscheidend, dass die verwendeten OFMs und OGMs (Definition siehe WIki) zum OAM passen.

Ich versteh noch nicht ganz, wenn der Ansatz ja Modular ist, warum passen die dann nicht von Haus aus Zusammen? Was ist die designidee dahinter? Warum muss da immer ein restore skript laufen, damit die zusammen passen? Das hab ich tatsächlich noch gar nicht durchschaut ...

[Ing-Dom]

Ich versteh noch nicht ganz, wenn der Ansatz ja Modular ist, warum passen die dann nicht von Haus aus Zusammen?

Wie soll das gehen?
Die Module "leben" ja, entwickeln sich weiter. Manchmal unter der Haube, aber manchmal mit inkompatiblen Änderungen bzw Ändeurngen, die dazu führen dass die xml neu gebaut werden muss.

gerade mit Platform.io geht die dependency verwaltung an sich wahnsinnig Elegant und plattformübergreifend.

ja, und es gibt so Sachen wie submodules oder subtree, aber das hat für unsere Bedürfnisse nicht gepasst. Das auszuführen, führt zu weit. Aber wir haben das nicht leichtfertig so entschieden, sondern bewusst.

[MAKERWOLF]

Wie soll das gehen?
Die Module "leben" ja, entwickeln sich weiter. Manchmal unter der Haube, aber manchmal mit inkompatiblen Änderungen bzw Änderungen, die dazu führen dass die xml neu gebaut werden muss.

Jetzt hab ich nochmal die dependencies.txt angeschaut, und gesehen, dass die tatsächlich unterschiedliche Versionen verwenden. Bei Platformio kriegt man das ja alles nicht mit, aber ich versteh jetzt warum es vorteilhaft ist, jedes Projekt in einen eigenen Ordner zu tun 😅

ja, und es gibt so Sachen wie submodules oder subtree, aber das hat für unsere Bedürfnisse nicht gepasst. Das auszuführen, führt zu weit. Aber wir haben das nicht leichtfertig so entschieden, sondern bewusst.

Also wegen mir kannst du das gerne ausführen, mir ist ja klar, dass ihr die Dinger aus gutem Grund so macht. Nur ist der für euch Offensichtlich, und für mich noch ein großes Rätsel Ich mein das ja auch nicht als Angriff und erwarte entsprechend auch keine Rechtfertigung, ich möchte nur das große Ganze besser verstehen.

[mumpf]

Der Punkt ist, dass wir modular sind, aber die ETS nicht. Die will am Ende immer eine ETS-Applikation zusammengebaut haben, mit nur einem Namensraum für alle Objekte, eindeutigen IDs für jedes UI-Element und keinerlei der üblichen Abstraktionselemente normaler Programmiersprachen.
Unsere Module bestehen immer aus Firmware (klassische Software-Klassen in C++) und die dazu passenden Stückchen ETS-Applikation, mit eigenen Abstraktionsverfahren.
Damit ist unser OpenKNX-Projekt nicht ein klassisches Softwareprojekt, wir (damals eigentlich ich) mussten uns durch Try & Error an die ETS herantasten und ich musste die Infrastruktur, die aus unseren Modulen eine ETS-Applikation macht, komplett entwickeln (incl. Key-Eindeutigkeit, Versionsüberprüfung. Das ist der OpenKNXproducer. Und der setzt eine gewisse Verzeichnisstruktur voraus. Wir sind einfach dabei geblieben, submodules oder subtree hätten zum Einen Änderungen am Producer erfordert und zum Anderen einen höheren Aufwand, die submodules/subtrees zu verwalten. Beides wollten wir nicht, vor allem, weil wir sowieso kein "normales" Softwareprojekt haben.

Das ist einfach der Stand der Dinge. Er unterstützt verschiedene Arbeitsweisen, ich arbeite durchaus anders als Ing-Dom, aber es funktioniert ebenso.

Aber warum aus 1.3 jetzt 18 machen?

Nein . Du sollst aus 1.3 eine 1.2 machen. Man muss derzeit noch wissen, wann man die interne ETS-Applikationsversion verwendet oder unsere menschenlesbare Form. Hier stehe die Konvertierung.

18 (Dezimal) ist 12 (Hex) ist 1.2 als ETS-Version. Der Producer unterstützt aber auch die dezimale Notation, insofern war die 18 auch ok.

Gruß, Waldemar

[MAKERWOLF]

Danke, jetzt bin ich gscheiter! 🤗

18 (Dezimal) ist 12 (Hex) ist 1.2 als ETS-Version. Der Producer unterstützt aber auch die dezimale Notation, insofern war die 18 auch ok.

Ach du heilige 🙈 Frei nach dem Motto, warum einfach, wenn's kompliziert geht 😂
Ich bin ja ein ganz großer fan der modernen Jahr.monat.subversion Versionsnummer. Da weiß man immer klar woran man ist. Nicht dass es in diesem Fall was hilft oder man etwas daran ändern könnte, schon klar 😅

Danke für eure harte Arbeit! Ich sehe durchaus, dass der Spaß nicht an einer Hand voll Wochenenden entstanden ist 🚀

[Noschvie]

MAKERWOLF vielleicht kannst du dem wiki ein How-To für den Einstieg in OpenKNX Welt hinzufügen? Leicht scheint dieser ja nicht zu sein...

[MAKERWOLF]

MAKERWOLF vielleicht kannst du dem wiki ein How-To für den Einstieg in OpenKNX Welt hinzufügen? Leicht scheint dieser ja nicht zu sein...

Ja ich hab das schon im Hinterkopf, aber zuerst muss ich selbst mal die Füße vom Boden bekommen 😉
Und es ist schon auch so, dass ich den maximal schwierigen Weg zum Einstieg gewählt hab, nicht, dass da jetzt ein falscher Eindruck entsteht.

[starwarsfan]

Hallo miteinander

Ich bin ja ein ganz großer fan der modernen Jahr.monat.subversion Versionsnummer. Da weiß man immer klar woran man ist.

Naja, da kann man auch geteilter Meinung sein. Aber zumindest wäre diese Variante dann schonmal sauberes SemVer...

[traxanos]

Frei nach dem Motto, warum einfach, wenn's kompliziert geht

bei der ets gibt es nur 8bits für versionen also 255. dann ist ende. diese wird im xml aus so angeben. die ets erteile dann die version je je 4 bits. somit sind auch wünsche nach jahr oder semver obsolete.

du darfst auch nicht einfach unsere xml anpassen und importieren. wer für die etc was machen möchte muss extrem background wissen haben, sonst kannst du dir echt ein ei ins nest legen.

also eigentlich sollte man selber keine ets dateien generieren falls man nicht weis was man tut. du kannst dir damit auch echt was kaputt machen.

willst du nur die hardware (firmware) bauen ist eine anpassung nicht nötigt. und dieser version check soll versehentliches bauen von inkompatiblen firmwares verhindern. und man sieht ja hier, dass es das auch getan hat.

[MAKERWOLF]

bei der ets gibt es nur 8bits für versionen also 255. dann ist ende. diese wird im xml aus so angeben. die ets erteile dann die version je je 4 bits. somit sind auch wünsche nach jahr oder semver obsolete.

du darfst auch nicht einfach unsere xml anpassen und importieren. wer für die etc was machen möchte muss extrem background wissen haben, sonst kannst du dir echt ein ei ins nest legen.

also eigentlich sollte man selber keine ets dateien generieren falls man nicht weis was man tut. du kannst dir damit auch echt was kaputt machen.

willst du nur die hardware (firmware) bauen ist eine anpassung nicht nötigt. und dieser version check soll versehentliches bauen von inkompatiblen firmwares verhindern. und man sieht ja hier, dass es das auch getan hat.

Danke für die Info! Das hilft mir sehr weiter das große Ganze zu verstehen! Das ist gerade das einzige worum es mir geht. Klar würd ich Zukunft gern Hardware und Firmware bauen, aber mir war schon relativ schnell klar, dass ohne "extremes Background Wissen" hier wenig zu holen sein wird. Deshalb ja auch der Steile weg den ich mir ausgesucht hab 😅 Auch wenn der zugebenerweise phasenweise steiler ist, als ich mir erhofft hab, aber ich kau mich durch!

Letzten Endes will ich verkabeltes Smart Home und Open Source, und so wie ich das gerade sehe gibts da ausser OpenKNX sowieso nichts. Wenn ich weiß, dass es ob ich will nur 8 Bits für die Versionen gibt, dann hab ich damit kein Problem. Wenn ich es nicht weiß, laufe ich gegen eine Wand 😂

[gbglace]

Kleinern Lernschritt den Du noch gehen solltest hier im Forum.

Zitat ist keine Antwort, findet man so auch nicht im Duden usw.

Und Vollzitate als direkte Reaktion eines Beitrages ist gegen die Forenregeln.

Einfach nach unten scrollen ins weiße Feld tippen und dann den grünen Antwort Knopf drücken. Einfach auf Zitat drücken ohne Textkürzung/Entfernung ist irgendwann Ignoranz und Faulheit.

[traxanos]

vielleicht noch ein hinweis, solltest du eigene ets apps bauen, dann nutze eigene id. wir haben uns mal darauf geeinigt das der bereich 0xAF (in der XML OpenKnxId="0xAF") von uns nicht für öffentliche knxprods genutzt wird. so solltest du also keine kollisionen haben.

[MAKERWOLF]

Und Vollzitate als direkte Reaktion eines Beitrages ist gegen die Forenregeln.

Ich werd die Forenregeln sicherheitshalber nochmal durchlesen, das war mir tatsächlich nicht bewusst. Sorry!

Einfach auf Zitat drücken ohne Textkürzung/Entfernung ist irgendwann Ignoranz und Faulheit.

Es ist eine Gewohnheit, weil eigentlich alle modernen Foren-Softwares das heutzutage automatisch einkürzen und nur herausstreichen, dass es eine Antwort darauf ist. Ganz bestimmt keine Faulheit, und dank Unwissenheit kann ich auch die Ignoranz ausschließen. Ich war wirklich schon lange nicht mehr aktiv in so einem Foren-Dinosaurier unterwegs. Hab den Wink verstanden und mache es in Zukunft besser 🤗

vielleicht noch ein hinweis, solltest du eigene ets apps bauen, dann nutze eigene id. wir haben uns mal darauf geeinigt das der bereich 0xAF (in der XML OpenKnxId="0xAF") von uns nicht für öffentliche knxprods genutzt wird. so solltest du also keine kollisionen haben.

Danke! Sehr gute Info! Wenn ich mich da ran wage werd ich aber denk ich gleich einen begleitenden Thread aufmachen 🤔