Unterstützung bei Aktualisierung von https://fhem.de/HOWTO_DE.html gesucht!

[Beta-User]

Braucht's das HOWTO überhaupt?

Wir haben diese Frage implizit ja in den Anfangsbeiträgen etwas gestreift, und ich selbst habe mir die auch gestellt - Antwort ist bekannt.

Was uns alle umtreibt ist eine gewisse Unzufriedenheit mit der Doku für Interessierte, und in Teilen sehe ich auch diese Fassung nur als eine Art Übergangslösung bis wir eine bessere Idee haben bzw. ggf. auch nur, bis alle Teile wieder sinnvoll neu strukturiert sind. Von daher: "proudly found elsewhere" ist auch ok....

Da FHEM sich nicht nur an deutschsprachige User wendet, ist m.E. für Doku, die man zum Einstieg benötigt, auch eine englische Fassung _zwingend_ erforderlich. Im Prinzip kann man ja behauten, mit der commandref sei der Punkt abgehakt, aber das würde auch die deutschen Fassungen aller anderen Dokumente obsolet machen...

Dann also nur das Einsteiger-pdf überarbeiten und übersetzen? Wäre ein Ansatz, aber
a) steht m.E. mindestens eine vorsichtige Renovierung des pdf's seit längerem aus und
b) wer sich schon ein wenig auskennt (weil er eine andere SW wie openhab schon kennt), wird sich kaum durch dieses Dokument wälzen wollen, sondern sucht nach etwas komprimierterem.

Er wird entweder gleich nach der Installation mit Trockenübungen beginnen (Erste Schritte) oder es direkt mit echter HW versuchen wollen. Erste Schritte ist allerdings vom Stil her wirklich eher weniger ein Überblick, es wird da auch schon wieder schon einiges (zu viel?) auf Basisniveau erläutert.

Also: Eine englische Doku, kurz (auf das wesentliche beschränkt) ist Pflicht. Nicht mehr, nicht weniger...

(Zu der Schreibweise im Anfängerbereich: Habe ich keinen Einfluß drauf und einfach die Dinge so übernommen wie vorgefunden. Auf FHEM.de ist FHEM groß geschrieben, also dürfte das das Maß der Dinge sein).

Darum (und auch aus anderen Gründen) ringe ich in Beta-Users Vorschlag auch mit der Angabe von Hardwareempfehlungen (raspberry); würde das eigentlich gerne herausnehmen.

Ist erledigt. So komme ich auch um den Hinweis rum, dass die GPIO's ansonsten nur dazu da sind, die Finger davon zu lassen bzw. ggf. nur neben dem PI-PCB eine RTC zu installieren .
Aber ihr habt recht, es sollte irgendwo stehen, dass man als Einsteiger (und nicht Linuxer) ein Linux nutzen sollte. Wohin damit?

Ansonsten habe ich bei der Gelegenheit noch die Überschriften etwas geändert und den Security-Teil modifiziert (Fahrplan: s.o.)

[drhirn]

Da FHEM sich nicht nur an deutschsprachige User wendet, ist m.E. für Doku, die man zum Einstieg benötigt, auch eine englische Fassung _zwingend_ erforderlich. Im Prinzip kann man ja behauten, mit der commandref sei der Punkt abgehakt, aber das würde auch die deutschen Fassungen aller anderen Dokumente obsolet machen...

Ich weiß, ich steh hier alleine auf weiter Flur. Aber ich halte die commandref nicht für eine - für den Anfänger - hilfreiche Sache. Um zu verstehen, um was es in der commandref geht, braucht man schon Vorwissen. Genau das nämlich, das im HOWTO und den anderen Dokumenten vermittelt wird.
Ich würde daher die commandref in dieser und sämtlichen anderen Diskussionen zur FHEM-Dokumentation aussen vor lassen. Die ist einfach eine technische Referenz für detaillierteres Wissen. Und das ist gut so.
Soll heißen, es braucht trotzdem noch eine Einführungs-Dokumentation. Wenn das dann nur ein einziges Dokument ist, wäre die auch leichter zu warten. Und v.a. auch leichter zu übersetzen.

Aber eigentlich war's total blöd, dass ich die Diskussion losgetreten habe. Die Zeit wäre besser in der Überarbeitung des HOWTOs investiert gewesen. Und wer weiß, vielleicht kommt da dann ja am Schluss versehentlich genau das raus, was wir alle wollen

