Plugin-System für FHEM

[Florian_GT]

Ein solches Modul gibt es bereits und wird weiter ausgebaut. Nennt sich Installer. Ziel ist genau das, eine Liste der verfügbaren Module welche nicht über FHEM verteilt werden und dann schnell und einfach runtergeladen und sogar definiert werden können.
Man müsste mal Julian fragen wie weit da seine derzeitige Entwicklung und weitere Planung ist.


Grüße

Ich fände es schon eine Hilfe, wenn Entwickler ihre Arbeit im GIT pflegen. Kann ja auch ein Development branch sein.

Ich finde es stört ungemein wenn ich ständig im Forum den jeweiligen Beitrag raus suchen muss für etliche Plugins oder Erweiterungen. Nicht nur Update sondern auch Erst-Installation. Ich glaube dass es da eine große Hürde bei dem Einsatz von Versionierungssystemen gibt. Zumindest war das bei mir vor einigen Jahren so. Heute hilft mir das System ungemein.

[Loredo]

In der Tat keine ganz neue Diskussion. Heikles Thema mit vielen Kontroversen ...
Meinen Standpunkt dürfte man kennen, spätestens mit Markos Verweiß auf meinen FHEM Installer und die FHEM Meta Aktivitäten.


Wie auch richtig erkannt wurde, ist das ein ziemlich dickes Brett. Begleiter sind daher absolut gern gesehen, bisher fehlte es daran. Mir wäre daran gelegen, dass es dann aber auch einen Austausch über die Vorgehensweise etc. geht. Kleinere Patches reviewe ich natürlich gerne, das ist kein Aufwand. Aber größere Änderungen würde ich stattdessen lieber abstimmen. In der Regel kommt bei einem entsprechenden Austausch auch etwas viel besseres zustande, als wenn eine Person alleine was verzapft.


Allerdings ist das Forum für einen schnellen und lebendigen Austausch (EDIT: Für Entwicklung, nicht Pflege/Support!) irgendwie nicht der richtige Ort. Das Forum ist für mich stark Enduser bezogen (neben dem, dass ich das Interface nicht mag).
Gerne als Issues in Github diskutieren oder in unserem inzwischen ja vermutlich eher bekanntem FHEM Entwickler Slack Team (Einladung z.B. von Marko oder mir).




PS:
Ich empfehle einmal jedem den Blick über den Tellerrand und andere Systeme wie ioBroker oder OpenHAB zu installieren und einmal das ein oder andere Modul/Paket/<BezeichnungHierEinfügen> zu konfigurieren. Bei IP-Symcon kann man gar "live" die Modularisierung miterleben. Nur mal als Anregung dazu, was ein modulares System in Sachen Übersichtlichtkeit und Wartbarkeit bieten kann. Ich sage nicht, dass dort alles perfekt ist. Aber eben von der Grundarchitektur deutlich mehr 2000er. An Perl und seinen Unzulänglichkeiten was Prozessskalierung etc. angeht kann man bei FHEM (leider) nix ändern, aber das modulare Konzept gibt es dort auch schon seit Dekaden.

[KölnSolar]

Hmm, dann mal eine der kontroverseren Meinungen.
Ich hab mich über die Jahre daran gewöhnt, dass das Forum Dreh- u. Angelpunkt von FHEM ist. Folglich finde ich jedwede Auslagerung nach GitHub etc. kontraproduktiv. Wie oft hab ich Beiträge gesehen, wie einfach es ist "andere Quellen" ins update einzubeziehen. Mag ja sein, dass das einfach ist, aber ich finde es kompliziert und intransparent.
KernSanis Ausgangspost versteh ich noch. Wenns aber daran geht Regeln festzulegen wird es in der Abgrenzung schon schwierig. Ich bin daher auch seiner Meinung, dass es eher ein Dokuproblem ist. Aber seien wir doch mal ehrlich: ein ausgeklügeltes System wird auch nicht besser genutzt werden. Manche Dinge landen trotzdem in "Codeschnipsel" und werden später vergessen. Trotzdem aber vielleicht von vielen genutzt.

