OpenKNX-Applikation verkleinern und mit weniger Modulen selber bauen

[Techi]

Noch eine Frage,
wie entferne ich am besten die OFM's die ich überhaupt nicht in der OAM eingebaut haben möchte ?
Ich weiß man könnte die einfach ignorieren oder mittlerweile in der ETS ausblenden aber ich hätte gerne einfach eine möglichs minimalistische Version ohne Module die ich auf der Hardware nie brauchen werde. Ich bin da Minimalist und mag es einfach nicht wenn da Software im System rumdümpelt die das garnix verloren hat.
Das ist bei mir so wie wenn man ne jukende Stelle hat wo man nicht zum kratzen rann kommt

[coko]

Kaum geschrieben und jetzt hab ich's gefunden.
Die "RaumController.conf.xml" war mit der "OAM-Haupt-XML" gemeint, kaum hab ich dort die Versionen angepasst, schon läufts.

Vorsicht: Falls Du die damit erzeugte knxprod in die ETS importiert, dann wirst Du damit Probleme produzieren!

Wenn Du die so erzeugte Firmware mit der offiziell Releasten ETS-App verwenden willst, dann passt das Speicherlayout nicht mehr...

[Techi]

Ich musste doch die Version entsprechend anpassen, da die OFMs von DFA und LOG eine neuere Version hatte
und ausserdem wurde die .knxprod doch nun auch gleich neu mit gebaut ?

Was wäre denn dann die richtige Lösung für das Versionsproblem gewesen ?

[coko]

wie entferne ich am besten die OFM's die ich überhaupt nicht in der OAM eingebaut haben möchte ?

Kurzfassung, bevor Du Dich in Unglück stürzt: Im selben OAM gar nicht!

Andere Modul-Zusammenstellung nur mit eigenem OAM mit anderer Id und auch da nicht einfach irgendeine. Einen Migrationspfad gibt es bei einem solchen Wechsel auch nicht. Und der Ressourcenbedarf von inaktiven Modulen ist unproblematisch, vor allem im Vergleich zur komplett separaten Pflege.

[Techi]

Ok, ich nehm das OAM ja quasi nur als Gerüst wo halt schon jeweils ein Sensor mit drinne ist den ich jeweils eh brauche. Es kann am Ende ja auch anders heissen und wie schon erwähnt es soll (auch in der ETS App) so schlank wie möglich werden, wirklich nur mit dem notwendigsten.

[mumpf]

Techi Ich werde die v1 reparieren, wenn ich wieder zu Hause bin, ich hab leider in den falschen Branch gepushed.

Ansonsten gilt das, was coco geschrieben hat: Die ETS ist sehr restriktiv, was kompatibel sein kann. Solltest Du versuchen, unterschiedliche Modulkombinationen als gleiches OAM zu compilieren und dann auch noch zu importieren, machst Du Dir Dein Projekt kaputt. Wenn das ginge, würden wir das anbieten, anstatt uns die Mühe zu machen, große Applikationen zu bauen, bei den wir einen irren Aufwand treiben müssen, damit sie kompatibel bleiben.
Wie coco schon geschrieben hat, ist der Ressourcenverbrauch zu vernachlässigen, in Zukunft wird er voraussichtlich noch geringer, wir arbeiten ja weiterhin dran.
Solltest Du wirklich verschiedene Applikationen bauen wollen, kannst Du das versuchen, aber es ist ein Heidenaufwand, für die Kompatibilität zu sorgen. Wir können da nicht darauf achten, weil wir Deine Kombinationen nicht kennen.
Das wird darin enden, dass Du frustriert keine Updates mehr machst, weil Du keine Lust hast, alles neu einzugeben. Oder Du arbeitest Dich so weit in das XML ein, dass Du alle Abhängigkeiten verstehst. Das geht, hab ich auch geschafft, ich wusste nach 2-3 Jahren schon um die 90%, die letzten 2 Jahre kamen dann nur noch punktuell neue Erkenntnisse. Einfacher ist es, die Sachen, die man nicht braucht, einfach auszublenden.