[Morgennebel]

Ich weiß, ich steh hier alleine auf weiter Flur. Aber ich halte die commandref nicht für eine - für den Anfänger - hilfreiche Sache. Um zu verstehen, um was es in der commandref geht, braucht man schon Vorwissen. Genau das nämlich, das im HOWTO und den anderen Dokumenten vermittelt wird.

Darüber habe ich auch schon oft nachgedacht. Selbst nach gut 3 Jahren FHEM überfordern mich die FHEM-Commandref und viele der Wiki-Artikel...

Einem Einsteiger wird es hier sehr schwer gemacht. Wie wäre es denn mit einer neuen Kategorie von Wiki-Artikeln auf dem Niveau von http://www.instructables.com/ ? Eine Aufgabenstellung, eine ins Detail dokumentierte Lösung mit Einkaufsliste und Photos.

Schnelle und einfache Erfolgserlebnisse für den Anfang. Quasi die Einstiegsdroge für einige Szenarien.

Ciao, -MN

[drhirn]

In der Art gibt's das eh so ungefähr. Aber halt nicht kuratiert. https://wiki.fhem.de/wiki/Kategorie:HOWTOS

Ändert aber nichts dran, dass es irgendwie eine Einsteiger-Anleitung geben muss.

[Beta-User]

Ich weiß, ich steh hier alleine auf weiter Flur. Aber ich halte die commandref nicht für eine - für den Anfänger - hilfreiche Sache. Um zu verstehen, um was es in der commandref geht, braucht man schon Vorwissen. Genau das nämlich, das im HOWTO und den anderen Dokumenten vermittelt wird.

Dass "die" commandref kein "einfaches" Dokument ist, ist schon richtig. Aber jeder Anfänger sollte zum einen "auswendig lernen", dass es eben DIE Doku ist, in die er nolens volens zu sehen hat!
Bei so einem Einstieg kann es nur darum gehen, einen Neuling (s.u.) dazu zu befähigen, sie - in den jeweils relevanten Abschniten - zu lesen und - zumindest in Ansätzen - zu verstehen. Ab da beginnt die harte Arbeit, die eben jeder vor sich hat.

Das ist jetzt zwar etwas OT und wurde auch schon an anderer Stelle diskutiert:
Es folgt daraus eigentlich vielleicht auch eine weitere Konsequenz. Teile, die der jeweilige Anwender nicht versteht, sollte er nicht nutzen! (Immer vorausgesetzt, die Darstellung selbst ist verständlich).

Dabei geht es nicht darum, dass jeder den Linux-Kernel-Quellcode nachvollziehen kann. Aber etwas verkürzend gesagt: Wenn ich den in der commandref dargestellten gedanklichen Kern eines Moduls (Anwendungsbereich und Voraussetzungen) oder ein Stück Mustercode nicht verstehe, darf ich als User eben allenfalls mich selbst den Wirkungen desselben aussetzen, die übrige Umwelt ist tabu.

Zwischenzeitlich kann ich dem Teil der Community sehr gut folgen, der die Aufrechterhaltung einer nicht zu niedrigen Eintrittschwelle in die Welt der Hausautomatisierung befürwortet. Leider fühlen sich dann manche andere bemüßigt, die Lücke zu füllen mit der Folge, dass man dann plötzlich lauter neue User mit Raspbian-Installationen einschließlich GUI hat, die glauben, alles sei einfach. Aber "leider" leben die meisten von uns nicht in einer Musterfamilie unter völlig identischen äußeren Rahmenbedingungen im IKEA-Haus, wie es seit 20 Jahren unverändert verkauft wird. Daher sind die wenigsten Dinge "einfach", und copy-paste hilft meist nur für die "kleinen" Aufgaben.

Und als "Einkaufsliste" haben wir immer noch im Einsteigerdokument Fritte+CUL stehen... Das durch Pi+Modul zu ersetzen ist kaum die Lösung, oder?

Wer also sowas wie instructables will, der muß es schon selber machen .

