Anpassung commandref zu include / Hinweis Expertenfunktion

krikan · 31 Mai 2016, 09:47:04

Die commandref zu http://fhem.de/commandref.html#include bzw. http://fhem.de/commandref_DE.html#include vermittelt für mich den Eindruck als sei include sehr sinnvoll quasi notwendig, um die .cfg zu strukturieren. Dass es dabei viele Abhängigkeiten zu beachten gibt, wird in der commandref jedoch nicht erwähnt. Zudem animiert dies zum direkten Editieren der .cfg. Gerade Einsteiger/Anfänger werden so mMn in eine falsche Richtung geschickt und nutzen dann intensiv include ohne Kenntnis der Probleme/Abhängigkeiten. (aktuell: https://forum.fhem.de/index.php/topic,54009.0.html)

Wäre es nicht sinnvoll in der commandref darauf hinzuweisen, dass include eine Expertenfunktion ist und grundsätzlich keinerlei Notwenigkeit zur Nutzung und manuellen Bearbeitung der .cfg besteht?

Gruß, Christian

CoolTux · 31 Mai 2016, 10:05:39

Ich wäre sogar dafür diese Passagen komplett zu entfernen.

marvin78 · 31 Mai 2016, 10:07:49

Entfernen ist natürlich nicht nötig. Es gibt schon auch Gründe für sehr fortgeschrittene User, include zu verwenden (ich denke da an Testsysteme bei Entwicklern). Hinweise auf die "Gefahren" bzw. der klare Hinweise darauf, dass include UND die Strukturierung der config nicht notwendig ist, halte ich jedoch für angebracht.

CoolTux · 31 Mai 2016, 10:12:47

Man sollte es tief in der Commandref verstecken. Fett rot Expertenfunktion schreiben und dazu das es keinerlei Support bei Verwendung gibt. Meine Meinung.

Grüße

rudolfkoenig · 31 Mai 2016, 11:07:20

Habe die Beschreibung verkuerzt, und mit "Dieses Befehl sollte nur von Experten verwendet werden." ergaenzt.

Bin noch unentschlossen, wie man ein System baut, was sowohl von Neulingen, wie auch von Erfahrenen verwendet werden kann. Eigentlich tendiere ich zu "du hast alle Freiheiten, auch das System kaputtzukonfigurieren", was fuer Neulinge ein Problem ist. "attr global expert" ist sinnlos, wie wir das bei der Einfuehrung von editConfig gesehen haben.

betateilchen · 31 Mai 2016, 11:20:23

Textbasierte Konfigurationsdateien abschaffen.

CoolTux · 31 Mai 2016, 11:34:21

Zustimmung

rudolfkoenig · 31 Mai 2016, 11:34:38