Gruß, Waldemar

[coko]

die Version entsprechend anpassen, da die OFMs [...] eine neuere Version hatte [...]

Was wäre denn dann die richtige Lösung für das Versionsproblem gewesen ?

Zum Bau einer eigenen (Applikationskompatiblen) Firmware: Nicht den Branch Restore vewenden, sondern die exakten verwendeten Modulversionen wiederherstellen. Damit hättest Du die Warnung gar nicht bekommen, weil dann die Versionen zueinander passen.

Nur der Vollständigkeit halber: Ein manuelles Downgrade auf die passenden Modul-Version nach Relase-Tag wäre ggf. auch möglich, aber das ist nur praktikabel wenn Du genau weist, welche Abhängigkeiten sich noch verändern dürfen und welche nicht.

Ansonsten siehe auch noch mal https://knx-user-forum.de/forum/proj...61#post2065361 Welches Ziel willst Du erreichen?

und ausserdem wurde die .knxprod doch nun auch gleich neu mit gebaut ?

Und genau das ist ein Problem: Du erzeugst damit eine, sogar sehr deutlich, abweichende knxprod mit identischer Applikations-Id und Version. Bei Nutzung in Deinem ETS-Projekt passieren dann schlimme Dinge, möglicherweise, ohne dass Du das es merkst, bevor es zu spät ist. Also auf keinen Fall machen!

[coko]

das OAM [...] als Gerüst wo halt schon jeweils ein Sensor mit drinne ist [...] es soll (auch in der ETS App) so schlank wie möglich werden

Mehrere verschiedene Applikationen sind mit Blick aufs ETS-Projekt das Gegenteil von Schlank. Jede im Projekt verwendete Applikation und Version wird Teil des ETS-Projekts. Egal, ob Du eine oder 100 Geräteinstanzen hast. Viele verschiedene Applikationen sorgen also dafür, dass das Projekt größer und damit tendenziell langsamer wird. Sehr große Applikationen werden zwar auch träge, aber schon im eigenen Interesse achten wir darauf, dass das im Rahmen bleibt. (Beispiel: Bei der StateEngine hatte ich aus diesem Grund vor dem ersten öffentlichen Release sogar noch die Dimensionierung verkleinert...)

Es kann am Ende ja auch anders heissen

Einfach umbenennen funktioniert nicht. Damit würdest Du sogar noch Nebeneffekte verursachen.

[traxanos]

Auch wenn das nicht jeder gerne hören möchte. Die ETS ist nicht dafür gebaut worden das jemand frei Applikationen zusammen baut nach seinen Wünschen und diese Importiert. Man muss auf sehr viele Sachen achten. Ich kann auch nur davon Abraten einfach mal ein OAM von uns zu clonen und daran Anpassungen für die ETS vorzunehmen. Damit kannst du dein komplettes Projekt zerstören inkl. neuer Projekte (Produktdaten projektneutral gespeichert werden).

Auch wenn wir alles OpenSource machen, und jeder theoretisch alles selber compilieren kann, muss man einfach sagen die ETS für sowas nicht entwickelt worden und kann nicht eben das Projekt für sich individualisieren.

[Techi]

Ich will halt kein fertiges OpenKNX Projekte verwenden sondern ganz spezifische Funktionen von ganz spezifischen Geräten abbilden und ich bin dabei ein Freund von Minimalismus. Also eine möglichst schlanke Firmware die nur genau das macht was sie soll und keinen Strich mehr (und dabei noch möglichst klein und im Source übersichtlich ist). Am besten eine main.c und ein main.h. ein paar Libs und fertig.

Wenn ich eine eigene ETS Applikation baue dann kann ich ja irgendeine ID dafür verwenden, nachdem ich nicht Mitglied der KNX Asi bin ist das ja eh nichts offizielles und es gibt immer das Risiko das es Überschneidungen gibt also such ich mir irgendeine ID selbst aus, so lange ich keine bereits verwendete ID einer anderen App erwische ist doch alles gut.

[Techi]

...
Einfach umbenennen funktioniert nicht. Damit würdest Du sogar noch Nebeneffekte verursachen.

