Addon Generierung automatisieren

[FUEL4EP]

Hallo Addon-Experten,

das händische Erzeugen der notwendigen Dateien für Addons, insbesondere der 'src/addon/install-*' und 'src/addon/uninstall-*' Shell-Skripte, ist fehleranfällig und mühselig.

Frage: Nutzt ihr dafür Generatoren? Wenn ja welche?

Habt ihr dafür schon mit XML und XML Schemas gearbeitet?

Ich bin gerade dabei, die 'src/addon/install-*' und 'src/addon/uninstall-*' Shell Skripte aus XML mittels eines Groovy-Skripts zu generieren.
Habt ihr dafür vielleicht bereits fertige Lösungen?

[jp112sdl]

Hmm, also meine 55 Installskripte sind alle von Hand erstellt.

Natürlich nehme ich mir als Grundlage immer ein bestehendes Skript als Vorlage.
Die Uninstall-Skripte erstelle ich immer gleich parallel - sobald ich z.B. eine Übersetzung im Install einfüge, kommt das Entfernen gleich mit ins Uninstall.

Fehler sind mir eigentlich noch keine unterlaufen.
Ich glaub es war 1x wo ich schnell eine Fix-Version nachgeschoben hab.
Ist bei 81 Releases ein guter Schnitt, würde ich sagen.

Ansonsten hat sich das Vorgehen bei mir etabliert.

Da es so unterschiedlich ist - mal braucht man Anpassungen in der elvST-Sektion der webui.js, mal nicht.
Gleiches trifft auch auf die stringtable_de.txt oder translate.lang.stringtable.js zu. In seltenen Fällen betrifft es auch die translate.lang.extension.js

Keine Ahnung, wie man das alles automatisieren könnte/sollte.
Da ist wohl mehr Zeit in das Bauen eines Automaten gesteckt, als in ein neues install-Skript

[FUEL4EP]

Hi Jérôme ,

danke für Dein Antwort.

Sobald ich was Brauchbares habe, werde ich es hier kurz vorstellen. Ich werde erst mal die Sektionen

webuiInsert*
/www/config/stringtable_de.txt
translate.lang.stringtable.js

automatisiert erzeugen. Ein Beispiel-XML File und das zugehörige XSD File (zur Syntaxvalidierung) (AsksinPP_addon_control_file.xsd.txt, .txt entfernen) sind angehängt.
Ich nutze den XML Copy Editor (xmlcopyeditor) für das Erzeugen und Validieren der XML-Dateien.
Mit Groovy geht das erzeugen eines Text-Files aus der XML Datei relativ einfach, z.B. sind hier Beispiele. Der angehängte Groovy Skript 'AsksinPP_addon_generator.groovy.txt' (.txt vor Ausführung entfernen) zeigt den einfachen Zugriff auf die definierten XML Elemente. Daraus nun die Shell-Skripte zu erzeugen, ist ziemlich gradlinig und einfach

Update 05. April 2021: Version 0.92 von AsksinPP_addon_generator.groovy:

Der Aufruf 'groovy AsksinPP_addon_generator.groovy ' im Terminalfenster erzeugt dort z.Z. nach Eingabe der XML Steuerdatei 'HB-UNI-Sensor1-AQ_BME680_addon_control.xml' den Install-Skript 'install_hb-uni-sensor-AQ-BME680.txt' (.txt entfernen, nur fürs Hochladen ins Forum notwendig) und den den Uninstall-Skript 'uninstall_hb-uni-sensor-AQ-BME680.txt' (.txt entfernen, nur fürs Hochladen ins Forum notwendig).
Install- und Uninstall-Skripte lassen sich damit automatisch erzeugen.

Die gründliche Verifikation des Generator-Skripts und der erzeugten Install- und Uninstall-Skripten steht noch aus.
In einer ersten Verifikation habe ich allerdings einige Fehler in den früher händisch erzeugten Install- und Uninstall-Skripten gefunden

P.S.: Ich bin noch Groovy - Novize und erhebe nicht den Anspruch alles perfekt 'groovy'-like programmiert zu haben
Groovy - Programmieren macht aber definitiv Spaß, wenn man sich mit ein paar Eigenheiten vertraut gemacht hat, die in Groovy anders sind.

[jp112sdl]

Aufgrund der zunehmend langsamer werdenden Addon-Installation hab ich sie nun bis auf ganz wenige Ausnahmen (eigentlich nur noch die DEVDB) auf patch umgestellt.
Das Einfügen der Addon-spezifischen Inhalte mit sed ist sehr zeitraubend (Datei öffnen - prüfen ob Zeile schon drin - Zeile einfügen - Datei schließen).

Die Orientierungspositionen für patch sind so gewählt, dass sie möglichst CCU FW unabhängig sind, also dort wo sich lt. OCCU in den letzten 4-6 Jahren nichts verändert hat.