Ich finde es stört ungemein wenn ich ständig im Forum den jeweiligen Beitrag raus suchen muss für etliche Plugins oder Erweiterungen.

Verstehe ich nicht so ganz, daher mach ich mal ein paar Beispiele:
1. Eine meiner Entwicklungen liegt seit einem Jahr brach. 1-2 User beteiligt. In einem FHEM-GitHub braucht das doch kein Mensch, denn es wird schon wieder unübersichtlich. Und in diesem Fall ist das Forum hilfreich, weil ich noch nicht einmal die Hardware habe und dem User immer mal schnell ein Update zum Test in den Thread hänge und er mir die Ergebnisse mitteilt.
2. Module sind im Entwicklungsstadium. Dieses Stadium bedeutet generell viel Kommunikation mit einer Handvoll Usern. Warum soll die auf eine 2. Plattform verlagert werden, zumal man auf der hiesigen doch ständig Support leistet ?
3. Ein Modul ist "verteilfähig". Ich frag mich, warum ab diesem Zeitpunkt nicht jedes update per SVN passiert. Umgekehrt macht man Testversionen, die im Thread auch genau als solche kenntlich gemacht(und je nach Sorgfalt auch wieder gelöscht) werden, die aber doch rein gar nichts in einem Update-Automatismus verloren haben, sondern ausgelöst durch einen Wunsch oder ein Problem individuell zu handhaben sind.
4. Über die commandref kann man sicherlich viel nörgeln. Aber es ist für mich immer wieder Anlass zum "stöbern". Wo stöbert man sonst ? Sie ist für mich also zentrales Informationsinstrument für neue Module. Die modulare commandref, die ich ehrlicherweise mir noch nie angesehen habe, ist da schon kontraproduktiv. Und, wie ich meine es in diesem Thread gelesen zu haben, mir ein System zusammenzuklicken ist doch realitätsfern. Ich wette, so ist kein System entstanden. Entstanden sind die Systeme durch Idee/Gedanken/Ansatz, suche in commandref/wiki/forum, ausprobieren.

Meines Erachtens fehlt es in der commandref nur an weiterer Strukturierung. Aber auch die ist nicht einfach. Ein DLNARenderer ist device-unabhängig und trotzdem Multimedia wie ein Samsung-TV. Alexa etwas anderes als ein echo. Daher auch 2 unterschiedliche "Modulfamilien". Aber welcher User weiß das, wenn er startet ? Wo soll er suchen ? Ist da github wirklich die Alternative ? Dort sehe ich eigentlich immer nur genau das Gegenteil zu FHEM: einzelne-Standalone-Entwicklungen, nichts modulares. Das einzige, wo es aus meiner Sicht Sinn macht, ist z.B. die Signalduino-Entwicklung. Aber da wächst ja auch eine firmware, um device für device.

Genug geschwafelt, wo ich noch nicht mal jeden Post verstanden habe. Und auf KernSanis Ausgangsthema gab es eine einfache aber meines Erachtens treffende Antwort

Hi,
das sind ja alles ganz nette Ideen, aber halt heftigst aufwändig. Ich dachte auch, dass das die Idee hinter dem "FHEM-Installer" Projekt (oder so) ist bzw. war.
Wahrscheinlich wäre anfangs schon viel geholfen, wenn jemand eine Liste machen würde mit FHEM-Teilen, die nicht im üblichen SVN sind. Das könnte man dann ja an prominenter Stelle ins Wiki packen.
Gruß,
   Thorsten

Grüße Markus

[Loredo]

