Viele Modul-Dateien in Update

[rudolfkoenig]

Thorsten moechte HM485 in die "normale" FHEM Distribution einbringen: das ist gut.
Schlecht (bzw. problematisch) ist, dass er ausser den eigentlichen Modulen noch weitere 50 Dateien mitbringt, da er die Aufgabe modular geloest hat.

Das ist erstens problematisch, weil ich in fhemupdate.pm alle seine Verzeichnisse per Hand nachpflegen muss, und zweitens, weil jetzt fuer ein Modul, was von den meisten Anwendern nicht benutzt wird, 50 neue Dateien per update verteilt werden.

Ich wuensche mir, dass wir bei update intelligenter vorgehen, und nur das was benoetigt wird herunterladen, um erstens die Benutzer und zweitens unseren Server zu entlasten, habe aber noch keine konkrete Idee. Wenn ich es richtig sehe, die Probleme bei autoload und bei der dokumentation gilt es zu loesen.

Soll ich diese Dateien auch bevor wir eine Loesung finden, aufnehmen?

[Thorsten Pferdekaemper]

Hi,

mir war nicht so ganz klar, dass die Anzahl der Dateien problematisch ist. Ich habe ein paar Dateien dazu gepackt, die eigentlich nur für Entwickler gebraucht werden. Die könnte ich entfernen oder in eine Zip-Datei packen. Das würde die Gesamtzahl der Dateien auf etwa 30 reduzieren (inklusive der beiden Moduldateien).
Ich könnte noch ein paar weitere Dateien loswerden, wenn ich das ganze etwas umstrukturiere. Dann werden halt ein paar Dateien größer, was ich weniger schön finde als ein etwas strukturierterer Ansatz, aber so schlimm ist das dann auch wieder nicht.