Was "Neuling" angeht:
Diese/r sollte daher mind. die Voraussetzungen mitbringen, verantwortlich mit dem wundervollen Baukasten umzugehen, der hier angeboten wird. Das erfordert etwas IT-Grundlagen und - vor allem - eine gewisse Grundkompetenz, große Problemstellungen wie den grundlegenden Aufbau einer Hausautomatisierung zu gliedern sowie den Zusammenhang zwischen Ursache und Wirkung verstehen zu können und zu wollen.
Werfen wir ihm also hier (Howto) einen Begriff vor die Füße, den er nicht versteht, sollte er eben eine Suchmaschine befragen - alleine das vom einzelnen konsequent umgesetzt würde bereits ca. 20% der heute im Forum gestellten Fragen überflüssig machen . Das Dokument könnte also ein Arbeitspapier in diesem Sinne sein.

Ergo geht es vorliegend eigentlich um Schadensbegrenzung:
Die "richtigen" Neulinge sollen befähigt werden, schnell eine ordentliche Installation zu erstellen, in der ihre Vorstellungen im Wesentlichen umgesetzt ist, der Rest darf gerne sagen: komischer Club, ist mir zu hoch.

Die Frage, die ich mir in dem Zusammenhang immer wieder stelle:
Wie kann man das eine vom anderen trennen? Wie kann man den Interessierten zum "richtigen" Neuling werden lassen, ohne die anderen vor den Kopf zu stoßen oder auf die nächste Lösung zu verweisen, die sie vermutlich genausowenig verstehen werden wie FHEM?

Aber gerade an der Stelle lassen wir eine Leerstellte bzw. überlassen das Feld anderen, die - aus welchen Gründen auch immer - die Kunde streuen, alles sei einfach.

Na ja, vergeßt es wieder, aber jetzt war es schon getippt, vielleicht findet es ja jemand doch aufschlußreich...

Und zur Klarstellung: Es braucht sich keiner der bisher hier an der Diskussion Beteiligten als "falsch hier" angesprochen fühlen .

[dev0]

Dass "die" commandref kein "einfaches" Dokument ist, ist schon richtig. Aber jeder Anfänger sollte zum einen "auswendig lernen", dass es eben DIE Doku ist, in die er nolens volens zu sehen hat!

Ich möchte mich jetzt schon dafür entschuldigen, dass ich nur "meine Meinung einwerfe" und mich an der Diskussion nicht weiter beteiligen werde:

Ich frage mich in diesem Zusammenhang: was ist FHEM denn eigentlich?

- ein Perl Framework für Enthusiasten, die kein Problem damit haben Quellcode oder techn. Dokumentationen zu lesen und ggf. anzupassen?
- ein Tool zur Automatisierung, dass Hans und Franz via GUI bedienen kann?

Mittlerweile vermutlich ein Zwitter. Aber ohne klare Ansage der/des Macher wird es schwieg bleiben eine klare und konsistente Dokumentation/Referenz zu schreiben.

- Sind Perlkenntnisse Voraussetzung für FHEM oder soll/kann man sich durch's Forum fragen. Es sind ja nur ein paar Zeilen, die man nicht kennt...
- Notify mit Perlcode braucht man ja auch nicht, die DOIF Syntax kann man ja (vielleicht) schneller lernen oder aus dem Forum/Wiki kopieren...

_Ich persönlich_ würde mir wünschen, dass das, für den Einsteiger im Vorfeld etwas klarer werden würde. Aber diese Entscheidung gibt es bisher nicht.

[Beta-User]

@dev0:
Danke für die Anmerkung!

Du hast es recht gut auf den Punkt gebracht, und bei näherer Betrachtung ist es so, dass wir uns schon zu lange in Richtung "Klickibunti via Gui" entwickelt haben, um an diesem Befund noch ernsthaft was zu ändern zu wollen.

Also laßt uns Interessierte in der richtigen Weise aufklären.

Knappe, technisch orientierte Doku für Linuxer mit Perl-Kenntnissen (bzw. solchen, die Programmierkenntnisse in anderen Sprachen mitbringen), (wer auch immer die erstellen mag) längere Fassungen für den Rest.

Dazu braucht man auch keine alten Glaubenskämpfe mehr aufleben zu lassen. Das Ursache-Wirkung-Prinzip stellt sich ja unabhängig von der konkret verwendeten Umsetzung (ohne einzelne Module nennen zu wollen ).

Aber es sollte eigentlich als Erstes die Hilfestellung zur Frage erstellt werden: Ist FHEM etwas für mich?
Was sollte ich mitbringen bzw. lernen und was dauerhaft leisten...