Klar, man kann jetzt wieder hingehen und abermals Informationen in Stein meißeln, bei denen dann wieder keiner die Pflege übernimmt.
Sinn und Zweck der ganzen Meta Geschichte war und ist, dass der Modulautor an zentraler Stelle in maschinenlesbarem und standardisiertem Format sein Modul dokumentiert. Dies ist der META.json Abschnitt.
Der FHEM Installer macht dies zugänglich. Man hat Schlagwortsuche, man kann es um eine Sektion für die Änderungshistorie erweitern, man kann "stöbern" (hast du mal den search-Befehl ausprobiert?), man kriegt gesagt wo in welchem Forum man Support bekommt, man bekommt gesagt, wo der Sourcecode liegt, man bekommt gesagt, welche Software Version man hat (Stichwort 30 verschiedene Stellen im Forum, wo man das mal her hatte...), sogar aus welcher Quelle. Man sieht welche Abhängigkeiten FHEM Module untereinander haben... es fehlt nicht mehr viel, um ein zentrales Verzeichnis zum Auffinden von Drittmodulen zu haben und diese jedes einzeln für sich aus ihrer eigenen Quelle herunterzuladen, inkl. unterschiedlicher Versionsstände ohne lokales Backup, Anzeige der Änderungshistorie, Anzeige über ausstehendes Update, etc. All das ohne ein langes Changelog File, wo ich im Fließtext jede Menge Updates zu lesen kriege über Module, die ich gar nicht verwende und die mich nicht interessieren.


Aber wie gesagt, genau auf solche Diskussionen habe ich gar keine Lust. Wer mitmachen will, der macht eben mit, wer nicht, wird zu nix gezwungen und bleibt bei dem, was er hat. Nur möchte ich mir die Entwicklung nicht dauernd dadurch madig machen lassen, dass hier im Forum eine zu große Öffentlichkeit darüber herscht, was gerade konstruktiv diskutiert wird. Alles andere bringt kein Stück weiter und hält nur auf. Ich brauche das aber auch alles nicht wiederholen, all das ist seit über 5 Jahren hinreichend bekannt.

[KernSani]

Nachdem ich den Thread mit ein paar Gedanken, die mir unter der Dusche kamen angestoßen habe melde ich mich auch mal wieder zu Wort und versuche mal für mich ein Zwischenfazit zu ziehen:
* Installer und Meta habe ich mir in den letzten Tagen ein bisschen angesehen - ich glaube, das ist sehr wertvolle Grundlagenarbeit für das, was sich zumindest einige hier wünschen: Eine zentrale Anlaufstelle zum einfachen Finden von Modulen für einen gewissen Anwendungszweck und eine möglichst "hazzle-free" Installation derselben.
* Bei der Doku gibt es ja auch schon Ansätze das zu integrieren (siehe FHEM 6.0 Thread)
* Wo ein Modul physisch liegt und gepflegt wird ist letztendlich egal, das soll ein Entwickler handhaben wie er will, solange es zentral auffindbar ist - Sinnvoll sind da aus meiner Sicht für mehr oder weniger "stable" Module nur Github oder SVN, in der Entwicklungsphase mache ich das gerne im Forum, aber da habe ich auch nicht den Anspruch, dass es zentral auffindbar und installierbar sein soll. Was ich persönlich - und da bin ich bei Markus/Kölnsolar - gut und wichtig finde, ist ein zentraler Anlaufpunkt für den Support - das bietet aktuell nur das Forum. Mit verteilten Github issues können vielleicht isolierte Probleme von Experten gelöst werden, bei den allermeisten "Problemen" halte ich aber das geballte und übergreifende Wissen der Community für sehr viel zielführender. Ist ein ganz anderes Thema und ich will das jetzt hier auch nicht vermischen, aber vielleicht gibt es ja Ansätze (ich habe ehrlich gesagt keine Ahnung), wie man das Forum mittelfristig in eine dem dritten Jahrzehnt des zweiten Jahrtausends eher gerechte Form bringen kann, ohne das bestehende Wissen (in Form von existierenden Beiträgen aber auch der großen und aktiven Community) zu verlieren
* Was mir noch ein bisschen fehlt - aber da niemand darauf eingeht, scheine ich der Einzige zu sein - ist eine gewisse Qualitätssicherung sicher zu stellen (oder dies zumindest kenntlich zu machen). Mir ist klar, dass das nur rudimentär möglich ist und wir keinen Apple-Store bauen werden, aber im SVN commit finden zumindest ein paar Tests statt, die gewisse Dinge (Mindest-Dokustandards etc...) versuchen sicher zu stellen. Bei Github ist das nicht der Fall. Im Meta-JSON gibt es einen "release status", das hilft aber nur bedingt. Dem Anwender zumindest kenntlich zu machen "hallo, ich komme aus dem SVN, ich habe automatisierte basic Checks überlebt" oder "ich komme aus eine 3rd Party repository, ich erfülle möglicherweise nicht den Anspruch an ein FHEM Modul" halte ich für wichtig (tatsächlich kann ich natürlich in die Commandref schreiben "ich habe keine Doku" und kann es ins SVN einchecken, also ist die Aussagekraft auch nur eingeschränkt).
Fazit: Ich glaube soooo unerreichbar ist das, was ich mir unter einem Plugin-System vorstelle garnicht. Schau mer mal was wir draus machen können...
Schönen Abend!

