Plugin-System für FHEM

Begonnen von KernSani, 10 Januar 2020, 23:11:42

Vorheriges Thema - Nächstes Thema

KernSani

Hallo zusammen,

sicher keine ganz neue Idee (ich habe aber bei einer schnellen Suche nichts dazu gefunden). Ich würde vorschlagen, dass wir uns mal Gedanken über ein Plugin-System für FHEM machen. Motivation dahinter ist, dass es mittlerweile eine Unmenge von FHEM-Modulen gibt, die im Core mit ausgeliefert werden, die aber vermutlich nur für einen Bruchteil der User relevant sind, andererseits Module, die für viele relevant sind in irgendwelchen Forums-Beiträgen (spontan fällt mir da - bis vor Kurzem - das echodevice-Modul ein) oder auf diversen Githubs verteilt sind.
Ich habe z.B, über die Feiertage zwei Module gebastelt, die für ich für mich nutze (Nintendo Switch und DSBMobile), die aber vermutlich nicht gerade Massen an Usern anziehen werden, aber für einige durchaus einen Mehrwert bieten. Ich werde diese Module voraussichtlich nie in das SVN einchecken - macht aus meiner Sicht keinen Sinn, wenn es 20 oder von mir aus 50 User gibt. Trotzdem würde ich aber den wenigen Usern die Möglichkeit geben, einfach die aktuellste Version zu erhalten (könnte ich über GIT, addToFHEMUpdate etc... aber das ist nicht Userfreundlich und Erstellung des controlfiles ist ja auch irgendwie ätzend.

Das Ganze macht es für den Anwender nicht einfach die für ihn relevanten Module zu finden, zudem kann im Prinzip jeder über Github oder Forum irgendwelchen Unfug zur Verfügung stellen, der keinen FHEM-Standards genügt.

Mein Vorschlag wäre daher in Kurzform:
* Ausdünnung des FHEM-Cores auf Module die von einem Großteil der Anwender genutzt werden.
* Schaffung eines "offiziellen" Plugin-Repositories, indem - wie heute im SVN - zumindest rudimentär geprüfte Module mit CommandRef etc... von autorisierten Entwicklern zur Verfügung gestellt werden können
* One-Click-Installation der Module aus dem Plugin-Repository aus der FHEM Oberfläche heraus (inkl. automatischem addToFHEMUpdate)

Gefühlt lässt sich sowas mit überschaubarem Aufwand umsetzen und würde es sowohl Entwicklern als auch Anwendern einfacher machen.

Was denkt ihr?

Grüße,

Oli
   
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

rudolfkoenig

Zitat* Ausdünnung des FHEM-Cores auf Module die von einem Großteil der Anwender genutzt werden.
Warum genau?
Um Bandbreite beim update zu sparen, oder dass ein "ls /opt/fhem/FHEM" schnell geht?

KernSani

Zitat von: rudolfkoenig am 11 Januar 2020, 00:02:11
Warum genau?
Um Bandbreite beim update zu sparen, oder dass ein "ls /opt/fhem/FHEM" schnell geht?
Ich glaube Bandbreite und Speicherplatz sind bei den meisten Anwendern weniger das Problem. Mir geht es mehr um Übersichtlichkeit z.B.  In http://www.fhem.de/commandref.html.
(Ja, es gibt auch modular) und eine Möglichkeit, Module, die vielleicht nur für einen kleinen Anwenderkreis relevant sind bereit zu stellen. Natürlich kann ich diese auch ins SVN einchecken, aber ist es sinnvoll, dass jeder FHEM User, 98_DSMobile.pm auf seiner SD-Karte hat?
Mag ich umgekehrt jeden Nutzer von DSMobile dazu nötigen updates aus einem Forum-Beitrag oder von Github herunter zu laden, um dann wieder mit Berechtigungsproblemen zu kämpfen, weil die Datei via FTP auf den Fhem-Server geschubst wurde?
Zusammengefasst: Ich glaube es würde es sowohl für Anwender als auch für Entwickler einfacher machen, wenn man nicht von einem Haufen von ,,Core"-Modulen erschlagen wird, sondern gezielt auswählen kann.
Möglicherweise ist es eher eine Frage der Dokumentation und der Strukturierung derselben...



Kurz, weil mobil
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

Beta-User

Hallo zusammen,

mir kommt das auch eher so vor, als ginge es  um Dokumentationsfragen.
Für Einsteiger (und vermutlich sogar fortgeschrittene Anwender), vor allem solche, die keine IT-Professionals sind, ist die Fülle an verschiedenen Wegen für (scheinbar) dasselbe Ergebnis und/oder auch welches Modul es ggf. schon für bestimmte Problemstellungen gibt usw. auch nach meinem Eindruck praktisch nicht zu überblicken.

Übersichtlichkeit bzw. Vorauswahl "wichtiger" Module (auf aktuellem Stand..., aber wer legt das fest?!?) sind daher ein Thema, das "man" angehen sollte, und z.B. das Umstellen der vom Forum aus aufgerufenen commandref auf modular (und die als default für 6.0 zu machen), könnte evtl. helfen. (Nur) über die Kurzbeschreibungen zu suchen und den "Rahmen" mehr hervorzuheben könnte die Einbettung vieler Module in die allgemeinen FHEM-Mechanismen evtl. deutlicher machen.

Inwieweit Ansätze rund um "Meta.pm" helfen können, da für weitere Übersichtlichkeit zu sorgen?

Spezielle/weitere Orte, an denen Module zu finden sein können, finde ich tendenziell schwierig. Zum einen  gibt ja auch contrib, wem also Doku "too much" ist, kann da was einchecken, dann liegt es nach einem allg. update auch mit den richten Rechten (nur am falschen Ort) vor, und der von einem populären Videoblogger (5 Gründe...) erhobene Vorwurf, die vielen Module würden alle beim Start geladen, ist sowieso Unsinn.
Wer heute Code (nur) im Forum (oder ganz außerhalb) publiziert, wird dafür Gründe haben. svn mag "speziell" sein, aber ehrlich gesagt glaube ich nicht, dass das keine wirkliche Hürde ist für jemanden, der Code allgemein verfügbar machen will, dafür entfällt ja auf der anderen Seite der update von Control-files uä. und auch die Lizenzierungs-Frage ist auf diesem Weg eher eindeutig zu klären.

Bin aber kein Experte in den ganzen Fragen, wollte nur meine 2ct loswerden.

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

Wie waere es mit einem parallel zu FHEM und contrib in SVN angelegtes Verzeichnis, was zwar die gleichen Pruefungen wie FHEM beim Einchecken benoetigt, aber per Voreinstellung nicht verteilt wird. Der Entwickler entscheidet, in welchem Verzeichnis sein Modul eingecheckt wird, der Benutzer muss das Modul explizit mit "update addModule XXX" bestellen.

Ich frage mich aber, ob das Ersparnis es Wert ist, dem Benutzer es komplizierter zu machen.

Beta-User

Hmm, überlege grade an contrib rum...

Also:
Im Moment muß man da händisch eingreifen, und zwar auch bei jedem update der betreffenden Datei (wie bekommt man das unkompliziert mit...?). Vielleicht macht es Sinn, contrib "aufzuhübschen", z.B. indem man bestimmte Module daraus "aktivieren" kann (per checkbox), die dann ins Modulverzeichnis kopiert werden und an updates teilnehmen?
(Achtung: es gibt Doppelungen, so dass man das nicht ausschließlich auf "Dateibasis" machen kann, z.B. für HMCCU wird der DEV-Zweig darüber verteilt... Man würde einen "Merker" dafür irgendwo ablegen müssen.)
Dazu eine Art "Kurzhilfe" zu der Datei, die die Kurzbeschreibung anzeigt, ähnlich wie bei attrTemplate? (sofern vorhanden).

Sowas würde transparenter machen, was es dort gibt und ggf. die "Attraktivität" dieses Weges erhöhen, ohne die Einstiegshürde zu hoch zu legen? (svn muß man immer noch "lernen" und die Berechtigung haben, aber das war's neben einer Kurzbeschreibung auch schon).

Nur mal ins Unreine gesprochen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Thorsten Pferdekaemper

Hi,
was ist falsch an dem Weg, wie z.B. FTUI, FUIP und HM485 bereitgestellt werden? Da muss der Benutzer nur einmal ein "update add ..." machen und schon kommt der ganze Kram mit dem normalen update mit.
Zum Erzeugen des Controlfiles muss man nur das normale SVN-Skript ein bisschen modifizieren und schon geht das recht schnell.
Was vielleicht noch fehlt, wäre irgendwo eine Liste, die solche "Third-Party"-Komponenten auflistet und vielleicht auch eine Bewertung erlaubt.
Gruß,
   Thorsten
FUIP

KernSani

/contrib halte ich persönlich in der heutigen Form nicht für einen sinnvollen Weg, Module zu verteilen. In Kombination mit einer Art addToUpdate (oder auch einem seperatem Verzeichnis) käme es meinem Plugin Gedanken schon recht nahe, dann ist aber tatsächlich die Frage, warum nicht gleich regulär einchecken...
Um nochmal auf mein DSBMobile-Beispiel zurück zu kommen: Ich verstehe aus de Diskussion, dass niemand ein Problem damit hat, wenn ich ein Modul einchecke, das am Wnde vielleicht nur von 5 Leuten genutzt wird?
Zum Thema Doku sind die genannten Ansätze (mit Meta muss ich mich auch mal beschäftigen) m.E. gut. Was ich auch schön fände - aber da habe ich auch noch keine echte Idee - wäre eine bessere Unterteilung der Kategorien, nur zwischen Device und Helper zu unterscheiden ist irgendwie zu wenig...
So, jetzt brauche ich erstmal noch einen Kaffee :-) Schönes Wochenende!


Kurz, weil mobil
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

KernSani

Zitat von: Thorsten Pferdekaemper am 11 Januar 2020, 10:08:51
Hi,
was ist falsch an dem Weg, wie z.B. FTUI, FUIP und HM485 bereitgestellt werden? Da muss der Benutzer nur einmal ein "update add ..." machen und schon kommt der ganze Kram mit dem normalen update mit.
Zum Erzeugen des Controlfiles muss man nur das normale SVN-Skript ein bisschen modifizieren und schon geht das recht schnell.
Was vielleicht noch fehlt, wäre irgendwo eine Liste, die solche "Third-Party"-Komponenten auflistet und vielleicht auch eine Bewertung erlaubt.
Gruß,
   Thorsten
Im Grunde ist die dezentrale Bereitstellung genau das, was ich ursprünglich als Plugin-System angedacht hatte. Neben einer zentralen Liste solcher Komponenten wäre dann noch eine Integration der Doku schön (also dass ich HM485 auch finde, wenn ich in die Commandref schaue)


Kurz, weil mobil
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

DS_Starter

Hallo Oli,

Zitat
Ich verstehe aus de Diskussion, dass niemand ein Problem damit hat, wenn ich ein Modul einchecke, das am Wnde vielleicht nur von 5 Leuten genutzt wird?
Dazu gebe ich zu bedenken, dass du die Nutzungsstatistik eigentlich nicht wirklich weißt, weil:

1. nicht jeder der ein Modul nutzt, es im Forum kundtut, d.h. keiner meldet sich mit "he, ich nutze dein Modul"
2. die Statistik unter https://fhem.de/stats/statistics.html nicht 100%ig aussagekräftig ist weil die Übertragung dieser Daten freiwillig ist und vom User aktiviert sein muss (ist auch gut so)

D.h. selbst wenn statistics sagt, 5 user nutzen dein Modul, könnten es theoretisch genauso gut 60 sein.

Grüße,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Thorsten Pferdekaemper

Zitat von: KernSani am 11 Januar 2020, 10:30:45Neben einer zentralen Liste solcher Komponenten wäre dann noch eine Integration der Doku schön (also dass ich HM485 auch finde, wenn ich in die Commandref schaue)
Also nachdem Du die Module "installiert" hast, siehst Du die Doku auch in der lokalen Commandref. ...aber das ist vielleicht nicht, was Du meinst. Jetzt könnte man fragen, warum man die Doku für ein Modul sehen will, wenn man es gar nicht benutzt. Das ist insbesondere interessant, um zu entscheiden, ob man das Modul benutzen will bzw. sollte. Diese Entscheidungshilfe müsste meiner Meinung nach nicht aus der Commandref kommen. Man braucht ja für die "3rd Party"-Module sowieso noch einen anderen Einstiegspunkt (mindestens um zu wissen, was man nach dem "update add" eingibt. Dort sollte dann auch genug Information stehen, damit man das entscheiden kann.
Gruß,
   Thorsten
FUIP

Florian_GT

Ich stelle mir vor, ich habe ein Dialog im Webinterface, dass mir alle zur Verfügung stehenden Module zur Installation anbietet. Nachdem die Installation abgeschlossen ist, wird der Konfigurationsdialog geladen. Dieser bietet mir alle notwendigen und Optionalen Felder an, die ich ausfüllen muss, damit das Module seine Funktion erfüllt. Diese Felder werden im Module mittels Array vorab vom Entwickler mit einer Beschreibung und Beispieldaten versehen, die dem Anwender hilft, die korrekten Parameter einzugeben.

Die Command Ref. in seiner jetzigen Form würde ich komplett abschaffen. Den Inhalt würde ich in z.B. eine Markdown oder ähnliche Dokumentationsform bringen, welche je Module in einen "doc" Ordner gespeichert und somit auch Offline verfügbar ist. Ich würde eine Form wählen, die mit einfachen "Word ähnlichen" Programmen auf Linux und Windows bearbeitet werden kann. Ohne eine komplexe Markdown Language lernen zu müssen. Jeder sollte per GIT oder SVN daran teilnehmen können. Den Content aus dem Wiki und der Commandref sollte hier in eine gemeinsame Dokumentation gegossen werden.

Es gibt ja auch Software im OpenSource Bereich die sich um die Übersetzung kümmert.

Im Module würde ich dann nur noch eine Beschreibung und eine Konfigurationsparameter dokumentation sehen. Dazu wäre hilfreich wenn auch dokumentiert wird, welche Daten das Module in welchen Readings ausgibt.
FHEM: Proxmox Server, FHEM in VM, pgSQL DB
Hardware: Ethersex (Pollin NETIO Boards), Diverse Tasmota MQTT Devices, Raspberry Pi Zero W Kameras, (Github RaspberryPiStreamingCamera), Zigbee2MQTT, ESPEasy

Development: UBA (Umwelt Bundesamt), BFS (Bundesamt für Strahlenschutz)

KernSani

@Florian_GT: So in etwa würde ich mir das auch vorstellen...   
Zitat von: Florian_GT am 11 Januar 2020, 22:39:53
Ich stelle mir vor, ich habe ein Dialog im Webinterface, dass mir alle zur Verfügung stehenden Module zur Installation anbietet.
Hier könnte man noch (mit einem Icon o.ä.) verschiedene "Reifegrade" unterscheiden, z.B.: FHEM Core (also SVN, erfüllt gewisse Standards), Extern (aber erfüllt SVN Standards), Beta (ungeprüft, hat evtl. keine Doku, oder nicht die notwendigen Metadaten für die Konfig usw...)
Zitat von: Florian_GT am 11 Januar 2020, 22:39:53
Die Command Ref. in seiner jetzigen Form würde ich komplett abschaffen. Den Inhalt würde ich in z.B. eine Markdown oder ähnliche Dokumentationsform bringen, welche je Module in einen "doc" Ordner gespeichert und somit auch Offline verfügbar ist. Ich würde eine Form wählen, die mit einfachen "Word ähnlichen" Programmen auf Linux und Windows bearbeitet werden kann. Ohne eine komplexe Markdown Language lernen zu müssen. Jeder sollte per GIT oder SVN daran teilnehmen können. Den Content aus dem Wiki und der Commandref sollte hier in eine gemeinsame Dokumentation gegossen werden.
Ich würde schon noch unterscheiden zwischen "offizieller" Doku des/der Entwickler(innen) und "Contributern" aber beides an einer Stelle und vernünftig editierbar wäre schon schön (*träum*)

Lass uns an die Arbeit machen ;)
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

Thorsten Pferdekaemper

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
FUIP

CoolTux

Zitat von: Florian_GT am 11 Januar 2020, 22:39:53
Ich stelle mir vor, ich habe ein Dialog im Webinterface, dass mir alle zur Verfügung stehenden Module zur Installation anbietet. Nachdem die Installation abgeschlossen ist, wird der Konfigurationsdialog geladen. Dieser bietet mir alle notwendigen und Optionalen Felder an, die ich ausfüllen muss, damit das Module seine Funktion erfüllt. Diese Felder werden im Module mittels Array vorab vom Entwickler mit einer Beschreibung und Beispieldaten versehen, die dem Anwender hilft, die korrekten Parameter einzugeben.

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
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net