Um das Nachpflegen per Hand zu vermeiden könnte man das auch so umbauen, dass automatisch alles, was in <fhem>/FHEM/lib ist, (rekursiv) automatisch mitgenommen wird. Ich könnte auch damit leben, dass man das auf eine Ebene beschränkt (also nur <fhem>/FHEM/lib/<modulname>/*) und dass man nur Verzeichnisse mitnimmt, deren Namen einem Modul entspricht. D.h. nur Verzeichnisse, zu denen es auch ein nn_<modulname>.pm gibt.

Wenn wir jetzt aber wirklich mal annehmen, dass FHEM so etwas wie ein Hausautomatisierungsbetriebssystem wird, und es früher oder später tatsächlich nicht mehr zu managen sein wird, dann wäre folgendes meine Idee:
Manche Teilprojekte (z.B. das FTUI) stellen schon eine eigene Update-Datei bereit. Dadurch kann man FTUI so installieren und updaten:

Code Auswählen Erweitern


update all https://raw.githubusercontent.com/knowthelist/fhem-tablet-ui/master/controls_fhemtabletui.txt

Könnte man nicht irgendwo zentral in FHEM eine Liste solcher Links anlegen, die dann automatisch beim update mit beachtet werden? Wenn jemand dann ein bestimmtes Modul verwenden will, dann trägt er nur den Link in seine eigene "Registry" ein (z.B. mit einem attr global registry...) und macht ein normales "update".
Der update Prozess würde dann zuerst den update mit allen Dateien machen und danach so Sachen wie comandref_join aufrufen. Mit dem autoload sehe ich nicht unbedingt ein Problem. Man muss halt einmalig die Links für die Dateilisten eintragen und update machen, wenn man einen bestimmten Teil verwenden will.

Wenn man das ganze etwas komfortabler machen will, dann könnte man noch eine Indirektion einführen. Z.B. könnte man auf dem SVN eine zentrale Datei führen, die den Ort der Dateilisten bestimmt. Das würde dann in etwa so aussehen:

Code Auswählen Erweitern


frontend.ftui https://raw.githubusercontent.com/knowthelist/fhem-tablet-ui/master/controls_fhemtabletui.txt
module.hm485 https://raw.githubusercontent.com/.../hm485.txt
...

Dann könnte man zum "Installieren" eines "externen" FHEM-Teils einfach nur z.B. "attr global registry module.hm485 frontend.ftui" schreiben, um die beiden hinzuzufügen.
Der Hit wäre natürlich, wenn man daraus eine Liste mit Checkboxen machen könnte... (SCNR)

Ach ja: Es wäre nett, wenn mir mal jemand erklären könnte, wie diese Dateien erzeugt werden. Dann könnte ich das wenigstens mal für HM485 machen.

Gruß,
   Thorsten

[rudolfkoenig]

Ach ja: Es wäre nett, wenn mir mal jemand erklären könnte, wie diese Dateien erzeugt werden. Dann könnte ich das wenigstens mal für HM485 machen.

controls_fhem.txt wird durch contrib/fhemupdate.pm erzeugt, ich bezweifle aber, dass dieses Programm sinnvoll fuer andere verwendbar ist.
Syntax der controls-Datei:

Code Auswählen Erweitern


MOV <src> <destdir>
oder
UPD YYYY-MM-DD_HH:MM:SS <SIZE> <Filename>
Alle anderen Eintraege werden ignoriert.

MOV wird fuers Umbennen von Dateien verwendet, bzw. z.Zt nur exklusiv, um welche nach unused zu schieben. Mit UPD wird die Datei heruntergeladen, falls der Zeitstempel oder die Groesse nicht mit der alten Version uebereinstimmt. <Filename> muss auf dem Webserver relativ zu der controls Datei liegen, sie wird lokal genauso angelegt.

Könnte man nicht irgendwo zentral in FHEM eine Liste solcher Links anlegen, die dann automatisch beim update mit beachtet werden?

Ich finde die Idee gut. Andere Meinungen?

[viegener]

Generell finde ich die Idee sehr gut, denn ich habe mir ein update script gebastelt, dass FHEM und FTUI und die widgets der Reihe nach updated und zwischendurch noch das Backup abschaltet, da ich nicht für jedes update ein getrenntes Backup brauche 

Ansonsten wäre es natürlich der Gipfel des Komforts, wenn eine gewisse Automatik existieren würde, so dass man bei BENUTZUNG des Moduls auch automatisch updates bekommt. Natürlich gibt es dann das Problem wie benutze ich ein Modul, dass ich noch nicht habe...

Als ersten Schritt wäre aber eine liste von update-links die alle abgearbeitet würden schon ein Fortschritt.

[Risiko]

Die Idee ist schon gut. Ich habe mir deshalb auch update script gebastelt.
Prinzipiell finde ich es aber nicht schön, dass Module an unterschiedlichen Stellen und unterschiedlichen Verwaltungssystemen gehostet werden. Ich hätte es lieber zentral.
Wenn die User nur das installieren was sie brauchen, dann ist das Update auch einfacher (es wird ja nur das geupdatet, was installiert ist.) Meiner Meinung nach müsste man was ab Installationsprozess ändern. Grundinstallation + Pakete für Module.
Weiß natürlich auch, dass das von heut auf morgen nicht getan ist.

[Icinger]

Dann könnte man zum "Installieren" eines "externen" FHEM-Teils einfach nur z.B. "attr global registry module.hm485 frontend.ftui" schreiben, um die beiden hinzuzufügen.

Liese sich das nicht vielleicht aus so lösen, dass beim ersten "define" eines Moduls sich dieses dann selbst in dieses attribut einfügt und gleich mal ein "update xxx" anstösst?

lg, Stefan

[Thorsten Pferdekaemper]

Liese sich das nicht vielleicht aus so lösen, dass beim ersten "define" eines Moduls sich dieses dann selbst in dieses attribut einfügt und gleich mal ein "update xxx" anstösst?

Naja, ich würde gerne zumindest für meine Sachen beim autocreate bleiben. Das würde dann nämlich nicht gehen.
Außerdem würde ich es nicht mögen, wenn FHEM "versteckt" auf's Internet zugreift.
Meiner Meinung nach wäre es vollkommen ok, wenn man das hinzufügen der "Pakete" selbst machen muss. Einen Automatismus fände ich nicht wirklich gut.
Gruß,
   Thorsten

[Icinger]

Außerdem würde ich es nicht mögen, wenn FHEM "versteckt" auf's Internet zugreift.

Gut, das ist ein schlagendes Argument

Alternative dazu wäre vielleicht, ein neues FHEM-Kommando "activate".

Damit könnte man zB vor dem define ein

Code Auswählen Erweitern

activate HM485
absetzen, welches eine spezielle SUB im HM485-Modul aufruft, welches eben dieses attribut setzt und das dazugehörige Update anstösst.

Ich selbst hätte sicher auch kein Problem, ein attrigut manuell zu setzen etc.
Ich sehe nur schon wieder 100te Threads hier im Anfänger-Forum. Ähnlich dem "Ich kann die FHEM-Config nicht mehr editieren" o.ä., die sich dadurch vermeiden lassen würden.

Schönen Sonntag noch,
Stefan

[UliM]

Hallo,
für HMW wäre auch mein Votum, das auf möglichst wenige Dateien zu reduzieren. Es kommen ja bisher alle mit der Dreiteilung in Hardwareanbindung  + Systemspezifische Verarbeitung + Frontend aus. Bisher habe ich nicht verstanden, warum HMW da mehr bräuchte.

Bezgl. Update aus anderen repositories wäre mein Votum die Konzentration in nur ein repository.

Gruß, Uli

[Thorsten Pferdekaemper]

Alternative dazu wäre vielleicht, ein neues FHEM-Kommando "activate".

Damit könnte man zB vor dem define ein

Code Auswählen Erweitern

activate HM485
absetzen, welches eine spezielle SUB im HM485-Modul aufruft, welches eben dieses attribut setzt und das dazugehörige Update anstösst.

Naja, da beißt sich aber die Katze ein bisschen in den Schwanz. Wenn das Modul noch nicht installiert ist, wie kann dann eine SUB aufgerufen werden?
Nein, meine Idee war einfach, dass es im Modul global ein entsprechendes Attribut (oder auch eins für jedes "nachladbare Modul" gibt), welches man setzen kann oder eben nicht.

Ich selbst hätte sicher auch kein Problem, ein attrigut manuell zu setzen etc.
Ich sehe nur schon wieder 100te Threads hier im Anfänger-Forum. Ähnlich dem "Ich kann die FHEM-Config nicht mehr editieren" o.ä., die sich dadurch vermeiden lassen würden.

So wie ich mir das vorstelle wäre das nur ein Klick oder ein Attribut in global. Auch für Anfänger dürfte das auch nicht schwierig sein, zumindest nicht schwieriger, als heute das FTUI oder HM485 zu installieren.
Ich wüsste auch nicht, warum das die fhem.cfg zerschießen sollte. Das könnte höchstens passieren, wenn wir auch eine "deinstall"-Option bereitstellen wollten. Das haben wir bisher aber gar nicht diskutiert.

für HMW wäre auch mein Votum, das auf möglichst wenige Dateien zu reduzieren. Es kommen ja bisher alle mit der Dreiteilung in Hardwareanbindung  + Systemspezifische Verarbeitung + Frontend aus. Bisher habe ich nicht verstanden, warum HMW da mehr bräuchte.

Naja, ob diese einfache Dreiteilung wirklich gut ist oder einfach nur historisch gewachsen ist ein anderes Thema. Meiner Meinung nach fördert das nicht gerade die Wartbarkeit der Module. Aber mal davon abgesehen. Hier sind ein paar Gründe, warum HM485 ein paar mehr Dateien hat:

• Es gibt joweils ein Modul für die Hardwareanbindung (IO-Modul) und eins für die Devices.
• Jedes unterstützte Device hat eine Device-Datei. Dort sind die Spezifika jedes Geräts hinterlegt. Diese werden aus XML-Beschreibungsdateien generiert, die der Hersteller liefert. Man kann auch eigene Geräte entwickeln. Dann liefert man eben selbst die XML-Datei und generiert daraus die FHEM-Device-Datei. Momentan werden 16 Geräte standardmäßig unterstützt, also 16 Dateien.
  Durch dieses Vorgehen unterstützt HM485 automatisch alle Geräte, die es gibt. Wenn neue Geräte dazukommen, dann muss man nirgends in's Coding eingreifen.
• Um nicht nur den eq3-Adapter (ca. 80€) zu unterstützen, sondern auch einfache RS485/Ethernet oder RS485/Seriell Adapter (ca. 12€), gibt es einen Daemon, der den Original-Adapter emuliert. Das ist so ähnlich wie der Daemon, den man sich für den HM-CFG-USB extra installieren und zusammenbauen muss, nur dass er bei HM485 in Perl geschrieben ist und automatisch mit dabei ist. Das Ding wird sogar automatisch von FHEM verwaltet.
  Dieser Daemon ist natürlich eine eigene Datei. Außerdem gibt es ein paar Sachen, die vom Daemon und von den anderen Modulen gemeinsam verwendet werden. Dadurch ist es auch sinnvoll, wenn diese Sachen in getrennten Dateien sind.
• Es gibt ein paar Hilfsprogramme, die zur Fehlersuche gedacht sind und auch zur Weiterentwicklung benötigt werden. (Z.B. das Programm, um die Geräte-XMLs in die FHEM-Gerätedateien zu übersetzen.)
• Das ganze ist inzwischen relativ komplex. Zum Beispiel hat HM485 ein UI, um alle Gerätekonfigurationen zu ändern, inklusive direkte Peerings und deren Konfiguration.

Ich denke, wenn ich ein bisschen daran arbeite, könnte ich das ganze auf ein Verzeichnis unterhalb FHEM/lib und etwa 25 Dateien runterbringen. Allerdings wird das ganze dann etwas unübersichtlich, was ich selbst etwas hässlich finde. Momentan sträube ich mich da noch etwas.
Gruß,
   Thorsten

[Icinger]

Ich wüsste auch nicht, warum das die fhem.cfg zerschießen sollte

Ich meinte nicht, es würde jemanden die config zerschiesse, sondern ich meinte das ganze Thema rund um das "attr editConfig"

Naja, da beißt sich aber die Katze ein bisschen in den Schwanz. Wenn das Modul noch nicht installiert ist, wie kann dann eine SUB aufgerufen werden?

Das Hauptmodul im main-Trunk, der Rest dann irgendwo exterm oder auch in nem eigenen Verzeichniss ala contrib, damit kann genauso eine SUB aufgerufen werden, wie im ersten define. Und diese holt dann eben die restlichen benötigten Files.

[Thorsten Pferdekaemper]

Ich meinte nicht, es würde jemanden die config zerschiesse, sondern ich meinte das ganze Thema rund um das "attr editConfig"

Ich verstehe nicht wirklich, was das mit dem Thema hier zu tun hat.

Das Hauptmodul im main-Trunk, der Rest dann irgendwo exterm oder auch in nem eigenen Verzeichniss ala contrib, damit kann genauso eine SUB aufgerufen werden, wie im ersten define. Und diese holt dann eben die restlichen benötigten Files.

Das halte ich nicht für so geschickt. Das kann dann schnell auseinanderlaufen. Man muss dann ja jedesmal, wenn man etwas ändert, beide Repositories updaten. Ich kann mir vorstellen, dass das schnell zu Problemen kommt.
...oder man hat im Hauptmodul nur noch genau die "Nachladeroutine" und sonst gar nichts. Dann kann man das "Nachladen" aber auch gleich in den Core einbauen.

Ich glaube, dass ich mal irgendwie einen Prototypen zusammenbasteln muss, der das mit dem Nachinstallieren inklusive update mal zeigt, so wie ich mir das vorstelle.

Gruß,
   Thorsten

[viegener]

Ich mag generell einfache Lösungen, die dann schrittweise erweitert und verfeinert werden, deshalb würde ich komplexe Themen (Stichwort commandref, automatisches Nachladen beim define etc) erst nachgelagert machen.

Einfach wäre, wenn man vielleicht mit folgendem anfängt:

Also eine Liste von Updatelokationen, die zentral mit dem jetzigen FHEM-Update geliefert wird
Per Installation werden Updatelokationen aktiviert ("Checkboxes")
Zusätzliche "private" Updatelokationen können manuell eingetragen werden

Vielleicht noch die Einschränkung, dass jede updatelokation nur ihr "eigenes" Verzeichnis ausgehend von einem Wurzelverzeichnis updaten sollte?

[Thorsten Pferdekaemper]

Also eine Liste von Updatelokationen, die zentral mit dem jetzigen FHEM-Update geliefert wird
Per Installation werden Updatelokationen aktiviert ("Checkboxes")
Zusätzliche "private" Updatelokationen können manuell eingetragen werden

Ja, so hatte ich mir das auch gedacht.

Vielleicht noch die Einschränkung, dass jede updatelokation nur ihr "eigenes" Verzeichnis ausgehend von einem Wurzelverzeichnis updaten sollte?

So ganz geht das wohl nicht: Module müssen in <fhem>/FHEM stehen und Erweiterungen für die Oberfläche in <fhem>/www bzw. <fhem>/www/pgm2. Aber ansonsten wäre es wahrscheinlich tatsächlich gut, wenn man den Namen des Wurzelverzeichnis vorgibt. In etwa <fhem>/FHEM/lib/<name> bzw. <fhem>/www/<name>, soweit das möglich ist.
Ich denke aber, das man das per Vereinbarung festlegen kann und nicht technisch. Bevor man dann eins dieser Repositories in die FHEM-Liste einträgt kann man es ja immer noch im Forum prüfen lassen.
Auch dafür würde man ja immerhin noch SVN-Schreibrechte brauchen.

Gruß,
   Thorsten

[viegener]

So ganz geht das wohl nicht: Module müssen in <fhem>/FHEM stehen und Erweiterungen für die Oberfläche in <fhem>/www bzw. <fhem>/www/pgm2. Aber ansonsten wäre es wahrscheinlich tatsächlich gut, wenn man den Namen des Wurzelverzeichnis vorgibt. In etwa <fhem>/FHEM/lib/<name> bzw. <fhem>/www/<name>, soweit das möglich ist.
Ich denke aber, das man das per Vereinbarung festlegen kann und nicht technisch. Bevor man dann eins dieser Repositories in die FHEM-Liste einträgt kann man es ja immer noch im Forum prüfen lassen.
Auch dafür würde man ja immerhin noch SVN-Schreibrechte brauchen.

Ja ich hatte auch eher an eine Vereinbarung im Sinne von: Verändere in gemeinsam genutzten Verzeichnisses nur Deine Dateien und füge für viele eigene Dateien ein eigenes Unterverzeichnis ein, dass nur Dein Update verändert. Und wie immer Ausnahmen bestätigen die Regel