[KölnSolar]

@Loredo:
Du hast mich missverstanden. Das war nicht die Kritik an Deinem Modul. Das kenne ich nicht und kann es gar nicht beurteilen.(Ich werds mir jetzt aber wohl angucken müssen  )
Den Weg

Ich fände es schon eine Hilfe, wenn Entwickler ihre Arbeit im GIT pflegen. Kann ja auch ein Development branch sein.

Ich finde es stört ungemein wenn ich ständig im Forum den jeweiligen Beitrag raus suchen muss für etliche Plugins oder Erweiterungen. Nicht nur Update sondern auch Erst-Installation.

halte ich für falsch. Schönes Bsp. übrigens, dass der Autor seit 9 Tagen nicht auf die Statusnachfrage zu einem Modulupdate, welches er vor 3 Monaten angekündigt hat, im Forum geantwortet hat.
Du hattest es deutlich anders formuliert

Allerdings ist das Forum für einen schnellen und lebendigen Austausch (EDIT: Für Entwicklung, nicht Pflege/Support!) irgendwie nicht der richtige Ort.

Bei den meisten Modulen halte ich aber auch das für überflüssig, solange nicht mehr als 1 Entwickler daran arbeiten. User zu animieren,  ein issue oder einen request im git zu eröffnen, halt ich für einen Irrweg. Genauso, wenn ein Entwickler in der commandref auf seine private homepage verweist....
(alles geschrieben bevor KernSani seinen letzten Post gemacht hat;und in dem fand ich nichts auf die Schnelle, was ich nicht unterscheiben könnte    )

[M.Schulze]

Hallo,

es geht hier wohl nicht um den Platz auf dem Datenträger oder Transfervolumen für die Synchronisierung.

Interessant wäre es in FHEM.PL eine Möglichkeit einzubauen die Module gezielt aktiviert oder deaktiviert
(unsichtbar macht, nicht verfügbar macht), ohne sie aber vom Datenträger zu löschen.
Das beinhaltet natürlich auch jegliche Hilfe. Idealerweise instant, sofort und nicht erst nach Reboot.

Also z.B. ein optionaler Key,oder eine optionale Key-sammlung in Global,
die dann über Sichtbarkeit und Nutzbarkeit eines Modules / der Module entscheidet. Optional natürlich.

Könnte auch 3-stufig sein: hidden,Modul da-nicht nutzbar, Modul da-nutzbar -> aber auf Datenräger immer da.

Anwendungfall 1:
Ich installiere beim Anwender eine 100% Installation, er soll ein Device-Modul erst sehen wenn er solch ein Produkt hat. Der Key steht auf der Verpackung. Handelt es sich um ein IoT Device könnte es sich auch selbst aktivieren.