[drhirn]

Zum Thema "Klickibunti via GUI": Ist die Steuerung/Verwaltung von FHEM mittels Telnet sehr verbreitet? Frage deshalb, weil's das HOWTO komplizierter als nötig macht (zum Schreiben + Verstehen), wenn immer telnet + FHEMWEB gleichzeitig (oder nur eines von beiden) erwähnt werden.

[drhirn]

Ich hab mal ein bisschen am HOWTO gearbeitet. Meine Anmerkungen sind immer in grün.

Mach jetzt mal eine Pause vom Editieren und schau, wie ich FHEM dazu bringe, mit meiner neuen NSA-Wanze (Echo Dot) zu kommunizieren

[Beta-User]

@drhirn:
Danke für die tatkräftige Mitarbeit!

Was das inhaltliche angeht, habe ich sehr gemischte Gefühle, da wir Meinungen austauschen, schreibe ich die Dinge, wie ich sie _empfinde_. Die meisten Änderungen finde ich (sehr) ok, auch wenn es dazu führt, dass der Text (teilweise) wächst. Kurz dazu:
- telnet/FHEMWEB: das so zu gliedern, telnet kurz zu erläutern, und dann Bilder zum Webfrontend einzufügen war sehr gut!
- Zu Begriffserklärung habe ich kurz was geschrieben, das sollte ggf. ausgelagert werden (Link in Info-Kasten rechts?), über das wo habe ich mir noch keine Gedanken gemacht.
- Wichtige Befehle für den ersten Start: noch unentschlossen, meine Tendenz wäre, das erst mal an das Ende des Textes zu verschieben. Da macht es eventuell dann auch für den Leser- je nach Umfang - mehr Sinn. Wenn es zu viele sind, wäre es dann entweder eine Art Linkliste oder ein separater Artikel?
- Mit einem Dummy oder einem DOIF anzufangen, sehe ich sehr kritisch. Dummy haben wir in den "ersten Schritten", da erschließt sich mir der Mehrwert der Doppelung nicht und ich vermute, dass die ersten Schritte auch der Hintergrund für die in jüngster Zeit zu erkennende inflationäre Verwendung ist. Da sollten wir gegensteuern oder jedenfalls dem nicht weiter Vorschub leisten. Zu DOIF wollte ich eigentlich nichts sagen, effektiv ist es _für mich persönlich_ ein nogo! Dazu nur soviel: Ich habe eben code generiert, um mit 3 RandomTimer-Definitionen zwei der verbliebenen 5 DOIFs in meiner Installation zu ersetzen, der Rest fliegt raus, wenn ich ausgiebig Zeit finde, um Clunis Rollandenlösung endlich zu implementieren.
Wenn also ein device konkret bereits an der Stelle erläutert werden soll, dann m.E. allenfalls "allowed"
- "by-id" propagiere ich selbst gerne, es führt aber an der Stelle m.E. zu weit.
- Das mit den spitzen Klammern würde ich irgendwo mal erwähnen, es gibt immer wieder user, die das nicht intus haben...

Wie gesagt, meine _Empfingung_!

tbc

[drhirn]

- Zu Begriffserklärung habe ich kurz was geschrieben, das sollte ggf. ausgelagert werden (Link in Info-Kasten rechts?), über das wo habe ich mir noch keine Gedanken gemacht.

Können wir auch machen. Ich würd's nur irgendwo unterbringen, weil wir die Begriffe dann in weiterer Folge den Lesern um die Ohren schleudern. Und das Wissen darüber halte ich für essentiell für das Verständnis der Funktionsweise von FHEM.

- Wichtige Befehle für den ersten Start: noch unentschlossen, meine Tendenz wäre, das erst mal an das Ende des Textes zu verschieben. Da macht es eventuell dann auch für den Leser- je nach Umfang - mehr Sinn. Wenn es zu viele sind, wäre es dann entweder eine Art Linkliste oder ein separater Artikel?

Hätte da nur an die Befehle gedacht, die im Laufe des HOWTOs auch vorkommen. Also wie in der notierten Liste. update, shutdown restart, define. Mehr eh nicht. Steht ja sowieso in der commandref.

- Mit einem Dummy oder einem DOIF anzufangen, sehe ich sehr kritisch.