Übrig geblieben ist dann in der jeweiligen Geräte-install_* Datei nur noch das Hinzufügen zur DEVDB (siehe z.B. https://github.com/jp112sdl/JP-HB-Devic ... i-sen-temp).
Diese Datei ist ohnehin sehr klein; zudem ist das Patchen des Einzeilers blöd, da sich dort in jeder CCU FW Version was ändert.

Auf meinem Raspberry Pi Testsystem mit (sicher nicht der schnellsten) SD-Karte ergeben sich dabei folgende Zeiten:

• alte Methode mit sed: 2m 36.65s
• neue Methode mit patch: 0m 28.73s

Aktuell bin ich noch am Testen einiger Szenarien, aber in den nächsten Tagen wird dann die V 5.0 veröffentlicht.

[FUEL4EP]

Hi Jérôme,

danke für Deinen Hinweis, dass Du die Struktur der Addons einfacher und schneller machen wirst. Einfacher ist immer besser

Ich schaue mir das gerne in Ruhe an.

Beim ersten Überfliegen ist mir nicht klar, wie die Übersetzungen eingepflegt werden.

Ist mein Verständnis korrekt, dass prinzipiell dieselbe Ergänzungen der relevanten CCU/RM Steuerdateien vorgenommen werden, nur wird patch statt sed dafür verwendet?

Gibt es das neue Environment schon wo zum Anschauen?

[jp112sdl]

Bisher hat jede install-Routine die für das Gerät benötigten Übersetzungen mitgebracht.
Zeile für Zeile.

Nun wird 1x der komplette Block an Übersetzungen (für alle Geräte) auf einmal mit patch eingepflegt.
https://github.com/jp112sdl/JP-HB-Devic ... #L286-L505

Das hat auch den Vorteil des besseren Überblicks. Bei der Vielzahl an Geräten bei mir hatte ich schon keine Ahnung, welche Übersetzung man evtl. aus einem anderen Gerät bereits nutzen könnte, oder ob dies und jenes schon drin ist.

Gibt es das neue Environment schon wo zum Anschauen?

Ja, hier im dev_V5.0 Branch https://github.com/jp112sdl/JP-HB-Devic ... e/dev_V5.0

Viel hat sich eigentlich nicht geändert, außer dass eine Hand voll Patchfiles dazugekommen sind und die (un)install_* Dateien kleiner geworden sind.

===

Auch die Update-Prozedur hat sich geändert.
Während es bisher so war, dass ich bei einem Addon-Update erstmal alle jemals erstellten/möglichen Patche zurückgerollt habe (á la "irgendeins wird schon passen") wird nun nach dem Hochladen das Addon erstmal ins "jp-hb-devices-addon-new" Verzeichnis entpackt.
Das Startskript schaut dann, ob es ein -new Verzeichnis gibt, rollt dann nur die aktuellen Patche aus einem bestehenden Addon-Verzeichnis zurück und patcht dann neu.

Klingt vielleicht etwas verwirrend... kann's aber auch grad nicht anders beschreiben ^^

[FUEL4EP]

Danke Jérôme, nun verstehe ich Deinen neuen Ansatz (besser).

Ich gehe mal davon aus, das der 'alte' und Dein 'neuer' Ansatz interoperabel sind und koexistieren können. Du hast 'nur' eine deutlich bessere und einfachere Methode erfunden, um Konfiguationsdateien der CCU/RM zu ändern.

[jp112sdl]

Ich denke, das sollte problemlos gehen, da die alte Routine, wie du oder Tom sie verwenden, immer nur oben anfügen.

[FUEL4EP]

Hallo Zusammen,

unter AsksinPP_addon_generator.groovy könnt ihr die erste Version (V0.92) eines Generators zur automatischen Generierung der 'Install' und 'uninstall' Skripte eines Addons finden.

Basierend auf einer XML Konfigurationsdatei (hier das Beispiel des HB-UNI-SENSOR-AQ-THPD-BME280 Sensors):

wird der 'install' und der 'uninstall' Skript automatisch erzeugt. Die unterstützte Syntax ist bisher auf einfache Sensoren beschränkt. Für meine 'einfachen' Sensoren reicht das völlig.

Weitere Beipiele sind hier zu finden.

Alle 'install' und 'uninstall'-Skripte der neuen Version V1.7 des Addons hb-ep-devices-addon wurden damit erzeugt.

Damit lassen sich die 'install' und 'uninstall'-Skripte wesentlich einfacher und weniger fehleranfällig erzeugen.

Derivate mit weniger Datenpunkten lassen sich damit einfacher erzeugen.

Die 'install' und 'uninstall'-Skripte sind noch für die 'alte' 'sed'-basierten Skripte, die bisher alle Addons verwendet haben.
Grundsätzlich lässt sich die gewählte Generatormethode auch auf die 'neue' 'patch'-basierte addon Methode, die Jérôme diese Woche vorgestellt hat, anwenden, um die 'patch'-Dateien zu erzeugen.

Wie Jérôme schon schrieb, sind die 'alte' und die 'neue' Addon Methoden miteinander kompatibel und interoperabel. Die alte Methode ist sicher noch sinvoll, wenn ihr ein Addon für wenige Geräte machen wollt. Bei >>10 HomeBrew Geräten macht sicher Jérômes neuer Patchansatz Sinn.

Der Vorteil des Generators besteht darin, dass die Datenatome nur einmal in der XML Konfigurationsdatei definiert werden. Durch den groovy-Skript werden dann die Zielskripte durch 'umformatieren' erzeugt. Dadurch wird nichts vergessen und die Daten sind immer konsistent.


Falls ihr Vorschläge zur Erweiterung des Generatorskripts habt, lasst es mich hier wissen.

[jp112sdl]

Alle 'install' und 'uninstall'-Skripte der neuen Version V1.7 des Addons hb-ep-devices-addon wurden damit erzeugt.

Warum muss man denn die 1.6 deinstallieren, bevor man die 1.7 installiert?