Anwendungfall 2:
Ich installiere bei mir eine 100% Installation, sehe bei mir aber nur den Minimalumfang da ich für Geräte die ich nicht habe keinen Key gesetzt habe.
Ich will diese auch nicht sehen sondern erst bei Bedarf aktivieren.


Danach könnte man, auch optional, ein Plugin-Helper entwickeln, das nur die Keys für die Sichtbarkeit managed, und nicht wirklich Dateien installiert.

Umsetzen könnte man das über Dateinamen.

nr?_xx_yyyy_modul.pm

x für das sichtbar-machen von Gruppen / Gerätearten
y für das sichtbar-machen von konkreten Modulen

MFG

[Beta-User]

Habe mir jetzt auch den installer nochmal angesehen (v.a., weil ich im Nachgang zu der Diskussion hier die von Meta genutzten Daten für die MySensors-Module nachpflegen wollte).

Unschön ist, dass man (so ich das richtig verstanden habe) da erst das prereq-irgendwas-Perl-Modul installiert haben muß (was bei mir aus irgendeinem Grund mit dh_make nicht ging, so dass direkt cpan erforderlich war) und dann die Installation weiterer Dinge nur durchläuft, wenn fhem Admin-Rechte hat. Ohne das im Detail durchschaut zu haben, gibt mir das kein gutes Gefühl (sorry, wenn da ein technisches Mißverständnis vorliegen sollte).Die JSON-Struktur selbst ist für mich als "Hobbyprogrammierer" eine Hürde, aber das wird schon irgendwie klappen (es gibt dazu Muster). Worauf ich raus will: Auch das System ist nicht selbserklärend für "Gelegenheitsdeveloper".

Insgesamt wäre meine Tendenz, nicht mehr Wege zu eröffnen, sondern die Mittel konsequent zu nutzen, die eben da sind (was Meta ggf. einschließt!) und dann auch so zu dokumentieren, dass man "developer-noobs" nicht überfordert, weil es zu umständlich/kompliziert... ist.
Einen gewissen Admin-Overhead wird man leider nicht vermeiden können, und m.E. ist es auch sinnvoll, die Vereins-Infrastruktur zu nutzen (ohne die git/svn-Diskussion irgendwie vertiefen zu wollen). Dann kann ein user auch darauf vertrauen, dass "jemand" (notfalls er selbst) ein Modul, das er nutzen will auch weiter entwickelt und nicht einfach die community auf unschöne Art verläßt. In der Regel war es in der Vergangenheit auch so, dass zumindest mittelfristig (fast) jedes offizielle Modul einen akzeptablen Reifegrad erreicht hat...
(Es mag durchaus gute Gründe geben, manche Dinge außerhalb der Vereins-Infrastruktur zu pflegen, was manche sehr aktive Entwickler auch tun; das ist weiter ausdrücklich erlaubt!)

MMn. ist es auch kein Problem, Dinge mit geringem Verbreitungs- oder Reifegrad mit über den offiziellen Kanal zu verbreiten, wobei sowas dann imo eher nach "contrib" gehört (oder was auch immer man für einen 2. "kleinen" Kanal verwendet). Sowas wie das "Nintendo"-Modul oder GSM/SMS-Kommunikation wäre da gut aufgehoben, z.B. bei Valves habe ich erst später entdeckt, dass es dort schon ist... 

Der Installer "kennt" scheinbar auch nur die Module, die bereits im Modul-Verzeichnis liegen, und würde daher hinsichtlich des "wo finde ich was" auch nicht helfen, oder habe ich was übersehen?