Aber es ist die einfachste Möglichkeit, wie ich einem User die Funktionsweise von FHEM näherbringen kann. Ohne Hardware zu benötigen. Und es gibt den schnellen "Wow, ich hab was geschafft"-Effekt der weiter oben schon mal erwähnt wurde. Was ganz einfaches nur. Klick auf Dummy1 und Dummy2 geht an. Oder so. Wir können dann ja in einem Nebensatz erwähnen, dass Dummys doof sind

Wenn also ein device konkret bereits an der Stelle erläutert werden soll, dann m.E. allenfalls "allowed"

Gefühlt ist das für mich eher eine Konfigurationsoption als ein Device (auch wenn's technisch natürlich ein Device ist) und zeigt eigentlich nicht die Vorgehensweisen und Möglichkeiten eines "richtigen" Devices.

- Das mit den spitzen Klammern würde ich irgendwo mal erwähnen, es gibt immer wieder user, die das nicht intus haben...

Du meinst sowas: <fhem-server>?

[Beta-User]

Können wir auch machen. Ich würd's nur irgendwo unterbringen, weil wir die Begriffe dann in weiterer Folge den Lesern um die Ohren schleudern. Und das Wissen darüber halte ich für essentiell für das Verständnis der Funktionsweise von FHEM.

Na ja, an sich hatte ich gedacht, man könnte auf eine Art Glossar verweisen. Das gibt es sogar, allerdings sind da - jedenfalls auf den ersten Blick - zuviele Stichworte.

Hätte da nur an die Befehle gedacht, die im Laufe des HOWTOs auch vorkommen. Also wie in der notierten Liste. update, shutdown restart, define. Mehr eh nicht. Steht ja sowieso in der commandref.

Anmerkung zu den beiden Punkten noch: Der Charme des "alten" Textes bestand (jedenfalls von der Richtung her) gerade darin, die Begriffe dann einzuführen, wenn sie benötigt wurden. Man hat also "by the way" eigentlich schon die Begrifflichkeiten dadurch erläutert, dass man sie funktional eingeführt hat. Das würde ich jedenfalls in diesem Dokument eigentlich gerne beibehalten wollen.

Der konkrete Ansatz war, das mit den Befehlen am Beispiel von "help" zu demonstrieren, allerdings kann es sein, dass hier etwas mehr an Erläuterung in der Tat gut wäre (hab's mir jetzt nicht direkt angesehen). Also (Infobox?): Sofern im Folgenden FHEM-Befehle wie ... verwendet werden, erhalten Sie hierzu durch Eingabe von "help <Befehl>" weitere Informationen zur Syntax und Verwendung dieses Befehls."

Aber es ist die einfachste Möglichkeit, wie ich einem User die Funktionsweise von FHEM näherbringen kann. Ohne Hardware zu benötigen. Und es gibt den schnellen "Wow, ich hab was geschafft"-Effekt der weiter oben schon mal erwähnt wurde. Was ganz einfaches nur. Klick auf Dummy1 und Dummy2 geht an. Oder so. Wir können dann ja in einem Nebensatz erwähnen, dass Dummys doof sind

Wenn jemand _unbedingt_ FHEM ohne HW ausprobieren will, kann er ja die "ersten Schritte" gehen, dann hat er genau diesen Effekt. Hat jemand konkrete HW, wird er die (bzw. erste Teile davon) kontrollieren wollen und über den (in diesem Fall eben unnötigen) Umweg wenig erfreut sein. Also: Bestenfalls bei der ersten konkreten Hardware (USB-Einführung) den Hinweis per Seitenkasten, dass er diesen Umweg gerne nehmen kann, von mir aus gerne verbunden mit dem Hinweis, dass Dummys in einer echten Umgebung eigentlich eher eine Randerscheinung sind bzw. sein sollten.

Gefühlt ist das für mich eher eine Konfigurationsoption als ein Device (auch wenn's technisch natürlich ein Device ist) und zeigt eigentlich nicht die Vorgehensweisen und Möglichkeiten eines "richtigen" Devices.

Mag sein, dass es an der Stelle recht abstrakt ist. Daher auch der Ansatz, das ganz wegzulassen und eben richtige Devices (USB+was auch immer) als erstes zu erläutern.

Du meinst sowas: <fhem-server>?

Ja, wobei ich eher gedanklich aus der Ecke komme, dass viele eine HmID haben, die "F11034" oder "F11234" ist. In diesen Fällen (war selbst betroffen ) scheinen die Betreffenden nicht mitbekommen zu haben, dass der konkrete Wert für eine FHT-Id im alten Howto bzw. dem Einsteiger-pdf eine willkürliche Angabe ist... Das sollte man halt bei der ersten Gelegenheit erläutern, an der sowas auftritt (s.o., ggf. bei "help").

[drhirn]

Na ja, an sich hatte ich gedacht, man könnte auf eine Art Glossar verweisen. Das gibt es sogar, allerdings sind da - jedenfalls auf den ersten Blick - zuviele Stichworte.

Ja, klar. Warum nicht.
Und ja, da gehört auf jeden Fall aufgeräumt

Der konkrete Ansatz war, das mit den Befehlen am Beispiel von "help" zu demonstrieren, allerdings kann es sein, dass hier etwas mehr an Erläuterung in der Tat gut wäre (hab's mir jetzt nicht direkt angesehen). Also (Infobox?): Sofern im Folgenden FHEM-Befehle wie ... verwendet werden, erhalten Sie hierzu durch Eingabe von "help <Befehl>" weitere Informationen zur Syntax und Verwendung dieses Befehls."

Finde ich gut!

Ja, wobei ich eher gedanklich aus der Ecke komme, dass viele eine HmID haben, die "F11034" oder "F11234" ist. In diesen Fällen (war selbst betroffen ) scheinen die Betreffenden nicht mitbekommen zu haben, dass der konkrete Wert für eine FHT-Id im alten Howto bzw. dem Einsteiger-pdf eine willkürliche Angabe ist... Das sollte man halt bei der ersten Gelegenheit erläutern, an der sowas auftritt (s.o., ggf. bei "help").

Dann müssten wir gleich am Anfang der Seite erklären, was mit diversen Formatierungs-Version gemeint ist. Und uns dann auch dran halten

[krikan]

- Zu Begriffserklärung habe ich kurz was geschrieben, das sollte ggf. ausgelagert werden (Link in Info-Kasten rechts?), über das wo habe ich mir noch keine Gedanken gemacht.

Habe ein wenig Sorge, dass bei der Definition Readings, Attributen,.. die xte Variante auftaucht. Mir gefällt das schon in "Erste Schritte" nicht.
Kann man nicht einfach auf die Definition in https://wiki.fhem.de/wiki/DevelopmentModuleIntro verlinken.
Letztlich entwickelt sich das auch. Rudis alte Definitionen von Attributen und Readings sind auch schon nicht mehr wirklich gültig. Das hat sich in andere Richtungen "verwässert".

- "by-id" propagiere ich selbst gerne, es führt aber an der Stelle m.E. zu weit.

habe einfach per Copy/Paste eine ZWDongle-Definition mit by-id hineinkopiert. Es ging mir nicht um by-id, als kann dort ruhig USB oder was auch immer stehen.

- Mit einem Dummy oder einem DOIF anzufangen, sehe ich sehr kritisch.

Ja. Dummy kann man sich bspw. in "Erste Schritte" anschauen.
Und DOIF halte ich auch nicht für ein ideales Einstiegs-Device.

[CoolTux]

Habe ein wenig Sorge, dass bei der Definition Readings, Attributen,.. die xte Variante auftaucht. Mir gefällt das schon in "Erste Schritte" nicht.
Kann man nicht einfach auf die Definition in https://wiki.fhem.de/wiki/DevelopmentModuleIntro verlinken.
Letztlich entwickelt sich das auch. Rudis alte Definitionen von Attributen und Readings sind auch schon nicht mehr wirklich gültig. Das hat sich in andere Richtungen "verwässert".habe einfach per Copy/Paste eine ZWDongle-Definition mit by-id hineinkopiert. Es ging mir nicht um by-id, als kann dort ruhig USB oder was auch immer stehen.Ja. Dummy kann man sich bspw. in "Erste Schritte" anschauen.
Und DOIF halte ich auch nicht für ein ideales Einstiegs-Device.

Oh je bitte nicht. Du möchtest nicht wirklich einem Anfänger das Developer Dokument lesen lassen? Macht das nicht, das verwirt noch viel mehr und der Anfänger denkt man muß programmieren können um Grundlagen des FHEM zu verstehen.