Diskussion: Verzeichnisstruktur von fhem - jetzt und in Zukunft

[betateilchen]

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)

[rudolfkoenig]

@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.

[betateilchen]

@betateilchen: ich formuliere es anders:
- ich sehe keinen Grund, die Module auf Unterzeichnisse aufzuteilen.

dafür sehe ich auch keinen zwingenden Grund

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.

Es ist z.Zt moeglich CUL einzustoepseln, FHEM zu installieren, und nach eine Weile logs zu haben, ohne irgendein Zutun.

theoretisch

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.

[tupol]

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.

[Prof. Dr. Peter Henning]

@tupol: Nun, ich kann zwar nicht mit einem "sozialen Umfeld" argumentieren, das eine geringe Aufmerksamkeitsspanne hat  . 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

[betateilchen]

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:

Code Auswählen Erweitern


# $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.

[rudolfkoenig]

@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.

[betateilchen]

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!)

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.

[tupol]

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.

[betateilchen]

manchmal wäre es schon schön und hilfreich, wenn manche Entwicklerkollegen auch ab und zu über ihren Tellerrand hinausdenken würden 

[Prof. Dr. Peter Henning]

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

[tupol]

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.

[ntruchsess]

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

[Prof. Dr. Peter Henning]

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