Benutzer Diskussion:Andies: Unterschied zwischen den Versionen

Aus FHEMWiki
(Willkommen "an Bord")
 
 
(11 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 43: Zeile 43:
[[Datei:Nuvola apps ksirc.png|25px|link=Benutzer Diskussion:Ph1959de]] &nbsp;&nbsp; '''Hast du Fragen an mich?''' Schreib mir auf [[Benutzer Diskussion:Ph1959de|<u>meiner</u> Diskussionsseite]]! Viele Grüße, [[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 00:06, 22. Feb. 2017 (CET)
[[Datei:Nuvola apps ksirc.png|25px|link=Benutzer Diskussion:Ph1959de]] &nbsp;&nbsp; '''Hast du Fragen an mich?''' Schreib mir auf [[Benutzer Diskussion:Ph1959de|<u>meiner</u> Diskussionsseite]]! Viele Grüße, [[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 00:06, 22. Feb. 2017 (CET)
|}
|}
== Änderungen am Artikel "Erste Schritte in FHEM" ==
Hallo!
Zunächst danke für Deine Mitarbeit am Wiki und bei FHEM. Aber -wie so oft im Leben- gibt es nur Rückmeldungen bei "Problemen" ;-) :
Hast Du Deine Änderungen am Artikel [[Erste Schritte in FHEM]], so wie im Vorwort zum Artikel erbeten, mit dem Verfasser Uli abgestimmt?
Die Änderungen widersprechen deutlich der Intention und dem Konzept des Artikels. Der Artikel soll nur einen kurzen Einstieg in FHEM geben; quasi einen "Vorgeschmack" auf FHEM liefern und nicht das Einsteiger-Pdf ersetzen.
Gruß, --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 13:51, 9. Mai 2017 (CEST)
Ja, habe ich abgestimmt. Ich hatte ihm vor einer Woche eine Mail geschrieben und er hat daraufhin OK gesagt, aber darum gebeten, es möglichst kurz zu halten. Kurze Nachfrage: Was genau ist der ''deutliche'' Widerspruch zur Intention?
--[[Benutzer:andies]] 14:09, 9. Mai 2017
<HR>
:Hallo andies!
:[[Erste_Schritte_in_FHEM#Grundbegriffe:_Device_und_Internal.2C_Attribut.2C_Reading]] geht meiner Meinung nach viel zu sehr in die Tiefe und ist gerade für einen groben Überblick nicht notwendig. Finde das persönlich eher verwirrend als hilfreich. Was interessiert mich bspw. beim ersten Kontakt mit FHEM, warum 98 vor einem Modul steht? Wofür muss man das für den schnellen Überblick wissen? Variablen, Zeichenketten, STATE, Readings, Internal, Attribut im "Vorwort" als Grundbegriffe schrecken mich ab. Das kommt doch im Artikelverlauf von selbst und muss man nicht schon im Vorhinein lesen. Der "device"-Erläuterung kann ich hingegen eine gewisse Notwendigkeit abgewinnen.
:Inhaltlich bin ich nicht im Detail eingestiegen, aber "Readings sollen während der Laufzeit vom Anwender" halte ich als Aussage für sehr gefährlich.
:Erlaube mir mal eine Gegenfrage: Hast Du beim Einstieg das Einsteiger-Pdf gelesen? Oder wie bist Du vorgegangen?
:Wenn Du die Änderungen mit Uli abgestimmt hast, ist das Ok und ich bin ruhig :-).
:Gruß, --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 15:28, 9. Mai 2017 (CEST)
<HR>
::Danke für die konstruktive Antwort; dann lass uns diskutieren! Ich erzähle mal, wieso ich das geschrieben habe und dann schauen wir, was wir am Ende daraus machen. Das wird jetzt aber ein längerer Text (Wir können das auch im Forum diskutieren, wäre das besser? Wenn ja, dann nimm einfach den Link, den ich da angegeben habe: https://forum.fhem.de/index.php/topic,71397.0.html). Ich habe mit FHEM angefangen, weil ich ein ganz konkretes Problem hatte, dass ich mit anderen Servern nicht habe lösen können (Garage übers Internet schalten, Rolladen auch) und ich glaube, dass das typisch ist - jedenfalls war das der Eindruck, den ich von einem Treffen in Berlin hatte. Dann habe ich die Einsteiger-PDF gelesen und hatte "irgendwie" Ahnung, wie das geht. Dann habe ich meine Rolladen in Griff gehabt und eigentlich wäre dann alles gut gewesen. Wäre ich da stehen geblieben, hätte ich den Wiki-Eintrag ''nicht'' verändert.
:: Der nächste Schritt war dann, dass ich (wie wahrscheinlich einige hier) Blut geleckt hatte. Nun sollte also auch noch der Stromverbrauch erfasst werden etc. Und auf einmal fingen die Probleme an. Ich habe zum Beispiel aus dem Wiki-Eintrag nicht verstanden, was überhaupt ein Attribut ist. Ständig wollte ich mit ReadingsVal die Werte der Attribute auslesen und bekam auch mal den Anpfiff: "Lies mal die commandref". Wenn man aber noch nie mit Perl programmiert hat, kapiert man das auch nach dem zehnten Lesen nicht. Hinzu kommt, dass einige Dinge so erklärt sind, dass für einen Anfänger ein Verständnis nahezu unmöglich wird; einige Wiki-Einträge sind ja wirklich verwaist. Also habe ich überlegt: Warum kapiere ich das nicht? Dann wurde mir klar, weil zum einen recht viele kleine Schusselfehler in der Einleitung stehen (zum Beispiel "Reading 'STATE'", wo es doch ein Internal ist oder man das Reading 'state' meint etc pp - so etwas verwirrt einen Anfänger total!) und zum anderen weil mehrere Grundbegriffe nicht vernünftig erklärt sind (zum Beispiel: "Nur Readings können von Menschen gelesen werden" - Internals auch!). Hinzu kommt, dass in der Einleitung zwar steht, was man genau tun soll ("tipp mal attr XY room sowieso" ein und dann siehst du was), aber nicht erklärt wird, ''was'' man da eigentlich macht - nämlich ein Attribut setzen und einen Wert zuweisen. Deshalb habe ich mich dran gesetzt und überlegt, was '''für mich''' wichtig gewesen wäre.
:: Nun zur Debatte. Was für mich wichtig ist, kann für andere verwirrend sein. Sehe ich sofort ein. Also lass uns im Detail diskutieren, was am Text verändert wird (nochmal: eventuell im Forum?). Das mit der Zeichenkette verstehe ich, das mit den Definitionen der Grundbegriffe finde ich aber wesentlich. Wir sollten vielleicht so debattieren: Was wollen wir beim Anfänger erreichen? Welches Vorwissen müssen wir voraussetzen, was nicht? Ich gehe davon aus, dass der typische Anwender mit einem ganz konkreten Problem zu FHEM stößt und zuerst das gelöst haben will. Dass er wenige Programmierkenntnisse besitzt und auch bereit ist, gewisses Leid in Kauf zu nehmen. Wir können aber nicht voraussetzen (auch wenn das der eine oder andere meint), dass er die gesamte Einsteiger-PDF verstanden, die commandref gelesen und verstanden hat und außerdem mit RegEx problemlos umgehen kann. Wenn wir uns bei der Beschreibung der Person, die den Wiki-Eintrag liest, einig sind, sollte sich ein besserer Text ergeben. Das man dabei sinnvollerweise vermeidet, bereits in der Einleitung eine Debatte zum Sinn und Unsinn von DOIF zu haben, ist auch mir Anfänger klar.
<HR>
:::Zum Diskussionsort: Mir ist es letztlich gleich. Hier wird es vmtl. nur ruhiger und mit weniger Beteiligung als im Forum zu gehen.
:::Also bist Du zum Einstieg mit dem Artikel "Erste Schritte in FHEM" problemlos klargekommen; erst als es weiter in die Tiefe ging, kamen die weiteren Probleme!? Daraus schließe ich zunächst einmal frech, dass der Artikel seinen Zweck erfüllt hat: Ein "Appetitanreger" auf FHEM, der erste Erfolgserlebnisse und erstes Verständniss schafft. Mehr soll er meiner Meinung nach auch nicht. Der Einsteiger soll sich in kurzer Zeit einen Überblick verschaffen (Zeitbedarf max. 60 Minuten): Ist FHEM etwas für mich? Wie geht das grundlegend? Wenn man neugierig geworden ist, dann weiterlernen.
:::Tippfehler und Co. (state vs. STATE) sollten im Artikel natürlich behoben werden. Mit Deinen weiterführenden Erläuterungen insb. Grundbegriffe, die Du nach den ersten Erfolgserlebnissen vermisst hast, steigt der Zeitbedarf für die Durcharbeitung und auch die Komplexität des Artikels deutlich. Er verliert damit eben seine eigentliche Intention. Das, was unter Grundbegriffe steht braucht man zum Einstieg nicht und verwirrt. Er entwickelt sich mMn dadurch in Richtung universellen Einsteiger-PDF Ersatz. Weitergehende Informationen könnte man aus dem Artikel ja verlinken statt sie darin aufzunehmen; aber selbst dabei bin ich zweifelnd, da es schnell zum Verzetteln in Details führt.
:::Auch Deine Definition der Grundbegriffe ist, wie Du im Forum liest, nicht unumstritten. Und die Bedenken kommen nicht von irgendjemanden, sondern von einem der Kern-Developer. Einen Punkt hatte ich gestern auch schon herausgepickt (Readings), den ich persönlich für gefährlich oder eher sogar falsch halte. Zudem existieren schon Definitionen der Begriffe im Wiki, die man verlinken könnte. Warum sollten wir 2 Definitionen im Wiki pflegen? Das ist zu pflegeaufwendig. Das ist aber auch eine Macke von mir: [https://wiki.fhem.de/w/index.php?title=SIGNALduino&diff=prev&oldid=21335] würde ich z.B. nicht so ausführlich machen, sondern auf [[Trick_der_Woche#CUL_.26_CO_.C3.BCber_Serial_ID-einbinden]] verlinken. Dadurch sind Fehler/Änderungen nur an einer Stelle zu berücksichtigen.
:::Wo steht eigentlich: "Nur Readings können von Menschen gelesen werden" ?
:::Was für Dich wichtig ist, liegt doch an Deinem Wissensstand. Zunächst hat der Einsteiger-Artikel gereicht. Dann ist man weiter und liest das Pdf. Und dann kommen Fragen und noch mehr Fragen. Damit bin ich wieder beim Ausgangspunkt, dass Deine Erläuterungen schon für Fortgeschrittenere sind und nicht in den genannten Artikel sollten ;-).
:::Was ich voraussetze? Nichts außer Lernbereitschaft. Dazu gehört auch, dass man sich zumindest mal Grundzüge von Perl anschaut. (Bin selbst kein Entwickler und werde keiner, sondern nur Anwender) Ohne Regex und Co. ist FHEM schwer  "verdaulich". Das z.B. tritt mir mittlerweile zu sehr in den Hintergrund.
:::Mir persönlich wäre es am Liebsten den Einsteiger-Artikel in die Kurzform zurückzubringen und Deine Überlegungen möglichst redudanzfrei in weiterführende Artikel zu packen oder in Ulis Einsteiger-Pdf einzubringen, falls er Hilfe mag. Was ich nicht möchte ist: Dich entmutigen und von der Mitarbeit abbringen, das wird nämmlich schnell so aufgefasst. Und meine Meinung muss auch nicht die Richtige sein, wenn es die überhaut gibt.
:::Gruß, --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 11:14, 10. Mai 2017 (CEST)
:::PS: (Langfristiges) Ziel ist bspw. [[FHEM_Installation_Windows]] und [[Erste Schritte in FHEM]] so zu gestalten, dass als Einsteiger ein Test von FHEM angefangen bei Installation bis zum Ende der ersten Experimente in ca. 90 Minuten möglich ist.
<HR>
::::Was ist davon zu halten, wenn wir den Grundbegriffe-Artikel zu einem Absatz mit ein, zwei Sätzen zusammenkürzen und den Inhalt auf weiterführende Seiten verschieben? Das wäre dann, in schlechtem Deutsch von der Idee her so: "Also wir legen jetzt mal los und wir brauchen dazu Attribute und Readings (was das ist, kannst du HIER nachlesen), aber erst einmal reicht <XYZ>"? Das können wir bei den anderen Abschnitten, bei denen Du Probleme hast, auch machen. Ich würde mir dann mal was überlegen und das hier vorstellen? Es wäre aber wegen der reparierten Schreibfehler vermutlich einfacher, wenn wir diesen Abschnitt _bearbeiten_ und _nicht_ zurückstellen, denn ich weiß nicht mehr, welche Fehler ich genau geändert habe.
<HR>
:::::Ich mache nichts einfach rückgängig, wir diskutieren doch: Ändere es einfach einmal so ab, wie Du es dann machen würdest. Im Übrigen bin ich nicht der Nabel der Welt, aber habe ein Meinung :-) . Am meisten stören mich die "Grundbegriffe". --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 16:08, 10. Mai 2017 (CEST)
<HR>
::::PS Aus dem Wiki: "Daten, welche von einem Gerät gelesen werden und in FHEM in einer für Menschen verständlichen Form zur Verfügung gestellt werden können, werden Readings genannt". Der Logiker schließt daraus, dass Internals für Menschen nicht verständlich sind (jedenfalls habe ich mich das wirklich gefragt: gilt etwa Readings = UTF-8, Internals = binär o.Ä?!)
<HR>
:::::Halte ich für eine erhebliche Überinterpretation der Aussage. Es wird doch nirgends eine Verbindung oder gar Vergleich zwischen Internals und Readings hergestellt und schon gar nicht, in welcher ihrer Merkmale/Eigenschaften aus Anwendersicht ein Gegensatz besteht. Eine klare und eindeutige Definition der Begriffe ist nicht so einfach und letztlich auch im Fluß. Zudem versuchst Du Begrifflichkeiten, die mMn eher aus Entwicklersicht entstanden sind, in ein Schema der Anwendersicht zu pressen. Ein bedeutendes Gegenbeispiel Deiner Definition finde ich beispielsweise auf die Schnelle noch bei Internals. Du schreibst: "Internals sollen vom Nutzer nicht direkt verändert werden". Das ist so vereinfacht in einem wesentlichen Punkt falsch. Das DEF in den Internals soll gerade von Einsteigern genutzt werden und nicht die manuelle Editierei in der fhem.cfg (siehe bspw. [[Konfiguration#Objektdetails]]). Die Nutzung des DEF wollen wir gerade den Einsteigern krampfhaft vermitteln; jetzt verbieten wir es aber bereits in der Definition im "Vorwort" des Einsteiger-Artikels. Das verwirrt sicherlich. Wenn Du das dann gerade ziehen willst, musst Du noch mehr erklären. Das führt zu mehr Verwirrung. Darum eben besser Definitionen weglassen. --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 16:08, 10. Mai 2017 (CEST)
<HR>
::::::Ich brauche, was die anderen Dinge angeht, etwas Zeit zum überarbeiten. Aber zur Überinterpretation kann ich sofort was sagen: Natürlich ist das erheblich überinterpretiert. Aber das ist genau der Punkt. Denn ich finde, wir müssen kontrollieren, welche Interpretationen möglich sind (wobei die Grenze, welches Vorwissen man voraussetzt, schwer zu ziehen ist). Anders gesagt: Gäbe es eine Möglichkeit, den Text anders zu formulieren, so dass zum einen solche Überinterpretationen nicht mehr möglich werden, trotzdem der Text lesbar bleibt und drittens die Information immer noch übermittelt wird? Und hier denke ich, dass es diese Möglichkeit durchaus gibt oder wir zumindest daran arbeiten sollten. (Nur ich kann heute und wahrscheinlich morgen nicht...)
[[Benutzer:andies|andies]] ([[Benutzer Diskussion:andies|Diskussion]]) 10:50, 12. Mai 2017 (CEST)
<HR>
Obige Diskussion zur besseren Nachvollziehbarkeit komplett nach [[Diskussion:Erste_Schritte_in_FHEM]] kopiert. Weitere Beiträge bitte dort. --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 10:44, 12. Mai 2017 (CEST)

Aktuelle Version vom 12. Mai 2017, 09:48 Uhr

Willkommen!

Hallo Andies, willkommen im FHEM Wiki!
Danke für dein Interesse an unserem Projekt, ich freue mich schon auf deine weiteren Beiträge. Die folgenden Seiten sollten dir die ersten Schritte erleichtern, bitte nimm dir daher etwas Zeit, sie zu lesen.

FHEM-spezifische Informationen

  Systemübersicht
FHEM Systemübersicht
  FHEMWiki:Über FHEMWiki
Informationen über dieses Wiki

Generelle Informationen über (Media)Wikis

Crystal Clear app kedit.svg
Hilfe:Bearbeiten
Zugang zu allen wichtigen Informationen.
X-office-presentation.svg
Wikipedia:Tutorial
Schritt-für-Schritt-Anleitung für Einsteiger.
Applications-system.svg
Wikipedia:Grundprinzipien
Die grundlegende Philosophie unseres Projekts.
MentorenProgrammLogo-7.svg
Wikipedia:Mentorenprogramm
Persönliche Einführung in die Beteiligung bei Wikipedia.

Bitte beachte, was Wikipedia nicht ist, und "unterschreibe" deine Diskussionsbeiträge durch Eingabe von --~~~~ oder durch Drücken der Schaltfläche Signaturknopf über dem Bearbeitungsfeld. Artikel werden jedoch nicht unterschrieben, und wofür die Zusammenfassungszeile da ist, erfährst du unter Zusammenfassung und Quellen.

Nuvola apps ksirc.png    Hast du Fragen an mich? Schreib mir auf meiner Diskussionsseite! Viele Grüße, Peter (Diskussion) 00:06, 22. Feb. 2017 (CET)

Änderungen am Artikel "Erste Schritte in FHEM"

Hallo!

Zunächst danke für Deine Mitarbeit am Wiki und bei FHEM. Aber -wie so oft im Leben- gibt es nur Rückmeldungen bei "Problemen" ;-) :

Hast Du Deine Änderungen am Artikel Erste Schritte in FHEM, so wie im Vorwort zum Artikel erbeten, mit dem Verfasser Uli abgestimmt?

Die Änderungen widersprechen deutlich der Intention und dem Konzept des Artikels. Der Artikel soll nur einen kurzen Einstieg in FHEM geben; quasi einen "Vorgeschmack" auf FHEM liefern und nicht das Einsteiger-Pdf ersetzen.

Gruß, --Christian (Diskussion) 13:51, 9. Mai 2017 (CEST)


Ja, habe ich abgestimmt. Ich hatte ihm vor einer Woche eine Mail geschrieben und er hat daraufhin OK gesagt, aber darum gebeten, es möglichst kurz zu halten. Kurze Nachfrage: Was genau ist der deutliche Widerspruch zur Intention?

--Benutzer:andies 14:09, 9. Mai 2017


Hallo andies!
Erste_Schritte_in_FHEM#Grundbegriffe:_Device_und_Internal.2C_Attribut.2C_Reading geht meiner Meinung nach viel zu sehr in die Tiefe und ist gerade für einen groben Überblick nicht notwendig. Finde das persönlich eher verwirrend als hilfreich. Was interessiert mich bspw. beim ersten Kontakt mit FHEM, warum 98 vor einem Modul steht? Wofür muss man das für den schnellen Überblick wissen? Variablen, Zeichenketten, STATE, Readings, Internal, Attribut im "Vorwort" als Grundbegriffe schrecken mich ab. Das kommt doch im Artikelverlauf von selbst und muss man nicht schon im Vorhinein lesen. Der "device"-Erläuterung kann ich hingegen eine gewisse Notwendigkeit abgewinnen.
Inhaltlich bin ich nicht im Detail eingestiegen, aber "Readings sollen während der Laufzeit vom Anwender" halte ich als Aussage für sehr gefährlich.
Erlaube mir mal eine Gegenfrage: Hast Du beim Einstieg das Einsteiger-Pdf gelesen? Oder wie bist Du vorgegangen?
Wenn Du die Änderungen mit Uli abgestimmt hast, ist das Ok und ich bin ruhig :-).
Gruß, --Christian (Diskussion) 15:28, 9. Mai 2017 (CEST)

Danke für die konstruktive Antwort; dann lass uns diskutieren! Ich erzähle mal, wieso ich das geschrieben habe und dann schauen wir, was wir am Ende daraus machen. Das wird jetzt aber ein längerer Text (Wir können das auch im Forum diskutieren, wäre das besser? Wenn ja, dann nimm einfach den Link, den ich da angegeben habe: https://forum.fhem.de/index.php/topic,71397.0.html). Ich habe mit FHEM angefangen, weil ich ein ganz konkretes Problem hatte, dass ich mit anderen Servern nicht habe lösen können (Garage übers Internet schalten, Rolladen auch) und ich glaube, dass das typisch ist - jedenfalls war das der Eindruck, den ich von einem Treffen in Berlin hatte. Dann habe ich die Einsteiger-PDF gelesen und hatte "irgendwie" Ahnung, wie das geht. Dann habe ich meine Rolladen in Griff gehabt und eigentlich wäre dann alles gut gewesen. Wäre ich da stehen geblieben, hätte ich den Wiki-Eintrag nicht verändert.
Der nächste Schritt war dann, dass ich (wie wahrscheinlich einige hier) Blut geleckt hatte. Nun sollte also auch noch der Stromverbrauch erfasst werden etc. Und auf einmal fingen die Probleme an. Ich habe zum Beispiel aus dem Wiki-Eintrag nicht verstanden, was überhaupt ein Attribut ist. Ständig wollte ich mit ReadingsVal die Werte der Attribute auslesen und bekam auch mal den Anpfiff: "Lies mal die commandref". Wenn man aber noch nie mit Perl programmiert hat, kapiert man das auch nach dem zehnten Lesen nicht. Hinzu kommt, dass einige Dinge so erklärt sind, dass für einen Anfänger ein Verständnis nahezu unmöglich wird; einige Wiki-Einträge sind ja wirklich verwaist. Also habe ich überlegt: Warum kapiere ich das nicht? Dann wurde mir klar, weil zum einen recht viele kleine Schusselfehler in der Einleitung stehen (zum Beispiel "Reading 'STATE'", wo es doch ein Internal ist oder man das Reading 'state' meint etc pp - so etwas verwirrt einen Anfänger total!) und zum anderen weil mehrere Grundbegriffe nicht vernünftig erklärt sind (zum Beispiel: "Nur Readings können von Menschen gelesen werden" - Internals auch!). Hinzu kommt, dass in der Einleitung zwar steht, was man genau tun soll ("tipp mal attr XY room sowieso" ein und dann siehst du was), aber nicht erklärt wird, was man da eigentlich macht - nämlich ein Attribut setzen und einen Wert zuweisen. Deshalb habe ich mich dran gesetzt und überlegt, was für mich wichtig gewesen wäre.
Nun zur Debatte. Was für mich wichtig ist, kann für andere verwirrend sein. Sehe ich sofort ein. Also lass uns im Detail diskutieren, was am Text verändert wird (nochmal: eventuell im Forum?). Das mit der Zeichenkette verstehe ich, das mit den Definitionen der Grundbegriffe finde ich aber wesentlich. Wir sollten vielleicht so debattieren: Was wollen wir beim Anfänger erreichen? Welches Vorwissen müssen wir voraussetzen, was nicht? Ich gehe davon aus, dass der typische Anwender mit einem ganz konkreten Problem zu FHEM stößt und zuerst das gelöst haben will. Dass er wenige Programmierkenntnisse besitzt und auch bereit ist, gewisses Leid in Kauf zu nehmen. Wir können aber nicht voraussetzen (auch wenn das der eine oder andere meint), dass er die gesamte Einsteiger-PDF verstanden, die commandref gelesen und verstanden hat und außerdem mit RegEx problemlos umgehen kann. Wenn wir uns bei der Beschreibung der Person, die den Wiki-Eintrag liest, einig sind, sollte sich ein besserer Text ergeben. Das man dabei sinnvollerweise vermeidet, bereits in der Einleitung eine Debatte zum Sinn und Unsinn von DOIF zu haben, ist auch mir Anfänger klar.

Zum Diskussionsort: Mir ist es letztlich gleich. Hier wird es vmtl. nur ruhiger und mit weniger Beteiligung als im Forum zu gehen.
Also bist Du zum Einstieg mit dem Artikel "Erste Schritte in FHEM" problemlos klargekommen; erst als es weiter in die Tiefe ging, kamen die weiteren Probleme!? Daraus schließe ich zunächst einmal frech, dass der Artikel seinen Zweck erfüllt hat: Ein "Appetitanreger" auf FHEM, der erste Erfolgserlebnisse und erstes Verständniss schafft. Mehr soll er meiner Meinung nach auch nicht. Der Einsteiger soll sich in kurzer Zeit einen Überblick verschaffen (Zeitbedarf max. 60 Minuten): Ist FHEM etwas für mich? Wie geht das grundlegend? Wenn man neugierig geworden ist, dann weiterlernen.
Tippfehler und Co. (state vs. STATE) sollten im Artikel natürlich behoben werden. Mit Deinen weiterführenden Erläuterungen insb. Grundbegriffe, die Du nach den ersten Erfolgserlebnissen vermisst hast, steigt der Zeitbedarf für die Durcharbeitung und auch die Komplexität des Artikels deutlich. Er verliert damit eben seine eigentliche Intention. Das, was unter Grundbegriffe steht braucht man zum Einstieg nicht und verwirrt. Er entwickelt sich mMn dadurch in Richtung universellen Einsteiger-PDF Ersatz. Weitergehende Informationen könnte man aus dem Artikel ja verlinken statt sie darin aufzunehmen; aber selbst dabei bin ich zweifelnd, da es schnell zum Verzetteln in Details führt.
Auch Deine Definition der Grundbegriffe ist, wie Du im Forum liest, nicht unumstritten. Und die Bedenken kommen nicht von irgendjemanden, sondern von einem der Kern-Developer. Einen Punkt hatte ich gestern auch schon herausgepickt (Readings), den ich persönlich für gefährlich oder eher sogar falsch halte. Zudem existieren schon Definitionen der Begriffe im Wiki, die man verlinken könnte. Warum sollten wir 2 Definitionen im Wiki pflegen? Das ist zu pflegeaufwendig. Das ist aber auch eine Macke von mir: [1] würde ich z.B. nicht so ausführlich machen, sondern auf Trick_der_Woche#CUL_.26_CO_.C3.BCber_Serial_ID-einbinden verlinken. Dadurch sind Fehler/Änderungen nur an einer Stelle zu berücksichtigen.
Wo steht eigentlich: "Nur Readings können von Menschen gelesen werden" ?
Was für Dich wichtig ist, liegt doch an Deinem Wissensstand. Zunächst hat der Einsteiger-Artikel gereicht. Dann ist man weiter und liest das Pdf. Und dann kommen Fragen und noch mehr Fragen. Damit bin ich wieder beim Ausgangspunkt, dass Deine Erläuterungen schon für Fortgeschrittenere sind und nicht in den genannten Artikel sollten ;-).
Was ich voraussetze? Nichts außer Lernbereitschaft. Dazu gehört auch, dass man sich zumindest mal Grundzüge von Perl anschaut. (Bin selbst kein Entwickler und werde keiner, sondern nur Anwender) Ohne Regex und Co. ist FHEM schwer "verdaulich". Das z.B. tritt mir mittlerweile zu sehr in den Hintergrund.
Mir persönlich wäre es am Liebsten den Einsteiger-Artikel in die Kurzform zurückzubringen und Deine Überlegungen möglichst redudanzfrei in weiterführende Artikel zu packen oder in Ulis Einsteiger-Pdf einzubringen, falls er Hilfe mag. Was ich nicht möchte ist: Dich entmutigen und von der Mitarbeit abbringen, das wird nämmlich schnell so aufgefasst. Und meine Meinung muss auch nicht die Richtige sein, wenn es die überhaut gibt.
Gruß, --Christian (Diskussion) 11:14, 10. Mai 2017 (CEST)
PS: (Langfristiges) Ziel ist bspw. FHEM_Installation_Windows und Erste Schritte in FHEM so zu gestalten, dass als Einsteiger ein Test von FHEM angefangen bei Installation bis zum Ende der ersten Experimente in ca. 90 Minuten möglich ist.

Was ist davon zu halten, wenn wir den Grundbegriffe-Artikel zu einem Absatz mit ein, zwei Sätzen zusammenkürzen und den Inhalt auf weiterführende Seiten verschieben? Das wäre dann, in schlechtem Deutsch von der Idee her so: "Also wir legen jetzt mal los und wir brauchen dazu Attribute und Readings (was das ist, kannst du HIER nachlesen), aber erst einmal reicht <XYZ>"? Das können wir bei den anderen Abschnitten, bei denen Du Probleme hast, auch machen. Ich würde mir dann mal was überlegen und das hier vorstellen? Es wäre aber wegen der reparierten Schreibfehler vermutlich einfacher, wenn wir diesen Abschnitt _bearbeiten_ und _nicht_ zurückstellen, denn ich weiß nicht mehr, welche Fehler ich genau geändert habe.

Ich mache nichts einfach rückgängig, wir diskutieren doch: Ändere es einfach einmal so ab, wie Du es dann machen würdest. Im Übrigen bin ich nicht der Nabel der Welt, aber habe ein Meinung :-) . Am meisten stören mich die "Grundbegriffe". --Christian (Diskussion) 16:08, 10. Mai 2017 (CEST)

PS Aus dem Wiki: "Daten, welche von einem Gerät gelesen werden und in FHEM in einer für Menschen verständlichen Form zur Verfügung gestellt werden können, werden Readings genannt". Der Logiker schließt daraus, dass Internals für Menschen nicht verständlich sind (jedenfalls habe ich mich das wirklich gefragt: gilt etwa Readings = UTF-8, Internals = binär o.Ä?!)

Halte ich für eine erhebliche Überinterpretation der Aussage. Es wird doch nirgends eine Verbindung oder gar Vergleich zwischen Internals und Readings hergestellt und schon gar nicht, in welcher ihrer Merkmale/Eigenschaften aus Anwendersicht ein Gegensatz besteht. Eine klare und eindeutige Definition der Begriffe ist nicht so einfach und letztlich auch im Fluß. Zudem versuchst Du Begrifflichkeiten, die mMn eher aus Entwicklersicht entstanden sind, in ein Schema der Anwendersicht zu pressen. Ein bedeutendes Gegenbeispiel Deiner Definition finde ich beispielsweise auf die Schnelle noch bei Internals. Du schreibst: "Internals sollen vom Nutzer nicht direkt verändert werden". Das ist so vereinfacht in einem wesentlichen Punkt falsch. Das DEF in den Internals soll gerade von Einsteigern genutzt werden und nicht die manuelle Editierei in der fhem.cfg (siehe bspw. Konfiguration#Objektdetails). Die Nutzung des DEF wollen wir gerade den Einsteigern krampfhaft vermitteln; jetzt verbieten wir es aber bereits in der Definition im "Vorwort" des Einsteiger-Artikels. Das verwirrt sicherlich. Wenn Du das dann gerade ziehen willst, musst Du noch mehr erklären. Das führt zu mehr Verwirrung. Darum eben besser Definitionen weglassen. --Christian (Diskussion) 16:08, 10. Mai 2017 (CEST)

Ich brauche, was die anderen Dinge angeht, etwas Zeit zum überarbeiten. Aber zur Überinterpretation kann ich sofort was sagen: Natürlich ist das erheblich überinterpretiert. Aber das ist genau der Punkt. Denn ich finde, wir müssen kontrollieren, welche Interpretationen möglich sind (wobei die Grenze, welches Vorwissen man voraussetzt, schwer zu ziehen ist). Anders gesagt: Gäbe es eine Möglichkeit, den Text anders zu formulieren, so dass zum einen solche Überinterpretationen nicht mehr möglich werden, trotzdem der Text lesbar bleibt und drittens die Information immer noch übermittelt wird? Und hier denke ich, dass es diese Möglichkeit durchaus gibt oder wir zumindest daran arbeiten sollten. (Nur ich kann heute und wahrscheinlich morgen nicht...)
andies (Diskussion) 10:50, 12. Mai 2017 (CEST)

Obige Diskussion zur besseren Nachvollziehbarkeit komplett nach Diskussion:Erste_Schritte_in_FHEM kopiert. Weitere Beiträge bitte dort. --Christian (Diskussion) 10:44, 12. Mai 2017 (CEST)