Was Module angeht, die hier im Forum "vergraben sind": Immer mal wieder stolpere ich noch über was, was man ggf. über die Suche mit den richtigen Begriffen findet, heute morgen fragte z.B. jemand nach SMS-Steuerung und wurde dann auf https://forum.fhem.de/index.php/topic,35989.msg283097.html#msg283097 verlinkt. Hat lt. Statistics zwar nur 4 Treffer, aber für den, der sowas sucht, ist das auch in Zeiten von Telegram&Co sicher interessant...
Man könnte jetzt anfangen, eine Liste mit solchen "Exotenmodulen" im Wiki/Installer/... zu pflegen (samt Bewertung durch wen?), aber das hätte sich in kurzer Zeit überholt; am Ende bleibt nur der Verweis auf eine Suchmaschine. Finde ich weniger zielführend wie eine einmalige Aktion, die Autoren mal dahingehend anzustupsen, ob nicht "jemand" (am besten sie selbst) das nach Contrib einpflegen soll, zusammen mit dem Link auf den Thread, aus dem es kommt.
Ist der Weg mal (wieder?) etabliert, hat man eventuell einen nachhaltigeren Effekt?

* Was mir noch ein bisschen fehlt - aber da niemand darauf eingeht, scheine ich der Einzige zu sein - ist eine gewisse Qualitätssicherung sicher zu stellen (oder dies zumindest kenntlich zu machen).

Hmm, finde ich auch nicht ganz unwichtig, aber zum einen werden erfahrungsgemäß aufkommende Probleme am effektivsten auch durch die bzw. mit Hilfe  der Community gelöst, vor allem dann, wenn "Bedarf" für ein Modul besteht, zum anderen wäre die allgemeine Einladung, neue Module erst mal via contrib zu verteilen eine Hilfestellung auch für den User dahingehend, dass tendenziell "/FHEM"-Module eben ausgetestet und robust sind, und er sich mit contrib in einen Bereich begibt, der Probleme machen kann (aber nicht muß). Damit hätte man auf Seiten der (potentiellen) Entwickler und der user einen einigermaßen deckungsgleichen Erwartungshorizont (und eine konrete Stelle, an der z.B. Meta/Installer Infos suchen kann zu weiteren Modulen, die evtl. für den User interessant sein könnten).

Allgemein wäre meine Bitte, den Fokus neben Visionen auch auf umsetzbare Bausteine zur kontinuierlichen Verbesserung des Ist-Zustands zu legen.

[Prof. Dr. Peter Henning]

Ich sehe die ganze Diskussion hier als ziemlich akademisch an. Gegenwärtig bietet FHEM - obwohl an mancher Stelle etwas chaotisch - sowohl den Entwicklern als auch den Nutzern sehr viele Freiheiten. Diese Freiheit sollten wir nicht ohne guten Grund einschränken. Ein solcher Grund besteht _nicht_ darin, dass dann irgendetwas übersichtlicher wäre, auch nicht, dass man Bandbreite und Speicherplatz spart. Und schon gar nicht in den Einlassungen eines selbst ernannten "Principal Strategist".

Es ist schon mehr als ein Open Source Projekt den Bach heruntergegangen, weil man es ordentlicher gestalten wollte, z.B. Apache Cocoon.

LG

pah

[CoolTux]

Zum Thema Plugin-System.
Mein Gedanke ist das neue Module welche sich in der Entwicklung befinden oder Module die man selbst nicht im offiziellen svn anbieten möchte dennoch vom User leicht zu finden und in /FHEM ein zu bringen sind. Dazu zählen auch Module welche in /contrib liegen. Der User müsste sie nach /FHEM kopieren (davon mal ab das er sie sich erstmal irgendwie auf seine Platte syncen muss) und dann noch schauen ob die Rechte stimmen.

Das könnte der Installer erledigen. Der kann jetzt schon für vorhandene Module die in Meta hinterlegten Quellen abgreifen und so kann man einfach per FHEMWEB sich zum Beispiel die aktuellste Version aus Github holen. Das ist nur ein Beispiel.
Es ist doch egal wo die Quellen zu einem nicht in /FHEM liegenden Modul sich befinden, schön wäre es wenn der User eine einfache Möglichkeit zum finden und einbinden hat. Es wäre eine weitere einfache Möglichkeit.

Persönlich unterstütze ich diese Idee des Installers von Julian sehr und bin begeistern vom derzeitigen Stand. Es wäre schade wenn es einschlafen würde.