Nach dieser Logik ist das Registry dem /etc/* eindeutig ueberlegen

CoolTux · 31 Mai 2016, 11:41:25

Sehe ich nicht so. Es kommt auf das Umfeld und die Gegebenheiten an. Im Gegensatz zu FHEM bietet Linux schon ein komplexeren Einstieg wenn man nicht gerade mit Ubuntu oder SuSe arbeitet. Hier ist man gezwungen vom Start er sich mit der Grundmaterie zu beschäftigen. Bei FHEM muss man kein Perl lernen und auch nicht die cfg kennen. Man kann wunderbar ohne arbeiten. Und muss den Umgang mit cfg auch nicht lernen zum arbeiten.
Aber genau das wäre Voraussetzungen wenn man mit include arbeiten will. Man sollte die Abhängigkeiten lernen und erkennen.

Ich wäre für eine Umstellung auf configDB von Start weg.

krikan · 31 Mai 2016, 11:45:22

ZitatHabe die Beschreibung verkuerzt, und mit "Dieses Befehl sollte nur von Experten verwendet werden." ergaenzt.

Danke!

Zitat von: rudolfkoenig am 31 Mai 2016, 11:07:20
Eigentlich tendiere ich zu "du hast alle Freiheiten, auch das System kaputtzukonfigurieren", was fuer Neulinge ein Problem ist.

Ja.
Aber wir können Anfängern per Doku eine Richtung zeigen, wie man einfacher starten kann und "include" gehört mMn eben nicht (mehr?) dazu.
Btw: der hilfreiche codemirror ist auch recht gut in der Doku versteckt.

zum Offtopic: ich möchte meine textbasierte Konfig und nichts anderes...

CoolTux · 31 Mai 2016, 11:49:28

Darfst und kannst Du ja gerne haben. So wie configDB gerade Optional ist und cfg File default kann man es ja dann umdrehen. configDB default und wer es anders mag cfg File Optional.

Das ist meine Meinung, nicht meine Religion

marvin78 · 31 Mai 2016, 11:51:51

Diese Diskussion kommt mir bekannt vor, gehört aber hier ggf. nicht wirklich hin. Im Grunde ist es völlig egal, was verwendet wird. Das Nachdenken wird nicht ersetzt und das ist es, woran es in der Regel liegt, dass die Dinge nicht funktionieren bzw. auch die Hilfe schwer ist, weil die Infos dementsprechend nicht geliefert werden.

betateilchen · 31 Mai 2016, 11:54:08

Genau das mit dem Umdrehen meine ich auch.

Lasst uns doch mal (und das ist ernstgemeint) darüber nachdenken, ob man fhem in einer der nächsten Versionen (meinetwegen ab Release 6) mit der configDB als default unters Volk bringt. Die aktuellen Installationspakete bringen bereits alles mit, was dazu nötig ist, es müssen nur zwei Dateien aus ./contrib umkopiert werden.

Zitat von: krikan am 31 Mai 2016, 11:45:22
zum Offtopic: ich möchte meine textbasierte Konfig und nichts anderes...

@krikan: Warum? Hast Du das Arbeiten mit der Konfigurationsdatenbank jemals getestet? Welche Schwierigkeiten erwartest Du?

Beta-User · 31 Mai 2016, 12:14:02

Zitat von: rudolfkoenig am 31 Mai 2016, 11:07:20
Bin noch unentschlossen, wie man ein System baut, was sowohl von Neulingen, wie auch von Erfahrenen verwendet werden kann.

Mal aus der Sicht eines Normalusers und ehemaligen Neulings:

Auf den ersten Blick fand ich bei Start mit FHEM (totaler Newbie) die Option der includes EXTREM ATTRAKTIV.
Nach wie vor verwende ich sie, und zwar gerne!

Die große Skepsis der includes gegenüber von eurer Seite (Entwicklerperspektive) kann ich andererseits auch sehr gut nachvollziehen

, da es eben deutlich etwas anderes ist, als nur eine fhem.cfg zu haben (ich habe damit zwar niemandes Zeit mit diesbezüglichen selbstverursachten Fragstellungen gestohlen, bin aber näherungsweise verzweifelt, bis ich verstanden habe, dass man dabei peinlich genau die Reihenfolge planen sollte, in der die einzelnen Bausteine geladen werden!!!).

"Damals" (das ist die Ewigkeit von ca. 30 Monate her) gab es (zumindest aus meiner möglicherweise beschränkten Perspektive) nur die Option, die config direkt zu bearbeiten - was ja aus durchaus berechtigten Gründen mittlerweile ebenfalls unerwünscht ist (im aktuellen Einsteiger-pdf aber noch als muss drin ist (S. 20/21!!!- und ja, das pdf ist super!)). Das hatte allerdings zwei sehr große Haken:

- ab einer gewissen Anzahl von Devices wird die fhem.cfg sehr unübersichtlich, insbesondere um sie zu editieren (bin HW-seitig wg. einer Renovierung gleich mit ca. 8 HM-Rolläden und diversen Dimmern usw. gestartet).

- eine gewisse Versionierung geht auch nur, wenn man die Kommentierungsfunktion nutzt, um "alte" Fassungen als Datenbasis verfügbar zu halten. Ich nutze das vor allem für das Basteln komplexerer Dinge wie DOIF's usw., und ja, configDB kann das sicher besser, Betateilchen, ich weiß. codemirror höre ich eben zum ersten Mal...

Rudolf ist nur beizupflichten, dass es unendlich schwierig ist, hier die "richtige" Balance zu finden, vor allem um Unerfahrene/Interessierte sinnvoll zu leiten und trotzdem Experten (oder denen, die ihre Erfahrungen gemacht haben) alle Möglichkeiten offen zu lassen. Ich wäre als zwischenzeitlich überzeugter fhem-User wahrscheinlich beigedreht, wenn mir damals jemand gesagt hätte, ich müsse vorneweg erst mal einen Datenbankserver aufsetzen, um fhem testen zu können (ich hatte (m)eine Fritzbox für meine ersten Versuche genutzt und ja, ich habe vorher auch schon Linux-Erfahrung und auch schon mal anderweitig eine MySQL-DB aufgesetzt).

Langer Rede kurzer Sinn:
Gerne bringe ich bei Interesse meine persönlichen Erfahrungen und Ideen ein, um anderen FHEM schmackhaft zu machen.

Anmerkungen in diese Richtung dazu noch:
V.a. am Anfang ist es schwer, sich überhaupt zu orientieren um einen Ansatzpunkt zu haben, wie man sinnvollerweise vorgeht bzw. was es benötigt. Weder das Einsteigerdokument noch das Wiki geben dazu so richtig Auskunft.

Etwas überspritzt formuliert würde ich es für Interessierte in die Richtung sagen:

FHEM ist etwas für Leute, die
- eine Möglichkeit suchen, über ihr Smartphone ihre Haustechnik zu steuern
- Informationen rund um's Haus zentral erfassen und auswerten können wollen
- eine vorhandene Hausautomatisierung grafisch anders darstellen wollen oder
- allgemein: im IoT nicht auf einen Hersteller oder eine bestimmte Lösungsmöglichkeit angewiesen sein wollen

Für FHEM braucht es:
- Freude am Experimentieren und Dazulernen
- einen 24/7 Server
- Schnittstellen für die Kommunikation mit der realen Welt
- Entscheidungsfreude: Für fast alle Dinge, die man mit einer Hausautomatisierung tun könnte, gibt es mindestens 2 Wege! Also: Einlesen und Entscheiden!!!!

Was tue ich, wenn ich noch keinen 24/7-Server betreibe?
- Kauf einen RPi, laß Deine FB wie sie ist! (Oder such' dir andere Server-HW, aber die 50€ sind mindestens für erste Versuche gut investiert!)

Welche Schnittstellen brauche ich?
- Welche HW willst Du steuern bzw. hast Du???
(Orientierungshilfe....)

betateilchen · 31 Mai 2016, 14:06:16

Zitat von: joe_re am 31 Mai 2016, 12:14:02
Mal aus der Sicht eines Normalusers und ehemaligen Neulings:
...
wenn mir damals jemand gesagt hätte, ich müsse vorneweg erst mal einen Datenbankserver aufsetzen, um fhem testen zu können (ich hatte (m)eine Fritzbox für meine ersten Versuche genutzt und ja, ich habe vorher auch schon Linux-Erfahrung und auch schon mal anderweitig eine MySQL-DB aufgesetzt).

Niemand muss vorneweg einen mysql Server aufsetzen, um ein datenbankbasiertes fhem zu testen. Das vorhandene .deb Paket enthält heute schon alles, was man braucht, um damit sofort anzufangen. Es werden lediglich zwei zusätzliche perl Pakete benötigt, die aber auch bereits heute im controlfile enthalten sind, das die .deb Installation steuert.

Und das Thema Fritzbox sollte für uns irgendwann nicht mehr Entscheidungsgrundlage sein. Mein Vorschlag mit der Umstellung würde sich nur auf Neuinstallationen auswirken.