:: fischer-net.de

Wie bereits in anderen Beiträgen berichtet, räumen wir zur Zeit FHEM etwas auf. Dabei geht es im Wesentlichen um die "Struktur" innerhalb der FHEM-Installation. Wurden zuvor alle Dateien einfach in das Modul-Verzeichnis gesteckt (also alle Module, gemischt mit den Dateien für die WebGUI PGM2), soll dies künftig aufgeräumter erscheinen. Den ersten Schritt in diese Richtung habe ich mit der aktuell noch in FHEM verfügbaren update-Funktion über den Befehl updatefhem umgesetzt. Dieser Befehl wird jedoch in der nächsten FHEM Version durch den neuen Befehl update abgelöst.

Viele FHEM-Anwender wissen vielleicht gar nicht, dass FHEM bei der Installation über das Makefile zwei Varianten anbietet: Die Installation mit der WebGUI PGM2 über den Aufruf von "make install-pgm2" oder eine reine Konsolen-Variante über den Aufruf von "make install". 

Hatte der Anwender bei der Installation also bewußt auf die WebGUI verzichtet, dann wurde ihm diese bei einem Aufruf von updatefhem wieder "untergeschoben". Es galt also für die neue Update-Funktion unter anderem auch die vom Benutzer gewählte Installationsart zu "respektieren".

Heute (05.07.2012) habe ich die erste einsatzfähige Version des neuen Befehls update fertiggestellt und im testing-Branch hochgeladen. Das Update wird künftig über zwei relevante Dateien gesteuert: Die Datei release.pm (die aktuell auch schon verteilt wird) und eine neue Steuerdatei nach dem Schema controls_<paket>.txt. Aktuell gibt es zwei "Pakete": FHEM und PGM2. Der Anwender hat also künftig die Freiheit zu entscheiden, was er aktualisieren will. Dabei kann durchaus auch eine nachträgliche Installation der WebGUI über den Updatebefehl angestoßen werden.

Die Vorgehensweise über die "Paket abhängige Aktualisierung" habe ich wohl überlegt: Es eröffnet uns (und natürlich letztlich dem Anwender) neue "Pakete" zu schnüren, die dann der Anwender einfach über ein Update "nachinstallieren" könnte. So könnten das z.B. Pakete für unterschiedliche Icons für PGM2, komplett neue WebGUIs oder "was uns auch immer noch einfällt" sein.

Durch die Kombination der Release-Informationen aus der Datei release.pm und der Steuerdateien, bieten sich dem Anwender vollkommen neue Möglichkeiten. Man kann künftig seinen "Updatezweig" selbst festlegen. Legt der Anwender z.B. viel Wert auf eine stabile Version von FHEM, dann werden Aktualisierungen auch nur aus dem stabilen Zweig bezogen. Hier sind dann allerdings nicht mit allzu viel Aktualisierungen zu rechnen; es sei denn es handelt sich um die Beseitigung schwerwiegender Fehler.

Der Anwender hat jedoch auch die Möglichkeit einzelne Dateien gezielt aus dem Entwicklungszweig zu aktualisieren / installieren. Dies kann z.B. nützlich sein, wenn im Entwicklungszweig von FHEM ein Modul für eine neue Technik eingestellt wurde, die der Anwender in seiner stabilen Umgebung nutzen und nicht auf die Veröffentlichung der nächsten stabilen FHEM Version warten möchte.

Und natürlich kann der Anwender auch komplett die "Entwicklungsversion" von FHEM einsetzen, wenn er denn experimentierfreudig ist.

Künftig werden "Upgrades", also eine Aktualisierung auf die nächst höhere Version mit dem neuen Updatebefehl möglich sein. Der Anwender kann also in seiner stabilen Installation bleiben um dann bei der Veröffentlichung der nächsten stabilen FHEM Version automatisch auf diese zu aktualisieren.

Des Weiteren habe ich dem Update-Befehl auch noch ein paar Features wie z.B. die Suche nach Dateien spendiert. Möchte der Anwender ein bestimmtes Modul oder eine bestimmte Datei aktualisieren und kennt nicht den genauen Namen, dann kann er dem Updatebefehl einen Teilstring übergeben und bekommt daraufhin Vorschläge, welche Dateien zutreffend wären.

Der neue Updatebefehl ist aus meiner Sicht vor allem für zukünftige Erweiterungen recht mächtig geworden. Der Anwender hat mehr Möglichkeiten "seine" ideale Installation zu bestimmen. Bevor die neue Updateroutine jedoch veröffentlicht wird, werde ich die Tage noch einen Aufruf an freiwillige Tester in der FHEM Usergroup auf Google-Groups starten.

Wenn ich das Thema "Update" abgeschlossen habe, wende ich mich wieder den Synology-Paketen zu. Da ich meine produktive Synology RS812 nicht "verhunzen" möchte, habe ich mir extra noch eine DS212 zugelegt, die dann (hoffentlich) als native Entwicklungsplattform genutzt werden kann. Somit wäre ich nicht mehr an die Cross-Compile Umgebung gebunden und könnte FHEM auf der Synology mit weiteren (notwendigen) CPAN Modulen ausstatten. Das ist zumindest der Plan ;-)