Grüße

[Loredo]

 

Unschön ist, dass man (so ich das richtig verstanden habe) da erst das prereq-irgendwas-Perl-Modul installiert haben muß (was bei mir aus irgendeinem Grund mit dh_make nicht ging, so dass direkt cpan erforderlich war) und dann die Installation weiterer Dinge nur durchläuft, wenn fhem Admin-Rechte hat.

Das hast du nicht zu Ende gedacht. das Perl Prereq Modul ist nur eine Krücke bzw ein Hilfsmittel, um die Module, die aktuell keine Metainformationen beinhalten (eben 98% aller Module) trotzdem mit möglichst vollständigen Informationen anhzeigen kann. Idealerweise gibt es irgendwann keine Module mehr ohne Metainformationen und dann braucht man das externe Perl Prereq Modul auch nicht mehr nachinstallieren (bzw. nur für exotische Module).

Ohne das im Detail durchschaut zu haben, gibt mir das kein gutes Gefühl (sorry, wenn da ein technisches Mißverständnis vorliegen sollte).Die JSON-Struktur selbst ist für mich als "Hobbyprogrammierer" eine Hürde, aber das wird schon irgendwie klappen (es gibt dazu Muster). Worauf ich raus will: Auch das System ist nicht selbserklärend für "Gelegenheitsdeveloper".

So ein META.json zu erstellen ist wirklich kein Hexenwerk. Tatsächlich nimmt der Installer das einem Entwickler sogar zu 99% schon ab: Man kann das Ergebnis des mit Hilfe von Perl Prereq ermittelten Zustandes über "get zzGetModuleMETA.json" anzeigen lassen und muss nur Copy&Paste ans Ende der eigenen Moduldatei machen - das kriegt hoffentlich jeder Entwickler hin. Man kann das JSON dann nochh bearbeiten und anpassen, muss aber nicht. Das Format entspricht dem offiziellen Perl CPAN Package Format, ist also auch im Netz super dokumentiert. FHEM spezifisce Erweiterungen gibt es über "x_*" Attribute. Auch dies entspricht dem offiziellen Standard. Welche Einstellmöglichkeiten es gibt, ist in /contrib/ bereits beispielhaft dokumentiert. Es ist aber wie gesagt für den Einstieg nicht notwendig, sich damit auseinanderzusetzen.

Insgesamt wäre meine Tendenz, nicht mehr Wege zu eröffnen, sondern die Mittel konsequent zu nutzen, die eben da sind (was Meta ggf. einschließt!) und dann auch so zu dokumentieren, dass man "developer-noobs" nicht überfordert, weil es zu umständlich/kompliziert... ist.

Ist ehrlich gesagt deutlich simpler, weil man an einer zentralen und einzigen Stelle in der eigenen Moduldatei ALLE Informationen hinterlegt und nicht über zig unterschiedliche Dateien verteilt, von denen man wissen muss, dass man es dort eintragen muss. Schau dir die Module an, die schon Metainformationen interlegt haben. Du musst für 95% der Anwendungsfälle nur das kopieren, was diese Module schon beinhalten. Wenn man CommandRef und Changelog noch dorthin übertragen möchte, ist das nur ein Katzensprung entfernt (tatsächlich habe ich das auch im Installer Modul selbst schonmal reingeschrieben, es wird halt bisher vom Installer nicht programmatisch ausgewertet und dargestellt).

Der Installer "kennt" scheinbar auch nur die Module, die bereits im Modul-Verzeichnis liegen, und würde daher hinsichtlich des "wo finde ich was" auch nicht helfen, oder habe ich was übersehen?