Irgendwie muss man ja anfangen und dazu verwende ich halt üblicherweise eine schon funktionierende Vorlage um schneller rein zu kommen.

[willisurf]

Ich will halt kein fertiges OpenKNX Projekte verwenden sondern ganz spezifische Funktionen von ganz spezifischen Geräten abbilden und ich bin dabei ein Freund von Minimalismus

Ist wahrscheinlich in einem eigenen Thread übersichtlicher

[henfri]

Ich will halt kein fertiges OpenKNX Projekte verwenden sondern ganz spezifische Funktionen von ganz spezifischen Geräten abbilden und ich bin dabei ein Freund von Minimalismus. Also eine möglichst schlanke Firmware die nur genau das macht was sie soll und keinen Strich mehr (und dabei noch möglichst klein und im Source übersichtlich ist). Am besten eine main.c und ein main.h. ein paar Libs und fertig.

Dann ist dies vielleicht eher etwas für dich
https://github.com/thelsing/knx

[Techi]

Ist wahrscheinlich in einem eigenen Thread übersichtlicher

Ja, da hast du vollkommen recht, ich mach dann bei Gelegenheit einen eigenen Thread auf.
Sorry fürs stören, war so gar nicht gewollt.

[mumpf]

Ich hab noch ein paar Anmerkungen hierzu :

• Du kannst das machen, aber bitte nicht veröffentlichen - oder zumindest klarstellen, dass es keine OpenKNX-Applikation und Firmware ist
• nur main.cpp und main.h wird nix. Aber Du kannst aus der Haupt-XML (dass Du ja schon gefunden hast) Module entfernen und entsprechend in der main.cpp diese nicht instanzieren.
• Du musst für JEDE Modul-Kombination eine eigene Applikations-ID wählen, um einigermaßen sauber in der ETS zu bleiben
• Du solltest Deine Applikations-IDs im Bereich 0xF000 bis 0xFFFF, das nutzen wir auch für unsere internen Tests - in dem Bereich werden wir auf keinen Fall was ausliefern.
• Wenn Du Updates von uns einspielen willst, musst Du passend neu bauen und entsprechend ApplicationVersionund ReplacesVersions kompatibel hochzählen, dann hast Du zumindest eine Chance, dass die Applikationen kompatibel bleiben.

Die Frage ist, was Du erreichen willst. Wenn Du Dir die Arbeit mit den obigen Punkten machst, erreichst Du erstmal nur minimal mehr als das, was wir neuerdings mit dem Ausblenden der Module bieten: Mehr Übersichtlichkeit.
An Ressourcen hast Du noch kaum Einsparungen gemacht. Willst Du Ressourcen sparen (warum?), musst Du das Speicherlayout und die KO-Vergabe neu machen. Dann verlierst Du aber jegliche Update-Möglichkeit von neuen Releases unsererseits. Eine Zeit lang wird ein manueller Abgleich möglich sein, wenn wir aber nochmal so was großes wie den RaumController machen, bei dem das Speicherlayout komplett neu gemacht wurde, wird es schwer bis unmöglich.

Musst Du wissen, Du kannst ja scheinbar programmieren und wirst das wohl auch hinbekommen - aber es ist wirklich nur eine philosophische Betrachtung, ob es besser ist, bestimmtes Coding auf dem Mikrocontroller zu haben, dass nicht aufgerufen wird und das somit keine Auswirkungen hat, oder dass dieses Coding gar nicht da ist und es deswegen keine Auswirkungen hat.

Ich persönlich finde, dass wir einen großen Schritt Richtung Übersichtlichkeit und Benutzerfreundlichkeit gegangen sind, indem wir es erlauben, alle Module, die nicht benötigt werden, auszublenden. Diese werden weder parametrisiert noch ausgeführt (das ist im derzeitigen Release noch nicht perfekt, aber wir arbeiten daran, es zu verbessern). Wenn Du wirklich auch das Coding weg haben willst, dann ist das Deine Sache - ich kann nur abraten.

Gruß, Waldemar