Ich denke, es ist Zeit, sich über eine andere Verzeichnisstruktur Gedanken zu machen. Vielleicht hat das ja jemand schon getan - dann bitte ich um Korrektur.
Grund: Im Hauptverzeichnis stehen inzwischen ca. 300 Dateien. Teilweise mit Nummerierung vorne dran, teilweise ohne. Teilweise Frontendmodule, teilweise Backendmodule, teilweise Systemerweiterungen - wie auch immer man es dreht und wendet, die Übersicht geht so langsam in den Keller.
Anregung:
1.Gliederung entsprechend der Commandref, also in commands, devices, helpers mit jeweils eigenem Unterverzeichnis FHEM/commands, FHEM/devices, FHEM/helpers
2.Festlegung, wo sub-Module etc. abgelegt werden. So könnte man z.B. neben dem Modul FHEM/devices/00_OWX.pm noch das Verzeichnis FHEM/devices/OWX haben und darin alle Hilfskonstrukte ablegen, die eventuell importiert werden müssen. Beim Update wäre dann relativ leicht festzulegen, dass ein Update des Unterverzeichnisses nicht separat erfolgt, sondern genau dann, wenn das Haupt-Devicefile sich geändert hat.
LG
pah
Stimme ich voll zu. Dann muss aber auch der Wiki-Eintrag verbessert bzw. erzeugt werden, denn ohne Anleitung kommt es wieder zum Chaos. (z.B verstehe ich unter einem Helper-Modul, ein Modul dass etwas zu anderen Modulen hinzufügt oder von Ihnen ausliest und das ist z.B. FB_CALLMONITOR nicht.)
Dasselbe inflationäre Chaos herrscht auch in gplot. Da packt jeder seine Modul-gplots rein, egal ob die jemand braucht oder nicht.
Zitat von: tupol am 09 Mai 2014, 16:02:39
Dasselbe inflationäre Chaos herrscht auch in gplot. Da packt jeder seine Modul-gplots rein, egal ob die jemand braucht oder nicht.
DAS nervt mich am allermeisten! Man kann den überschüssigen "Müll" in dem Verzeichnis gar nicht so schnell löschen, wie er da per update reingespült wird. Gerade habe ich dort wieder eine Datei "sysstat.gplot" löschen müssen, die ich dort nicht haben möchte.
Meines Erachtens gehören gplot Dateien grundsätzlich nach contrib, von wo man sich die Dateien, die man wirklich braucht, in das aktiv genutzte gplot Verzeichnis kopieren kann. (Ausser der template Datei brauche ich z.B. überhaupt keine der standardmäßig ausgelieferten gplot Dateien)
Tja, das könnte man natürlich auf alle anderen Verzeichnisse ausweiten.
Oder, wenn wir schon beim Wiki sind: Warum nicht das Wiki zu einem SMW (Semantic Media Wiki) erweitern, so dass man eine etwas clevere Suche nach beispielhaften gplot files an Hand der gewünschten Attribute durchführen kann ? Ich gebe ja zu, dass so etwas mein Arbeitsgebiet ist - aber warum sollte man das nicht einmal praktisch umsetzen ?
LG
pah
Zitat von: Prof. Dr. Peter Henning am 09 Mai 2014, 18:10:09
Oder, wenn wir schon beim Wiki sind: Warum nicht das Wiki zu einem SMW (Semantic Media Wiki) erweitern
Weil das WIKI - gelinde gesagt - in seiner derzeitigen Form eine Katastrophe ist, zumindest inhaltlich, und wenn es darum geht, dort wirklich eine Information zu finden, von der man weiss, dass sie dort irgendwo vergraben ist.
Zitat von: Prof. Dr. Peter Henning am 09 Mai 2014, 15:15:33
Ich denke, es ist Zeit, sich über eine andere Verzeichnisstruktur Gedanken zu machen.
*unterschreib*
*unterschreib*
welches problem soll eine andere directory struktur lösen?
das fhem selber ein file nicht findet kann es ja nicht sein. so wie man auf dem standpunkt stehen kann das es dem anwender egal sein soll wie das konfig file strukturiert ist kann man auch der meinung sein so lange fhem die files findest ist es wursch wie viele davon in einem verzeichnis liegen. also muss es etwas anderes sein...
- das es zu viele fhem module gibt?
-> das ist doch kein nachteil - das in FHEM nicht nur die module sondern noch ein paar hilfs files liegen?
-> es sind unter 10%. ob das stört ist sicher ansichtssache. - etwas nach contrib zu tun ist so lange nicht gut wie es vom update ausgeschlossen ist.
- eine bessere organisation?
- wie oben vorgeschlagen an der commandref orientiert?
-> ich glaube das hilft nicht wirklich weiter. zum einen ist die einteilung nicht eindeutig
-> zum anderen bleibt wieder ein recht grosser anteil (die devices) beisammen. - das aufsplittern nach einem anderen kriterium?
-> ist wirklich aufteilen der richtige ansatz? oder doch eher zusammen suchen was zusammen gehört? - das zusammenhalten aller files die zu einem modul gehören (z.b. modul file, hilfs files, plot vorlagen, doku)
-> es gibt wenig module mit mehr als einem file
ps: ich finde es ziemlich daneben etwas als müll zu bezeichnen nur weil man selber keine verwendung dafür hat (wie ich z.b. bbb module).
pps: die plotfiles sind seit es den plot editor gibt nicht mehr so wichtig wie sie mal waren. ich glaube aber es hilft immer noch vielen mal nachsehen zu können.
Zitat von: justme1968 am 09 Mai 2014, 18:51:33
ps: ich finde es ziemlich daneben etwas als müll zu bezeichnen nur weil man selber keine verwendung dafür hat (wie ich z.b. bbb module).
da waren Anführungszeichen drumrum ;)
Zitat von: justme1968 am 09 Mai 2014, 18:51:33
pps: die plotfiles sind seit es den plot editor gibt nicht mehr so wichtig wie sie mal waren.
Genau das ist doch der Punkt. Nur zum Nachschauen brauche ich die nicht unter Edit Files.
Die Argumente von Andre vertrete ich auch, hier sind noch weitere:
- fhemupdate.pl (das Ding, was einmal am Tag die Dateien aus SVN nach fhem.de schiebt), ist z.Zt. nicht in der Lage Verzeichnisse automatisch zu kopieren, ich muss neue Verzeichnisse eintragen. Falls es sich rausstellt, dass mehrere Module Hilfsdateien brauchen, dann werde ich das aber automatisieren (muessen).
- 98_update.pm ist nicht wirklich in der Lage, Dateien zu verschieben. Es gibt zwar MOVE Befehle in control_fhem.txt, aber sie werden auch Jahre nach der Umorganization bei jedem update immer wieder durchgefuehrt, weil man nicht so recht weiss, ob es noetig ist oder nicht.
- Verzeichnisumorganisation bringt immer Verwirrung bei den Benutzer nach sich, wenn man es macht, dann sollte man gute Gruende dafuer haben, und fehlerfrei durchfuehren. Die Trennung von Bildern,Modulen und .gplot Files hat vielen einiges an Support-Stunden gekostet, und diese Trennung war sehr klar.
Fuer die .gplot/.css Dateien habe ich noch keine gute Loesung, das Problem sehe ich aber auch.
klingt ein bisschen nach "das machen wir schon immer so" ...
Die Tatsachen, dass fhemupdate.pl und 98_update.pm bestimmte Dinge einfach derzeit nicht können, ist doch kein Argument dafür, etwas deswegen nicht ändern zu können, denn solche Skripte sind nicht in Stein gemeißelt, sondern lassen sich wie alle anderen Dinge in und um fhem ändern. Vorausgesetzt, man möchte etwas ändern.
Und wenn man mit einem neuen Release eine neue Verzeichnisstruktur einführt und mit dem Release Wechsel ein migrationsscript ausliefert?
Andere bekommen das auch hin. Alte Zöpfe sollte man auch mal abschneiden. Mir erscheint es manchmal als ob das zögerliche Vorgehen (was durchaus berechtigt sein mag) einer Weiterentwicklung (Verbesserung) im Wege steht. An der Freiwilligen Power in diesem Projekt wird das meiner Beobachtung nach nicht scheitern.
Vielleicht sollte man
1.) festlegen ob dieses Thema eines ist das umgesetzt wird
Und dann
A) ein extra thread zu dem Thema öffnen
B) todo's sammeln
C) diese todo's auf verschiedenen Personen verteilen.
Erstmal ist dieser Diskussionspunkt wie so viele. Es wird nichtfestgehalten ob dies gemacht wird oder nicht.
Vorschlag für das gplot Verzeichnis:
Im Verzeichnis www/gplot nur ein Standard-Template und die gplots für die autocreate-Funktionalität zulassen.
Den Rest in ein Unterverzeichnis www/gplot/templates/unknownModul
Dann kann jeder für seine gplots ein Modulunterverzeichnis anlegen (z.B. www/gplot/templates/LUXTRONIK2) und dort seine gplots hin verschieben. Dann wäre zumindest die inflationäre Summe gelöst und man kann auch zwischen filelog und dblog unterscheiden.
Gruß
tupol
Das mit den modulspezifischen Unterverzeichnissen funktioniert nicht so einfach, weil neuangelegte Unterverzeichnisse nicht automatisch per update ausgeliefert werden.
Aber EINEN Unterordner für alle gplot Dateien ./www/gplot/templates würde ich auch begrüßen. Dann würden sich im ./www/gplot nur noch die tatsächlich benötigten gplot-Dateien befinden. Die gleiche Vorgehensweise würde ich auch bei den styles begrüßen.
Ob man gplot per autocreate wirklich überhaupt noch braucht, könnte man separat diskutieren. Mit dem plot-Editor lassen sich nach meiner Erfahrung die plot-Dateien schneller selbst anlegen als das Ändern vorhandener Vorlagen dauert. Denn das, was ein Modulautor in einer gplot Datei ausliefert, ist doch 100% willkürlich nach seinem eigenen Gusto festgelegt und keineswegs für alle Anwendungsfälle - selbst des gleichen Moduls - geeignet.
Wenn es nach mir ginge: Überhaupt keine gplot Dateien mehr ausliefern, ausser der template-Datei, die beim Klick auf den Link "Create SVG from Log" benötigt wird.
Ich kann mich noch an meine Anfangszeit erinnern. Ich fand autocreate-Plots sehr, sehr hilfreich.
Ich nicht, da ich lieber verstehen möchte, wie etwas funktioniert, anstatt mich darauf zu verlassen, dass es vielleicht eine fertige Lösung gibt, die dann aber doch nicht das tut, was ich möchte und ich mich trotzdem mit der Funktionsweise auseinandersetzen muss.
(aber wie schon gesagt - das ist genauso ein eigenes Thema, wie auch die Diskussion um die Verzeichnisstruktur nichts mit dem eigentlichen Threadthema zu tun hat)
@betateilchen: ich formuliere es anders:
- ich sehe keinen Grund, die Module auf Unterzeichnisse aufzuteilen.
- falls Bedarf besteht, Hilfsdateien fuer Module zu haben, dann werde ich das durch modulspezifische Unterverzeichnisse in FHEM unterstuetzen. Das ist aber Arbeit, was ich erst mache, wenn Bedarf besteht.
@tupol:
- ich sehe auch so wie betateilchen, dass man am besten in www/gplot nur jeweils ein template fuer FileLog bzw. DbLog anbietet, und der Rest in einem gemeinsamen templates Unterordner verscheindet, oder gar in Wiki/contrib/sonstwo. Bin nur noch zoegerlich, da ich vermute, dass nicht jeder Happy ist, wenn nach einem update fs20.gplot verschwunden ist. Alternativ Schieben/Loeschen nicht aktiv, sondern liefern es nur noch nicht mehr aus.
- autocreated plots habe ich ganz vergessen, das will ich weiter anbieten wollen. Es ist z.Zt moeglich CUL einzustoepseln, FHEM zu installieren, und nach eine Weile logs zu haben, ohne irgendein Zutun. Das will ich behalten. Seufz.
Zitat von: rudolfkoenig am 10 Mai 2014, 11:38:54
@betateilchen: ich formuliere es anders:
- ich sehe keinen Grund, die Module auf Unterzeichnisse aufzuteilen.
dafür sehe ich auch keinen zwingenden Grund
Zitat von: rudolfkoenig am 10 Mai 2014, 11:38:54
dann werde ich das durch modulspezifische Unterverzeichnisse in FHEM unterstuetzen.
Dafür sehe ich schon Bedarf - z.B. für Homematic. Oder auch für die ganzen Hilfsdateien Blocking.pm, HttpUtils.pm, TcpServerUtils.pm usw, die alle nicht als device geladen werden.
Zitat von: rudolfkoenig am 10 Mai 2014, 11:38:54
Es ist z.Zt moeglich CUL einzustoepseln, FHEM zu installieren, und nach eine Weile logs zu haben, ohne irgendein Zutun.
theoretisch ;)
Zitat von: rudolfkoenig am 10 Mai 2014, 11:38:54
Das will ich behalten. Seufz.
Wenn alle gplot Dateien in www/gplot/templates lägen, bräuchte man nur dafür sorgen, dass beim Anlegen des SVG die gewünschte gplot-Datei aus dem templates Verzeichnis nach www/gplot kopiert wird.
Ganz ehrlich, wenn ich genug Zeit habe, bastele ich auch gerne in FHEM. Aber eigentlich habe ich es mir als preiswerte Hausautomatisierung zugelegt und nicht zum Basteln. Ich freue mich zwar sehr, wenn meine eigene Bastelei auch anderen nutzt, insbesondere Leuten die nicht so technikverliebt sind. So wie ich mich kenne, verschwindet die Lust am Basteln aber bald und dann finde ich es nur noch nervig, mich in jede Änderung ewig lange einarbeiten zu müssen. Der Verbreitungsgrad der Software in meinem sozialen Umfeld beschränkt sich (trotz "Werbung") auch nur auf mich, da niemand das Ding zum Laufen bringt und auch keiner Lust hat sich einzuarbeiten.
Am Anfang war ich zudem mit den Tausenden von Einstellungen und Fehlerquellen überfordert und ich vermute, dass dies vielen "normalen" Benutzern auch so geht. Man kann ja mal eine Umfrage starten. Prinzipiell halte ich, bei fehlender Benutzerfreundlichkeit, nicht die Benutzter für unfähig sondern das Bedienkonzept für fehlerhaft.
Deshalb würde ich es stark befürworten, der autocreate Funktion ein hohes Gewicht zu geben.
@tupol: Nun, ich kann zwar nicht mit einem "sozialen Umfeld" argumentieren, das eine geringe Aufmerksamkeitsspanne hat 8). Für mich ist eher das Problem, dass ich wochenlang gar nicht zum "recerational programming" komme - und dann ob der Komplexität manchmal seufze.
@Rudi: Das Argument mit dem Update sticht - aber nur vorerst. Mal sehen, ob sich das nicht ändern lässt.
Es gibt m.E. noch eine andere Alternative, die ich zumindest mal in den Teich werfe: Stellen wir uns doch einfach vor, dass jede "normale" FHEM-Installation nur eine eingeschränkte Anzahl von Modulen umfasst - nämlich nur diejenigen, die wirklich gebraucht werden. Eine Anfangsinstallatin von FHEM wäre also sehr klein und übersichtlich. Eine Modifikation des update-Modules könnte dafür sorgen, dass bei der Neudefinition eines Devices (auch per autocreate) ein eventuell notwendiges Modul (und seine Helper) erst über das Netz geholt wird.
Selbstverständlich könnte man mit einem Kommando "get all" (oder so...) auch dafür sorgen, dass gleich der ganze Zoo geholt wird (wer es denn möchte).
Und es wäre auch möglich, mit einem "set purge" Kommando dafür zu sorgen, dass alles gelöscht wird, was lokal gar nicht benötigt wird.
Für die allermeisten Installationen würde das bedeuten, dass sie sehr übersichtlich sind - und überdies sehr viel schneller upzudaten.
Sicher würde dies auch dazu führen, dass irgendein DAU total inkonsistente Installationen herstellt. Dem kann man aber sagen, der soll sich nach einem "get all" wieder melden...
LG
pah
Zitat von: Prof. Dr. Peter Henning am 10 Mai 2014, 17:23:06
Es gibt m.E. noch eine andere Alternative, die ich zumindest mal in den Teich werfe: Stellen wir uns doch einfach vor, dass jede "normale" FHEM-Installation nur eine eingeschränkte Anzahl von Modulen umfasst - nämlich nur diejenigen, die wirklich gebraucht werden. Eine Anfangsinstallatin von FHEM wäre also sehr klein und übersichtlich. Eine Modifikation des update-Modules könnte dafür sorgen, dass bei der Neudefinition eines Devices (auch per autocreate) ein eventuell notwendiges Modul (und seine Helper) erst über das Netz geholt wird.
Dann werfe ich jetzt noch eine Alternative in den Raum,
die bei mir bereits problemlos läuft. Alle (!) Module sind in meiner configDB gespeichert und sobald ein Device definiert wird, das noch nicht in fhem vorhanden (dessen Modul noch nicht geladen bzw. im Dateisystem vorhanden) ist, wird die entsprechende Moduldatei aus der Datenbank in das Filesystem kopiert.
Der nächste logische Schritt ist dann, das Modul direkt aus der Datenbank zu laden und gar nicht mehr ins Dateisystem zu verlegen. Aber so weit bin ich mit meiner Entwicklung noch nicht.
Diese Technik macht die Sache SEHR übersichtlich. Die absolut notwendige Grundinstallation besteht nur aus diesen Modulen:
# $Id: fhem.pl 5728 2014-05-03 09:41:12Z rudolfkoenig $
# $Id: configDB.pm 5762 2014-05-06 09:56:02Z betateilchen $
# $Id: 01_FHEMWEB.pm 5783 2014-05-08 11:16:45Z rudolfkoenig $
# $Id: 92_FileLog.pm 5752 2014-05-05 15:41:00Z rudolfkoenig $
# $Id: 98_telnet.pm 4844 2014-02-08 07:54:03Z rudolfkoenig $
wobei man dabei prinzipiell sogar noch auf FileLog und telnet verzichten könnte.
Ja, ich weiss... SQL Datenbanken und Fritzbox ... aber ich wollte einen durchaus möglichen Ansatz aufzeigen, dem eine Dateistruktur völlig wurscht ist.
@pah: deine Idee hat einige nette Vorteile, eine fehlerfreie Implementation wird aber nicht trivial sein. FHEM-Module und Dateien, die man ueber FHEMWEB laedt (wie .css/.gplot/.svg) sind noch einigermassen gut abzufangen, da sie ueber zentrale Funktionen geleitet werden. Schwieriger wird es mit Hilfsmodulen, die direkt per "use" geladen werden.
Ich meine aber, dass die meisten FHEM-Anwender diese Option einfach nicht nutzen werden, um sich nicht von fhem.de abhaengig zu machen (was man hat, das hat man :). Wuerde mich interessieren, wie die Mehrheit das sieht, bevor wir Energie in sowas reinstecken.
@betateilchen: ein Filesystem ist auch eine Datenbank, d.h ob man nicht direkt benoetigte Dateien lokal speichert oder nicht, ist mit beiden Methoden gleich gut (oder schlecht) zu loesen.
Der "Vorteil" einer Datenbank in diesem Kontext ist, dass die Benutzer die Moeglichkeiten, interne Strukturen der abgelegten Daten zu studieren, nicht kennen, und deswegen sich ueber Details der Implementierung weniger aufregen. Siehe auch die "save aendert die Reihenfolge der Zeilen in fhem.cfg" Diskussion.
Zitat von: rudolfkoenig am 11 Mai 2014, 10:18:27
Ich meine aber, dass die meisten FHEM-Anwender diese Option einfach nicht nutzen werden, um sich nicht von fhem.de abhaengig zu machen (was man hat, das hat man :). Wuerde mich interessieren, wie die Mehrheit das sieht, bevor wir Energie in sowas reinstecken.
Sehe ich auch so - die Software sollte immer komplett beim Anwender vorliegen. Dabei geht es weder um die Abhängigkeit von fhem sondern um die Tatsache, dass man nicht immer und überall, wo man fhem einsetzt, auch eine Internetverbindung zur Verfügung hat (ja, solche Fälle gibt es tatsächlich auch heute noch!)
Zitat von: rudolfkoenig am 11 Mai 2014, 10:18:27
Der "Vorteil" einer Datenbank in diesem Kontext ist, dass die Benutzer die Moeglichkeiten, interne Strukturen der abgelegten Daten zu studieren, nicht kennen, und deswegen sich ueber Details der Implementierung weniger aufregen. Siehe auch die "save aendert die Reihenfolge der Zeilen in fhem.cfg" Diskussion.
Langsam kommen wir der Sache näher :) Genau deshalb habe ich ja mit der Entwicklung von configDB angefangen.
Ein weiterer Vorteil: Die Moduldatenbank gibt es bei mir nur einmal und alle drei hier in Betrieb befindlichen fhem-Installationen bedienen sich gemeinsam aus dieser Datenbank. Ja, ich weiss, man kann auch Dateisysteme freigeben, aber die Moduldatenbank ist halt nur eine einzige Datei (zumindest wenn man SQLite einsetzt) und damit sehr überschaubar und portabel.
Und was macht ihr mit den Modulen, die nicht auf dem FHEM Server liegen? Ich möchte weiterhin filebasierte Module haben. Module in Datenbanken sind weder ordentlich zu debuggen noch sehe ich den geringsten Vorteil darin.
manchmal wäre es schon schön und hilfreich, wenn manche Entwicklerkollegen auch ab und zu über ihren Tellerrand hinausdenken würden ???
Ein Benutzer, der schon beim Lesen einer Perl-Datei Probleme hat, wird sicher mit einer Datenbank noch weniger anfangen können...
Man könnte das Ganze andersherum anfangen.
Nämlich einen "Purge"-Befehl bauen, der einfach alle bei einer Installation nicht benötigten Module zunächst in ein "UNUSED" - Unterverzeichnis verschiebt. Aus diesem kann man sie ganz einfach wieder per "Unpurge" herausholen.
LG
pah
Zitat von: betateilchen am 11 Mai 2014, 12:53:18
manchmal wäre es schon schön und hilfreich, wenn manche Entwicklerkollegen auch ab und zu über ihren Tellerrand hinausdenken würden ???
Dem stimme ich 100 % zu.
Zitat von: betateilchen am 10 Mai 2014, 11:53:15
Dafür sehe ich schon Bedarf - z.B. für Homematic. Oder auch für die ganzen Hilfsdateien Blocking.pm, HttpUtils.pm, TcpServerUtils.pm usw, die alle nicht als device geladen werden.
die ganzen Hilfs-module die nicht als fhem-modul direkt (per 'define xxx') geladen werden können könnte man ja einfach ins 'lib'-Verzeichnis legen. Dann sollte dieses Verzeichnis aber von fhem.pl schon ins @INC-Array aufgenommen werden.
Ansonsten sehe ich es so: solange alle FHEM-module im package 'main' leben, sehe ich keinen Grund, warum man mit Modulspezifischen Unterverzeichnissen anfangen sollte. Das würde das Entwickeln auch nicht unbedingt vereinfachen - keine IDE sucht von sich aus in Verzeichnissen, die nicht explizit im @INC-pfad stehen nach modul-dateien, die im 'main'-package geladen werden.
Und was die Übersichtlichkeit angeht: Entweder man ist perl-entwickler und will da reinschauen, oder man ist 'nur Benutzer' und guckt eh nur in die Config-files. Und die liegen ja separat (typischerweise im Verzeichnis mit fhem.pl).
Gruß,
Norbert
Nicht doch. Die Prämisse "entweder man ist Perl-Entwickler und will da reinschauen" ist nicht exhaustiv komplementär zu "man ist nur Benutzer".
Man kann nämlich sehr wohl etwas zu FHEM beitragen, ohne sich für das fünfunddreißigste Steuermodul einer privaten Stereoanlage mit LED-Farbwechsel und Wassertemperaturanzeige zu interessieren.
LG
pah