Stand heute ja. Der Installer ist ja auch bei weitem nicht Feature complete, steht halt eben auf der (imaginären) Todo Liste und wurde im Forum auch schon an verschiedenen Stellen thematisiert. Module auffindbar und nachladbar zu machen (inkl. Wechsel zwischen "Produktivversion" und "Entwicklerversion") ist nunmehr eine Frage ein passendes Datenformat dafür zu definieren. Für das grundsätzliche auffinden gibt es ja schon die Sourcecode Quellinformationen im META.json. Dort würde der Installer dann eben im "master" Branch nach eine Datei aus einem bestimmten Pfad abrufen. Idealerweise ist das die (Haupt)Moduldatei an sich schon und die Informationen können dann aus dem META.json Bereich "remote" ausgelesen und ausgewertet werden. Das machhen wir heute auch schhon lokal so - das Modul muss nicht geladen sein, um die Metainformationen zu erhalten.

Was Module angeht, die hier im Forum "vergraben sind": Immer mal wieder stolpere ich noch über was, was man ggf. über die Suche mit den richtigen Begriffen findet, heute morgen fragte z.B. jemand nach SMS-Steuerung und wurde dann auf https://forum.fhem.de/index.php/topic,35989.msg283097.html#msg283097 verlinkt. Hat lt. Statistics zwar nur 4 Treffer, aber für den, der sowas sucht, ist das auch in Zeiten von Telegram&Co sicher interessant...
Man könnte jetzt anfangen, eine Liste mit solchen "Exotenmodulen" im Wiki/Installer/... zu pflegen (samt Bewertung durch wen?), aber das hätte sich in kurzer Zeit überholt; am Ende bleibt nur der Verweis auf eine Suchmaschine. Finde ich weniger zielführend wie eine einmalige Aktion, die Autoren mal dahingehend anzustupsen, ob nicht "jemand" (am besten sie selbst) das nach Contrib einpflegen soll, zusammen mit dem Link auf den Thread, aus dem es kommt.
Ist der Weg mal (wieder?) etabliert, hat man eventuell einen nachhaltigeren Effekt?

Da muss man jetzt nichts im Installer direkt für pflegen... Das Meta-Package kann sogar mit lokal gepflegten Dateien umgehen, also zB Dateien, die man aus dem Forum heruntergeladen und eingespielt hat. Darüber kann man zumindest rudimentär auch zwischen aktuellen und veralteten Versionen unterscheiden, um dem Modulautor ein wenig beim support und debuggen zu helfen (es liegen ja dann oft zig Varianten verteilt im Forum und die User suchen sich oft das nächstbeste File aus ...).


Andere Projekte führen ganz einfach eine Textdatei auf Github, die jeder über einen Pull-Request (der ja dann moderiert ist) ergänzen kann. Sowas würde der Installer auswerten und von dort dann auf die anderen Repos in oder auch außerhalb von Github kommen (eben z.B. auch im /contrib/ Zweig von FHEM selbst). Die dort zu erwartende Datenstruktur müssten wir dann definieren. Ich hätte die Moduldatei selbst als allein ausreichend angenommen. Dort wäre dann noch ein Bereich einzurichten, um weitere Dateien zu verlinken, die mitkommen sollen. Das ist aber für ganz viele Module nichtmals notwendig, von daher käme man mit einem direkten Link auf die Moduldatei selbst, die dann ihre Versionsinfos alle im META.json vorliegen hat, schon sehr weit.

Allgemein wäre meine Bitte, den Fokus neben Visionen auch auf umsetzbare Bausteine zur kontinuierlichen Verbesserung des Ist-Zustands zu legen.

Meiner Meinung nach bin ich das Thema genau deshalb und auch genau so bereits angegangen.

Ich sehe die ganze Diskussion hier als ziemlich akademisch an. Gegenwärtig bietet FHEM - obwohl an mancher Stelle etwas chaotisch - sowohl den Entwicklern als auch den Nutzern sehr viele Freiheiten. Diese Freiheit sollten wir nicht ohne guten Grund einschränken.

Der Sinn von Meta und dem Installer ist genau dafür da, um mehr Freiheiten zu geben, nicht um sie einzuschränken.

[Prof. Dr. Peter Henning]

Prima, dann sind wir ja auf einer Wellenlänge.

LG

pah