FHEM Forum

Hallo!

Hat jemand Zeit und Lust mich bei der Übernahme und Aktualisierung von https://fhem.de/HOWTO_DE.html bzw. https://fhem.de/HOWTO.html in unser Wiki zu unterstützen?
Insbesondere (aber nicht nur) bei der Aktualisierung des Abschnitts https://fhem.de/HOWTO.html#security könnte ich Hilfe gebrauchen (siehe auch https://forum.fhem.de/index.php/topic,72629.0/all.html).

Gruß, Christian

ICh würde mich grundsätzlich gerne beteiligen , zumal ich auf der ein oder anderen Seite ein Beispiel vermisse ;-)

Hallo Christian,

ich bin auch bereit. Ich verstehe noch nicht genau was zu tun ist, aber wenn ich helfen kann.

Gruß Otto

ZitatIch verstehe noch nicht genau was zu tun ist, aber wenn ich helfen kann.

Hallo Otto, aruttkamp und @all!

Die Seiten https://fhem.de/HOWTO_DE.html und https://fhem.de/HOWTO.html sollen von fhem.de ins Wiki verlagert werden. fhem.de soll anschließend nur noch auf die entsprechenden Wiki-Seiten verlinken.
Ziel ist im Endeffekt fhem.de als Landing-Page mit Verlinkungen ins Wiki zu nutzen. Bei HOWTO_Windows und anderen fhem.de Unterseiten habe ich damit schon angefangen bzw. bin durch.

Mit den beiden hier angesprochenen Seiten habe ich noch nicht begonnen, da sich meine FHEM-Prios momentan ein wenig verschoben haben und die Seiten umfangreicherer Überarbeitung bedürfen.

Wer mag, kann gerne mit eigenen Ideen loslegen.  :)

Btw. Für die Übersetzung von Erste Schritte in FHEM (https://wiki.fhem.de/wiki/Erste_Schritte_in_FHEM) ins Englische https://wiki.fhem.de/wiki/First_steps_in_FHEM brauchen wir auch noch dringend Hilfe.

Gruß, Christian

Da das Thema nach wie vor aktuell ist, und sich anscheinend niemand so recht berufen fühlt, mal meine Gedanken zum Thema.

"An sich" war ich grade dabei, mir das HOWTO_DE mal anzusehen, ob und wie man das überarbeiten kann. Zu einem richtigen Ergebnis bin ich nicht gekommen, will aber mal folgende Punkte und Anknüpfungspunkte an bestehende Elemente der Doku zur Diskussion stellen:

1. Das "Erste Schritte" im Wiki ist ziemlich gut und greift ganz viele Teile aus dem Howto auf, nicht enthalten sind folgende Themen:

a) USB-Devices (automatische Erkennung, die man m.E. nach dem ersten erfolgreichen Durchlauf abschalten sollte).
b) autocreate von "echten" physischen Devices, wenn diese über ein definiertes IO reinkommen
c) Loggen, plotten, structure und Watchdog
d) Sicherheit
e) FHEMWEB

2. Gar nicht (im Howto) enthalten sind Hinweise auf die Bedeutung von perl, regex &Co.. Da würde sich m.E. ein Link auf die entsprechenden Abschnitte in der commandref und http://regex101.com/ anbieten, zur Frage wo s.u..

3. In den "Ersten Schritten" etwas "kurz" kommt m.E. der Hinweis, dass die Geräte des Typs "dummy" hier vorrangig deswegen verwendet werden, weil man ja gerade keine Hardware hat. Für echte Hardware ist an der Stelle ein deutlicher Hinweis (Kasten?) zu empfehlen, die entsprechenden Attribute direkt bei den Hardware-Devices zu setzen, wobei ich da gleich auf die Option hinweisen würde, weitere Attribute mit "userattr" zu definieren, in denen dann benutzerdefinierte Angaben gespeichert werden können. M.E. ist der vorrangige Zweck von "Dummy" in einem "echten" FHEM, allgemeine, nicht auf einzelne Geräte bezogene Informationen zu speichern (das mag aber darin begründet liegen, dass ich kein anderes Frontend nutze).

4. Outdates im Howto:
a) Da ist ziemlich viel von Fritzbox die Rede - m.E. ist das mittlerweile überholt und kann/sollte raus.
b) FS20 ist auch nicht mehr taufrisch => auf die Darstellung eines konkreten HW-Systems ganz verzichten?

5. Vorschlag für eine neue Struktur bzw. Änderungen:
a) Howto: nur noch eine erste Anlaufstelle (als eine Art Linksammlung) mit folgenden Themen (*=(ggf neuer) separater Artikel, @=Link):
-- Installation (Linux: @Debian-way bzw. mit *make, @Windows, *MacOS (?))
-- @"Erste Schritte"
-- *Security (update auf "allowed", vpn + reverseProxy (kein Portforwarding!))
-- *Automatisches Einbinden von USB-Interfaces und autocreate darüber hereinkommender Devices (mit Verweis auf die entsprechenden Hardwaresysteme und die Darstellung dort - ggf. wäre hier exemplarisch auf HM (BidCoS), Z-Wave und FS20 einzugehen bzw. auf die dortigen "Einstiegsseiten" (sofern vorhanden?) zu verlinken.
-- *Perl und Regex
-- Link auf "Einsteiger-pdf" (in dem sind obige Themen angerissen, es kommen aber auch Loggen, plotten, structure und Watchdog vor (ungeprüft). Das das m.E. eigentlich völlig ausreichend, man könnte das aber auch im Rahmen einer
-- Linkliste mit nützlichen Basis-Modulen machen. (Was im pdf drin ist, ggf. noch Threshold?) Diese könnte man erweitern mit Wiki-Artikeln, die man kennen sollte (Event-Monitor!)
-- GUI ist was, was viele vielleicht an der Stelle noch interessiert (incl. Floorplan usw.). M.E. ist es ausreichend, nur auf eine allg. Wikidarstellung der unterschiedlichen Angebote zu verweisen (?)

b) Einsteiger-pdf:
Ist ja eigentlich super, und kann/sollte auch weiterhin eine zentrale Rolle spielen. Aber die dortige Darstellung des Editierens der .cfg und #include sind in jedem Fal überholt, ob man Floorplan an der Stelle schon braucht, darüber kann man vermutlich lange diskutieren.
Nicht mehr so prickelnd finde ich FS20 als Beispielsystem, und die Darstellung von HM ist zwar auch super und hat mir viel geholfen, aber das würde ich dennoch mittlerweile (wieder?) als getrenntes Dokument sehen für Leute, die damit einsteigen wollen.
Rein sollte dafür die Option mit dem raw-Import von mehreren Codezeilen (ich bin nicht der einzige, der telnet noch nie benutzt hat...).

c) Erste Schritte:
Funktion von Dummy klarstellen (s.o.).

Das war's für's erste. Ich übernehme da gerne den einen oder anderen Teil, aber einiges weiß ich nicht bzw. kann nicht beurteilen, ob die Vorschläge in die falsche Richtung gehen.

Gruß, Beta-User

Hi,

mir geht es da ähnlich wie Beta-User, ich nehme immer mal wieder Anlauf, stelle fest es wird zu groß und mache dann für mich sowas (https://heinz-otto.blogspot.de/2018/02/in-fhem-externe-programme-aufrufen.html) weil ich es gerade brauche und endlich mal verstehen will. Dann denke ich schon beim Schreiben dran, das muss eigentlich an entsprechende Stelle ins Wiki oder ins HowTo. Aber dann steht da wieder die große ungelöste Struktur im Raum ...

Ich unterstütze den Vorschlag, das HowTo ziemlich einfach (und Hardware unspezifisch) zu lassen. Es wird relativ statisch sein, also muss da bloß die Orientierung rein.

Soll man jetzt dazu einfach mal ein HTML als Vorschlag verfassen?

Zum Punkt 1 a) von Beta-User ich meine man muss es vorm ersten Lauf abschalten sonst ist es zu spät und FHEM klemmt. Ist mittlerweile beim nackten Raspberry mit einem BT Stick dran so. (Probing CUL device /dev/ttyAMA0 ein paar Einträge und Perl bei 100%)

Gruß Otto

ZitatSoll man jetzt dazu einfach mal ein HTML als Vorschlag verfassen?

Die HOWTO-HTML-Seiten auf fhem.de sollen komplett verschwinden und durch einen Link auf entsprechende Wiki-Seite(n) ersetzt werden, damit Änderungen schneller, einfacher und durch mehr Personen vorgenommen werden können als auf der HTML-fhem.de Seite.

Wer mag kann gerne Vorschläge im Wiki abliefern. Vorgaben oder DEN richtigen Weg gibt es mMn nicht.

Zitat
1. Das "Erste Schritte" im Wiki ist ziemlich gut und greift ganz viele Teile aus dem Howto auf, nicht enthalten sind folgende Themen:

Erste Schritte soll(te?) nur einen ersten Einstieg und Überblick ohne Hardwareanforderungen liefern; quasi, ob FHEM etwas für einen persönlich ist. Darum sind auch viele Dinge nicht enthalten. Es soll nur einen Überblick verschaffen.
Nächster Schritt wäre das Einsteiger-PDF.

Zitat2. Gar nicht (im Howto) enthalten sind Hinweise auf die Bedeutung von perl, regex &Co.. Da würde sich m.E. ein Link auf die entsprechenden Abschnitte in der commandref und http://regex101.com/ anbieten, zur Frage wo s.u..

Das Thema Perl- und RegEx-Kenntnisse kommt aus meiner Sicht (mittlerweile) zu kurz. Hatte deshalb in Erste Schritte vor kurzem einen Hinweis zu Perl aufgenommen..
Das HOWTO ist schon relativ alt. Stammt von Rudi aus der Zeit, als es noch kein Einsteiger-PDF gab und ich habe es nicht wirklich weitergepflegt.
"Damals" wurde in der Google-Goup ganz oft auf die Bedeutung von Perl hingewiesen.

zu 3. habe ich keine Probleme mit vorsichtigen Ergänzungen in Absprache mit Uli. Aber bitte nicht zu sehr aufbohren. Mir ist dort mittlerweile schon wieder zu viel drin. Dort wird versucht Readings/Internals/Attribute zu erklären und die Namensgebung bei Modulen zu erläutern.

zu 4. Fritzbox raus und FS20 raus. Hardwareunabhängig ist grundsätzlich nicht schlecht, aber wie erklärt man loggen, plotten usw. sinnvoll?

zu 5.) "Daumen hoch."

zu 5b) Uli als Einsteiger-PDF Autor ansprechen.

Danke für den Einsatz!

Btw: Irgendwie sollten wir das neben deutsch auch auf englisch hinbekommen, damit wir nicht alle Fremdsprachler abhängen. Bei "Erste Schritte" und FHEM Installation" habe u.a. ich mich mit Englisch versucht, wobei Versuch ernst zu nehmen ist.

Gruß, Christian

Hallo Christian,

Du bist doch bestimmt von uns der fitteste im Wiki, ich tue mich immer schwer mit Formatierung, Struktur, Links, Autor Box usw.
Vorschlag: nimm doch

Zitatzu 5.) "Daumen hoch."

und lege das genau so als Hülle mal an? Dann können wir das Seite für Seite mit Texten/Vorschlägen füllen?!

Gruß Otto

OK, dann haben wir zumindest mal einen Fahrplan. Den Ansatz, sich mal auf den Weg zu machen, finde ich ok, da ja scheinbar Einigkeit über die "grobe Richtung" (Punkt 5) besteht (?). Vorschläge sind aber willkommen und sicher findet sich beim Erstellen noch der eine oder andere Punkt, der so noch nicht hinhaut.

Vorab: Die Liste sollte eher eine Bestandsaufnahme sein, das "enthält - enthält nicht" war nicht an sich als Kritik gedacht.

Zu den "Ersten Schritten": Das ursprüngliche Ziel war klar, und es hat vermutlich einigen Leuten sehr geholfen, das mal praktisch auszuprobieren. [OT]Ob man damit feststellen kann, ob FHEM was für einen persönlich ist, wage ich zu bezweifeln, weil einem größeren Teil der Neu-User nicht klar zu sein scheint, dass man FHEM "pflegen" muß und sich bei jedem neuen Modul bzw. jeder neuen Hardware überlegen, was man sich damit "einbrockt" - aber das ist wieder ein anderes Thema, irgendwo angesiedelt zwischen "Erwartungen", "Planung" und "Betrieb" ;) .[/OT]

Einig sind wir darin, dass es auch auf mittlere Sicht ein "Arbeitsdokument" zum ersten Erproben ohne Hardware sein soll - ich würde es im Hinterkopf ergänzen um "ohne vertiefende Einblicke". Von daher würde ich perl und regex (bzw. devspec lt. commandref) in einem logisch anschließenden 2. Teil (oder weiteren Teil bzw. dann der Linkliste im Sinne von: "was man sinnvollerweise gelesen haben sollte") sehen und dahin ggf. auch structure etc. packen. Damit wäre der derzeitige Artikel also quasi wieder zu reduzieren auf eine Art "blink" (so war das ursprünglich, wenn ich das noch recht in Erinnerung habe. (Btw. zu regex&co: die Commandref enthält mit der "Einleitung" auch eine Art allgemeiner Einführung, in dem vieles kurz und knackig erläutert ist).

Der Hinweiskasten zu Dummy wartet in der deutschen Fassung auf Rückmeldung: Wenn das in Text und in der Sache ok ist, kann ich gerne noch versuchen, das zu übersetzen - verbessern kann es dann ja jemand, der (noch ;D ) besser Englisch kann ;) .

UliM habe ich wegen des pdf per pm kontaktiert und warte mal auf seine Reaktion.

Was den Rest angeht: Ich mache mich (voraussichtlich aber erst übernächste Woche) gerne mal dran, da einen ersten Vorschlag (in einer deutschen Fassung) zu machen - und das dann als "Roh-Übersetzung" nachzuziehen, wenn das in der deutschen Fassung einen "mature" status hat. Allerdings: bei der Erstellung der letzten Seiten (ThinClient und Dokumentenstruktur in FHEM) hatte ich den Eindruck, dass es eventuell besser wäre, jemand würde die grundsätzliche Struktur (leer) angelegt (Danke @Otto, war fast fertig mit Tippen...) - vor allem dann, wenn es im Hintergrund bei entsprechender Vorgehensweise möglich sein sollte (?), dass der User eine für ihn passende Sprachfassung ausgeliefert bekommt...
Oder kann man das auch leicht im Hintergrund nachziehen? (ich vermute es fast, das Thema wäre dann nur das Nachziehen von Links - nach ggf. erfolgtem Umbenennen.)

@Andis & ggf. andere stille Mitleser:
Jetzt wäre die Gelegenheit, sich einzubringen und ggf. einen Teil der Arbeit zu machen (Otto ist ja schon an Bord, vorab schon mal Danke! ;) )...

Wenn wir grade dabei sind eine Rohfassung für eine englische Übersetzung der Dokumentstruktur:

ZitatDocumentation about FHEM is spread among several sources.

Short overview as a first orientation:

=[http://www.fhem.de FHEM]=
Some basic infos about FHEM and installation instructions.
={{Link2CmdRef}}=
If you run into trouble when using and configuring FHEM it is strictly recommended to have a look into '''CommandRef'''. There you find detailed info about usage and options for all official modules and FHEM-commands. Also this is the place where new functionality will be first documented directly by module's autors. Commandref shall provide the necessary info about how to use
* FHEM commands and options;
* Device Modules wrt. definition, configuration and usage. Device Module typically means modules to integrate a piece of hardware;
* Helper Modules.
For all people contributing software to be officially distributed with FHEM (aka Module author) there is just one strict rule: They have to provide a commandref (in english) for the module and support it for the first tree months. So commandref is the most important source for information about each module.

'''TIPP:''' A lot of the Module Authors are not fluent in english, so in case you see room for improvement of the english version just provide a better version and contact the respective[https://www.fhem.de/MAINTAINER.txt maintainer] - he/she most likely will be happy.

=FHEMWiki=
The page you are currently reading is part of the FHEMWiki. The link at the top left leads you to the main page. This is a good place to start. We appologise about most articles are in german, feel free to add or translate content also in english for others! Many articles you find in the FHEMWiki are directly maintained by Module's authors, a lot of them have just been written by other users. So accuracy and actuality of the articles may vary.

'''TIPP:''' There's a special [https://forum.fhem.de/index.php/board,80.0.html section in our forum] for proposals for improvement on the FHEMWiki.

=[http://forum.fhem.de/ Forum]=
Some Module Authors - especially of Modules not (yet) distributed as part of FHEM - prefer to provide further info about the usage of these modules in the forum. Helpfull info about the forum itself is provided in the [https://forum.fhem.de/index.php/board,18.0.html pinned Threads in Anfängerbereich], we appologize about them beeing mostly in german. Feel free to ask any question also in english - either in the english part of the forum or also in the regular section you find suitable for your specific interest. If you are able to read german, you may find a lot of usefull info by using the hints for doing forum searches in the mentionned pinned threads.

'''TIPP:''' We like to challenge people about first having used the searching possibilities before asking, as most problems have been discussed before - there are about 20.000 users in the forum - so there waits (at least one) solution on most topics to be discovered! But we understand it's not easy to even know the right keywords for searching if you are not speaking german.

=Internet, Blogs usw.=
Information provided in other sources - especially blogs - you have to challenge yourself whether this is at the right level of actuality and quality. Keep in mind: Most of the respective bloggers aso. may follow their own agenda. This may be different to the FHEM community's.

'''TIPP:''' So it's highly recommended to first doublecheck that sort of information against the one provided by the community before asking questions on info sourced "elsewhere" in the forum.

[[Kategorie:Dokumentation]]

Kann gerne nach Durchsicht dann in's Wiki. Oder sollte man da eine neue, separate Seite erfassen (gefällt mir nicht so...)

Zitat von: Otto123 am 09 Februar 2018, 15:14:07
nimm doch und lege das genau so als Hülle mal an? Dann können wir das Seite für Seite mit Texten/Vorschlägen füllen?!

Kann ich machen, zunächst möchte ich aber endlich mal die "short description" in der commandref überall nachpflegen. Also wird nicht sofort etwas. Wenn ihr ungeduldig werdet, dann bitte selbst loslegen.

Zitat(Btw. zu regex&co: die Commandref enthält mit der "Einleitung" auch eine Art allgemeiner Einführung, in dem vieles kurz und knackig erläutert ist).

Ja, stimmt. Sollten wir ebenso wie https://fhem.de/commandref.html#perl als "Pflicht"lektüre anführen. Kommt momentan zu kurz.

ZitatDer Hinweiskasten zu Dummy wartet in der deutschen Fassung auf Rückmeldung:

Gerade gesehen:  Im 2. Absatz von https://wiki.fhem.de/wiki/Erste_Schritte_in_FHEM#Device_anlegen_-_define hatte Andies das Thema dummy schon angeführt. Ist jetzt irgendwie doppelt.

Zitatvor allem dann, wenn es im Hintergrund bei entsprechender Vorgehensweise möglich sein sollte (?), dass der User eine für ihn passende Sprachfassung ausgeliefert bekommt...

Gibt keine Hintergundautomatik. Man muss die passende Seite aufrufen. Von fhem.de würde ich auf die passende Sprachversion verlinken.
Die Sprachversion kann man durch ein angehängtes Kürzel am Artikelnamen wie hier unterscheiden:
deutsch: https://wiki.fhem.de/wiki/FHEM_Installation_Windows
englisch: https://wiki.fhem.de/wiki/FHEM_Installation_Windows/en

Hier
https://wiki.fhem.de/wiki/Erste_Schritte_in_FHEM
https://wiki.fhem.de/wiki/First_steps_in_FHEM
habe ich aber unterschiedliche Seitennamen verwendet, weil es ansonsten wenig Sinn machte.
Am Ende von https://wiki.fhem.de/wiki/First_steps_in_FHEM#What.27s_next.3F ist ein Hinweis, welche Sprachversion aktueller ist.
Es bleibt aber manuelle Übersetzungsarbeit.
Ich würde erst die deutsche Fassung machen und dann den Inhalt auf eine englische Seite mit Links und Co kopieren. Bei Erste Schritte und Installation Windows haben wir das so durchgeführt.

ZitatOder sollte man da eine neue, separate Seite erfassen (gefällt mir nicht so...)

Finde separate Seiten für jede Sprache wegen Übersichtlichkeit besser. Vielleicht kommen auch die französischen Wiki-Schreiber/User wieder und dann würde es in einer Seite gänzlich unübersichtlich.
Lasse mich aber auch vom Gegenteil überzeugen.

Ansonsten freut mich Deine prompte Übersetzungsarbeit. Du kannst so etwas auch gerne direkt ins Wiki packen.

Eine formale Anmerkung  ;) : 1. Überschriften bitte auf 2. Gliederungsebene packen (bspw: ==[http://www.fhem.de FHEM]==).

Gruß, Christian

Zitat von: krikan am 09 Februar 2018, 20:30:26
Die Sprachversion kann man durch ein angehängtes Kürzel am Artikelnamen wie hier unterscheiden:

Finde separate Seiten für jede Sprache wegen Übersichtlichkeit besser. Vielleicht kommen auch die französischen Wiki-Schreiber/User wieder und dann würde es in einer Seite gänzlich unübersichtlich.
Lasse mich aber auch vom Gegenteil überzeugen.

Ansonsten freut mich Deine prompte Übersetzungsarbeit. Du kannst so etwas auch gerne direkt ins Wiki packen.

Gerne geschehen, die englische Fassung ist entsprechend der bisherigen Gepflogenheiten online: https://wiki.fhem.de/wiki/Dokumentationssstruktur/en.
Das mit den "==" hat es wohl beim parsen beim reinkopieren hier im Forum zerhauen, ich hatte ja nur die Ausgangsstruktur verwendet, hätte eigentlich passen sollen ??? .

Was die Frage der Sprachfassungen angeht, finde ich das nicht sooo klasse. Mir hatte eher was vorgeschwebt wie im Mediawiki (https://www.mediawiki.org/wiki/Help:Moving_a_page): Da kommen oben im Kopf eines Artikels die verfügbaren Sprachfassungen. Sowas läd ggf. auch mal jemanden ein, der einfach nur etwas FHEM kann, dafür aber ggf. noch besser Englisch oder Französisch (bei mir würde das dann zwar irgendwie so aussehen als ob es französisch wäre, aber einladend wäre das eher nicht...). Allerdings habe ich keinen Plan, wie das im Hintergrund verwaltet wird (Wiki-extension?). Und klar: Es bleibt "manuelle" Arbeit :) .

Zu dem doppelten Dummy-Hinweis: Ist irgendwie richtig, aber wir sollten irgend eine Zwischenlösung finden - nach meinen Eindruck kommen die "vielen Dummys" eventuell auch daher, dass sie an der prominenten Stelle so "beworben" werden, ohne von einer unnötig exzessiven Verwendung abzuraten.

Wenn es wegen der Sprachfassungen keinen zusätzlichen nachträglichen Aufwand generiert, können wir (Otto, ich und wer sich noch berufen fühlt) die Artikel auch einfach anlegen, mir ging es nur darum, dass das eben ggf. zusätzlichen Aufwand nach sich zieht, weil zumindest mir nicht so richtig klar ist, welche administrativen "Drumrums" einzuhalten sind, um den Artikeln eine vernünftige Struktur im Sinne der Wiki-Einbindung zu geben.
Das eilt auch nicht sooo sehr, ich bin jetzt eh' erst mal ziemlich offline.

Bis dahin erst mal Grüße,

Beta-User

Danke!

Wir hatten die Diskussion zur Mehrsprachigkeit hier https://forum.fhem.de/index.php/topic,65790.0.html schon einmal. Neuer Stand ist mir nicht bekannt.
Von meiner Seite wollte ich Mehrsprachigkeit nur bei den von fhem.de ins Wiki verlagerten Seiten (HOWTO, Installation, Erste Schritte (neu)).
Dokumentationsstruktur hatte ich nicht auf dem Schirm schadet aber nicht.
Ansonsten würde ich mich weiterhin auf deutsch beschraenken.

Zitat
Wenn es wegen der Sprachfassungen keinen zusätzlichen nachträglichen Aufwand generiert, können wir (Otto, ich und wer sich noch berufen fühlt) die Artikel auch einfach anlegen, mir ging es nur darum, dass das eben ggf. zusätzlichen Aufwand nach sich zieht, weil zumindest mir nicht so richtig klar ist, welche administrativen "Drumrums" einzuhalten sind, um den Artikeln eine vernünftige Struktur im Sinne der Wiki-Einbindung zu geben.

Das ehrt Dich/Euch und weil ihr Euch die Gedanken macht, war mein Ansatz: Macht ruhig. Artikel kann man immer noch umbenennen und anders kategorisieren. Letzteres mit keinen Nebenwirkungen.

Gruß, Christian

Ah, den Mehrsprachigkeitsartikel hatte ich nicht wahrgenommen (und jetzt auch nicht vertieft gelesen), da ich einfach von folgenden Annahmen ausgegangen bin:
- Wiki-SW unterstützt grundsätzlich Mehrsprachigkeit (ggf. nach Aktivierung)
- Grundlegende Infos, die man als interessierter Mensch _braucht_, sollten/müssen auch mind. auf englisch verfügbar sein (mehr ist "nice to have"). Also eigentlich reicht für alle die commandref ;) :( ;D 8) .

Aber klar, weniger ist manchmal mehr, vor allem, wenn es um Aktualität geht. Andererseits: wenn man nicht auf die Schnelle erfassen kann, wo "eigentlich" noch was zu tun wäre (mehrere Sprachfassungen), ist es noch eine Stufe schwieriger, Aktualität zu gewährleisten, und bei den beiden geläufigsten Sprachen sollte das noch gehen...

Aber darauf können wir dann zu gegebener Zeit nochmal (in dem anderen Thread) zurückkommen ;) .

So, anbei füge ich mal eine erste Rohfassung bei, damit es hier weitergeht.

Es sind bewußt erst mal nicht zu tiefgreifende Eingriffe in den Ausgangstext erfolgt. Da manches noch aktualisiert werden sollte und auch einige Anmerkungen zu diskutieren sind, vor einer Veröffentlichung erst mal auf diesem Weg.

Rückmeldungen sind wie immer willkommen...

Kann FHEM noch auf Fritzboxen installiert werden? Dachte, dass hätte AVM mal unterbunden. Wenn's nicht mehr geht, würde ich nämlich alles diesbezüglich weg lassen. Oder eigentlich sowieso.
VPN/Apache-Proxy würde ich auch nicht erwähnen. Das greift zu weit.

@drhirn:
Vorab: Danke für die Rückmeldung!
Aber bezieht sich deine Antwort auf das txt oder die aktuelle Fassung bei fhem.de?

In dem oben angehängten txt-File findet sich nur an einer Stelle eine Fritzbox. Da geht es um vpn und das sollte m.E. dann inhaltlich auch noch passen, im übrigen ist es wie hier in dem Thread schon als ok besprochen raus.
Und ja, die Installation auf einer Fritte geht wohl noch, wenn man die Dinger genügend verbiegt...

Zu vpn/Apache: vpn würde ich drin lassen, zu Apache/reverseProxy hatte ich das noch mit dem Hinweis drin, dass man das auch nach meinem Eindruck besser woanders unterbringen sollte (wer und wo! Ich habe keine wirkliche Ahnung von sowas und bin daher nicht der Richtige). vpn würde ich deswegen drin lassen, weil es genug Leute gibt, die sonst das Stichwort noch nie als "offizielle" Empfehlung gehört haben und dann einfaches Portforwarding einrichten und sich über Sicherheit gar keinen Kopf machen, weil sie glauben "allowed" wäre ausreichend...

EDIT: anbei eine etwas aktualisierte Fassung (nur ProxyServer durch ReverseProxy ersetzt).

Sorry, bin irgendwie beim Lesen des txt und der aktuellen Fassung durcheinander gekommen. Im txt steht eh nichts mehr von Fritzbox.

Ok, das VPN-Argument ist gut. Und den Hinweis bzgl. Apache-Text woanders-unterbringen habe ich gelesen. Wollte dich damit nur bestätigen.

Ich denke, wenn sich einer mit ReverseProxy beschäftigen will, ist er eh schon fortgeschritten genug, um selber die Anleitungen im Forum/Wiki zu finden. Das könnte man also auch einfach nur mit einem Satz - wie beim VPN - abhandeln.

Zitat von: Beta-User am 07 März 2018, 13:32:33
EDIT: anbei eine etwas aktualisierte Fassung (nur ProxyServer durch ReverseProxy ersetzt).

Ein paar zufällige Gedanken, während ich das Dokument gelesen habe:

Ich hab mir deinen Vorschlag mal durchgelesen und dabei versucht, alles was ich bereits über FHEM weiß, zu vergessen. Ich bin bereits am zweiten und dritten Absatz gescheitert, denn der Text geht viel zu schnell auf die Ebene, in der man aktiv etwas machen muss und erklärt überhaupt nicht, warum und wann (z.B. welche Kombination aus OS, Plattform und Transceiver führt zu welchen Schritten). Das sollte eigentlich alles in die Sektion über USB-Geräte.

Lustig ist auch, dass die Installation von FHEM (im gleichnamigen Abschnitt und auch sonst wo) eigentlich überhaupt nicht behandelt wird. Was ist mit dem Debian-Paket? Gibt es andere Möglichkeiten, z.B. Docker? Das make-Beispiel wird in vielen Fällen fehlschlagen, da nirgendwo steht, dass man sich FHEM erst mal als Sourcecode runterladen muss (nicht vergessen: Das richtet sich an Anfänger, nicht an Leute die sowas schon mal gemacht haben) und dass man dann auch noch in das entpackte Verzeichnis wechseln sollte, bevor man make ausführt.

Ist telnet wirklich eine "Standard TCP/IP Weboberfläche"?

Der ganze Teil über Sicherheit geht viel zu tief in die Materie und sollte auf eine eigene Seite, die dort natürlich verlinkt ist, ausgelagert werden. Maximal das Thema allowed und das Abraten von port forwardings sollte dort hin. Dito geht der Abschnitt über USB-Geräte in Bereiche, die über "Erste Schritte" weit hinausgehen.

Es sollte einen Bereich geben, in denen wichtige Begriffe und die Kernkonzepte von FHEM erklärt werden (was sind Events/Trigger/Aktoren/Sensoren, etc. pp.)

PERL = Perl (http://perldoc.perl.org/perlfaq1.html#What's-the-difference-between-%22perl%22-and-%22Perl%22%3f)
LINUX = Linux

tbc

Zitat von: Christoph Morrison am 07 März 2018, 18:46:53
Ein paar zufällige Gedanken, während ich das Dokument gelesen habe:

Vorab: Danke für's lesen! Und auch bei der Gelegenheit noch für deine anderen bisherigen Aktivitäten zur Verbesserung der Doku!

Der Text"vorschlag" hält sich erst mal recht eng am historischen Vorbild, aber du hast natürlich recht damit, dass man das  - bzw. auch das gesamte Umfeld der "Einsteiger-Literatur" nochmal gründlich überarbeiten sollte.

Bevor ich hier anfange, auf die berechtigten Kritikpunkte einzugehen: Welches ist die richtige Vorgehensweise für die Weiterbearbeitung des Textes?

Im Wiki habe ich noch keinen Entwurfsmodus entdeckt, mit dem man vorbereitend editieren kann, ohne dass alles gleich online ist. Wäre das eher was für github? Wir können gerne dein Repo nutzen (das du für die Verbesserungsvorschläge eingerichtet hattest)...

Vorschläge sind willkommen, ich freue mich jedenfalls, dass hierzu endlich eine gewisse konstruktive Diskussion in Gang kommt bzw. dann irgendwann auch das Anliegen von krikan erledigt sein sollte :) .

Zitat von: Beta-User am 07 März 2018, 19:43:37
Bevor ich hier anfange, auf die berechtigten Kritikpunkte einzugehen: Welches ist die richtige Vorgehensweise für die Weiterbearbeitung des Textes?

Ich glaube, ich würde sowas über ein live document wie z.B. Google Docs machen. So ein Wiki ist zwar im Prinzip ein gutes Tool zu Kollaboration im größeren Stil, aber halt nur am gesamten Textkorpus und nicht an einem einzelnen Lemma (= Artikel, Seite, was auch immer). Alternativ gibt es einen Maintainer für eine Seite, der change requests für sie annimmt, ansonsten aber die Oberhoheit hat (wie im Repository). Letzteres bildet MediaWiki über die gesichteten Versionen ab.

Beides funktioniert und beides hat seine Vor- und Nachteile.

ZitatIm Wiki habe ich noch keinen Entwurfsmodus entdeckt, mit dem man vorbereitend editieren kann, ohne dass alles gleich online ist. Wäre das eher was für github? Wir können gerne dein Repo nutzen (das du für die Verbesserungsvorschläge eingerichtet hattest)...

Ich glaube Github ist dazu zu schwerfällig

Zitat von: Beta-User am 07 März 2018, 19:43:37
Der Text"vorschlag" hält sich erst mal recht eng am historischen Vorbild, aber du hast natürlich recht damit, dass man das  - bzw. auch das gesamte Umfeld der "Einsteiger-Literatur" nochmal gründlich überarbeiten sollte.

Mir persönlich gefällt gerade die Anlehnung an das kurze, knappe, technische "Original".
Die Zielgruppe ist nach meinem Verständnis ein wenig anders als Erste Schritte bzw. Einsteiger-PDF, die ich nicht ersetzen wollte.
Aber letztlich bestimmt ihr als Bearbeiter und Schreiber, wohin die Reise geht.  :)

Zitat
Welches ist die richtige Vorgehensweise für die Weiterbearbeitung des Textes?

Wiki ist gerade für die gemeinsame Bearbeitung da. Änderungen kann man nachverfolgen, rückgänig machen,..
Auch wenn es direkt online ist, sehe ich kein Problem. Ich hätte dann meine Gedanken beim Lesen eben auch direkt eingearbeitet.
Im Wiki kann man direkt bsw Links passend setzen und kontrollieren, während man bei externen Dokumenten nachher ein- und nachpflegen muss. Finde ich persönlich zu anstrengend. Aber letztlich egal....

@Beta-User: Daumen hoch.

So, erste Fassung ist online unter https://wiki.fhem.de/wiki/HOWTO (https://wiki.fhem.de/wiki/HOWTO).

Sehe das ähnlich, dass das eine Kurzeinführung für Leute sein sollte, die Grundlagenkenntnisse mitbringen und einen schnellen Überblick haben wollen oder eine Kurzreferenz suchen. Nicht komplette noobs (aber wer weiß am Anfang schon alles...?). Daher gefällt auch mir der knappe, sachliche Stil.

Was ich noch geändert habe:
- Installation gekürzt auf den Hinweis, dass das direkt auf fhem.de beschrieben ist
- Den ersten USB-Teil aus der Einleitung zu USB-Devices verschoben, da macht er sich in der Tat besser
- Apache raus
- Schreibweisen auf Linux und Perl geändert
EDIT: - Hinweis auf regex101.com aufgenommen
- diverse Formatierungsversuche...

Wer mag, kann jetzt also gerne direkt verbessern - das ist eine Einladung!

(Ich selbst finde den Editor im Wiki aber echt gewöhnungsbedürftig, aber was soll's. Und den Link auf den Event Monitor in funktionsfähiger Form einzubauen, ist mir leider auch nicht gelungen...)

Zitat von: krikan am 06 Juni 2017, 12:05:45
Insbesondere (aber nicht nur) bei der Aktualisierung des Abschnitts https://fhem.de/HOWTO.html#security könnte ich Hilfe gebrauchen (siehe auch https://forum.fhem.de/index.php/topic,72629.0/all.html).

Zitat von: Beta-User am 07 März 2018, 21:03:56
So, erste Fassung ist online unter https://wiki.fhem.de/wiki/HOWTO (https://wiki.fhem.de/wiki/HOWTO).

Darf ich als immernoch-Neuling dazu etwas sagen?

(Mein persönlicher Hintergrund: FHEM übe ich fleißig, habe immerzu Fragen, immerzu etwas nicht verstanden. Security allgemein kann ich.)

Ich lese also die "erste Fassung" wie frisch geboren. Das bisherige howto kenne ich nicht, habe ich ganz bewusst nicht gelesen. Also bin ich die perfekte Zielgruppe.

Bei der "ersten Fassung" fällt mir beim Überfliegen auf, dass die Ebenen wild durcheinander gehen. Mal WAN, mal intranet, dann mal schalte-Lampe ein. Hmmm.

Ich würde mal umgekehrt fragen wollen: Was ist jetzt eigentlich das Ziel des Dokuments? Beim ersten Überfliegen ist das für mich nur teilweise erkennbar.

Wenn wir "security" ernst nehmen, ist der erste Schritt eine Bedrohungsanalyse. Der zweite Schritt wäre dann, die verschiedenen Bedrohungsebenen genau zu betrachten. Ganz rational haben wir vier:

1) Aktualität des Betriebssystems des FHEM-Wirts. Allgemeine Sicherheit des FHEM-Wirts. Aktualität des FHEM-Daemon.

2) Datenweg WAN (das böse Internet) <-> FHEM-Server. Offene Ports. Aktiv angestoßene unverschlüsselte Übertragung.

3) FHEM im Intranet. Angreifer (gern Agent) greift von innen an. Weitere Bedrohung WiFi-Sicherheit. Ansonsten wie 1).

4) Sensoren/Aktoren die mit dem FHEM-Server interagieren. Unverschlüsselt. Angriffsszenarien. Abwehrmöglichkeiten. (Ggf. Unterpunkt Aktoren via fhemweb: Risiko Codeeinschleusung.)

Ich denke, dass (in meinem Denkbild) der Absatz "Installation" stehen bleiben kann und vielleicht muss. Das bietet dem Techniker einen groben Überblick, wo Schnittstellen zu 1) und 2) aufgemacht werden.

Hingegen passt im Sinne von security der Abschnitt "Einbinden und Konfiguration von Sensoren und Aktoren" überhaupt nicht. Der gehört (anders gestaltet) unter 4). Dort müsste diskutiert werden, wie man z-B. die automatische Erkennung komplett ausschaltet, selektiv einschaltet, fremde Geräte erkennt. [¹]

Nach "Installation" müsste es aus meiner Sicht mit der Abarbeitung der Punkte 1-4 weiter gehen. Und es kann und darf bei "security" wirklich nur um Security gehen - nicht darum, wie man eine Lampe einschaltet.


Bitte nicht böse sein. Ist ja nur eine Einzelmeinung, quasi ein Einzelfall. ;)
Insbesondere @Beta-User : Du hast Arbeit investiert. Und nun kommt einer und mault rum. Ich weiß. Sei bitte nicht böse.

[¹] Neben mein-klein-Haus sind recht viele andere klein-Häuschen bei guten Empfangsbedingungen. Ich habe gut 80 Sensoren/Aktoren meiner Nachbarn bei. Ich weiß, dass da ein Fenster auf ist, wie warm es ist, ich kann Nachbars Garage aufmachen. Könnte - mache ich nicht. no harm to the network.

Kurze Frage, habe es nie gemacht und auch nie getestet. Ist ein Devicename mit Punkt zulässig?

Ja. Siehe fhem.pl/goodDeviceName($)

Zitat von: curt am 08 März 2018, 00:15:30
Darf ich als immernoch-Neuling dazu etwas sagen?
[...]
Bitte nicht böse sein.

Gerne! Deswegen diskutieren wir öffentlich und insbesondere hier geht es auch darum, Meinungen und Eindrücke auszutauschen. Also jedenfalls von meiner Seite: Alles gut, der Dank für die investierte Zeit geht in gleicher Weise zurück :D .

Was deine Einwände zum Abschnitt Security angeht, sind das m.E. alles valide Punkte. Es stellt sich - wie auch die Anmerkung von Christoph Morrision aufzeigt - immer die Frage, was noch da reingehört, und was ggf. in einen separaten Artikel. Hier würde ich sagen, dass die Überschrift "Sicherheit" zu pauschal ist. Eigentlich sollte da m.E. _an der Stelle_ nur etwas wie "Absicherung der FHEM-Serverkomponente" stehen. Dazu gehören dann allowed und die dort derzeit aufgeführten Stichworte, was ggf. noch zusammengefasst werden kann.
Auf die weiterführenden Themen sollte ggf. im Rahmen der Planung (https://wiki.fhem.de/wiki/Planung) eingegangen werden oder in einem separaten Artikel, auf den nur im Rahmen eines Hinweiskastens zu verweisen wäre.
(An Christoph Morrision: Ich habe leider keine Ahnung, ob das mit TCP/IP und telnet sachlich korrekt ist, da ich bis dato davon ausgegangen war, dass der ursprüngliche Autor (Rudi?) wußte, was er da schreibt.)

Zur Darstellung der USB-Themen:
Nach meinem persönlichen Eindruck ist das zwar lang, sprengt aber noch nicht den Rahmen. Denn irgendwo muß man ja anfangen, Begrifflichkeiten und Zusammenhänge "im Fluß" darzustellen. Allerdings ist auch hier die Überschrift "USB Geräte" nicht unbedingt glücklich gewählt. Vorschlag hier: "Schnittstellen zur realen Welt, insbesondere USB-Geräte"?
Dazu eine kurze Einführung, dass es eigentlich nur zwei Wege gibt, wie FHEM an Infos aus der Außenwelt kommen kann - via serieller Schnittstelle oder eben via TCP/IP. (Dazu kurz eine Frage: Wer nur ser2net oä. nutzt, benötigt dann auch das libserial-perl-modul, oder?)

Ich stell jetzt mal ganz provokant eine Frage, die mir beim Durchlesen des HOWTOs gekommen ist: Braucht's das HOWTO überhaupt?
Was ich damit sagen will, wir haben die Installationsanleitung, das HowTo, das "FHEM für Einsteiger"-PDF und die "Ersten Schritte in FHEM". Das ist schon fast etwas Overkill, nicht? Wär's nicht sinnvoller, EINE Anlaufstation zu haben, die dann auch gerne etwas ausführlicher sein darf?

(P.S.: Weil's mir grad aufgefallen ist: Im Anfängerfragen-Bereich heißt's noch "pdf-eBook zum Einstieg in fhem" und "Kleiner fhem-Kurs: Erste Schritte in fhem".)

Zitat von: drhirn am 08 März 2018, 10:57:52
Braucht's das HOWTO überhaupt?

Spielverderber.   ;D

Der Ersteller des HOWTOs (Rudi) hatte mit dem Löschen keine Probleme.
Ich fand es aber persönlich als Kurzüberblick statt "Erste Schritte"/"Einsteiger-PDF" ganz sinnvoll und habe Erhaltung befürwortet.
HOWTO ist für den Lesertyp: erst HOWTO, dann commandref. Auch so kann man nämlich zum Ziel kommen.
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.

Ja, wir haben Dopplungen und Überschneidungen. Lösung: ?

Zitat(P.S.: Weil's mir grad aufgefallen ist: Im Anfängerfragen-Bereich heißt's noch "pdf-eBook zum Einstieg in fhem" und "Kleiner fhem-Kurs: Erste Schritte in fhem".)

Poster (Uli?) bitte ansprechen. Ich mag nicht in fremden Posts editieren.

Zitat von: krikan am 08 März 2018, 11:31:15
Spielverderber.   ;D

Immer ;D

Zitat von: krikanDarum (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.

War mir auch ein Dorn im Auge. Andererseits könnte es uns davor retten, dass alle anfangen, FHEM auf Windows zu installieren. Ein Raspberry ist eine kleine Einstiegshürde.

Zitat von: krikanJa, wir haben Dopplungen und Überschneidungen. Lösung: ?

Wie gesagt, eine Anlaufstation. Ein Wiki-Artikel, der mal alles überblicksmäßig abhandelt. Von Installation über Erstkonfiguration über Sicherheit über Einbinden von Geräten über Notifys über ...
Also im Prinzip das HOWTO ergänzt um Informationen aus den anderen Quellen. Mit Links zu weiterführenden Informationen.
Steinigt mich, aber mir ist auf die schnelle keine andere Seite als Beispiel eingefallen. Und meine Finger weigern sich, es zu tippen. Aber wie hier (https://docs.openhab.org) könnte ich mir das vorstellen.

Zitat von: krikanPoster (Uli?) bitte ansprechen. Ich mag nicht in fremden Posts editieren.

Mach ich.

Zitat von: drhirn am 08 März 2018, 10:57:52
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).

Zitat von: krikan am 08 März 2018, 11:31:15
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.)

Zitat von: Beta-User am 08 März 2018, 11:56:39
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 ;D

Zitat von: drhirn am 08 März 2018, 13:01:45
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

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.

Zitat von: drhirn am 08 März 2018, 13:01:45
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 :P .

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 :) .

ZitatDass "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.

@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 (https://forum.fhem.de/index.php/topic,85438.msg778222.html#msg778222) 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...

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.

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

@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

Zitat von: Beta-User am 09 März 2018, 12:45:55
- 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.

Zitat von: Beta-User
- 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.

Zitat von: Beta-User- 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 ;)

Zitat von: Beta-UserWenn 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.

Zitat von: Beta-User- 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>?

Zitat von: drhirn am 09 März 2018, 13:01:53
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 (https://wiki.fhem.de/wiki/Kategorie:Glossary), allerdings sind da - jedenfalls auf den ersten Blick - zuviele Stichworte.

Zitat von: drhirn am 09 März 2018, 13:01:53
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."

Zitat von: drhirn am 09 März 2018, 13:01:53
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.

Zitat von: drhirn am 09 März 2018, 13:01:53
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.

Zitat von: drhirn am 09 März 2018, 13:01:53
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").

Zitat von: Beta-User am 09 März 2018, 13:31:00
Na ja, an sich hatte ich gedacht, man könnte auf eine Art Glossar verweisen. Das gibt es sogar (https://wiki.fhem.de/wiki/Kategorie:Glossary), allerdings sind da - jedenfalls auf den ersten Blick - zuviele Stichworte.

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

Zitat von: Beta-UserDer 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!

Zitat von: Beta-UserJa, 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 ;)

Zitat von: Beta-User am 09 März 2018, 12:45:55
- 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".

Zitat
- "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.

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

Zitat von: krikan am 09 März 2018, 14:31:28
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.

Zitat von: CoolTux am 09 März 2018, 14:41:28
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.

Ich möchte nur eins: nicht den xten Definitionsversuch
Von mir aus auch sehr gerne keine Definition und keine Links. Bisher sind wir bei HOWTO ohne ausgekommen.

Hihi, DOIF scheint echt ein rotes Tuch zu sein. Dabei hab ich's extra nach dem notify hingeschrieben. ;D

Ich hätt's praktisch gefunden, wenn die Begriffe irgendwo mit einem kurzen Satz erklärt werden. Kommt nämlich in den "Ersten Schritten" auch nicht so wirklich rüber. Aber ich bekomm auch keine Krise, wenn wir's weglassen.

Zitat von: drhirn am 09 März 2018, 14:55:09
Hihi, DOIF scheint echt ein rotes Tuch zu sein.

Nein.
Das ist nur so funktionsreich, dass ich es gerade für den Anfang und für das Verständnis unglücklich finde. Aber das ist nur meine Meinung...

Zitat
Ich hätt's praktisch gefunden, wenn die Begriffe irgendwo mit einem kurzen Satz erklärt werden. Kommt nämlich in den "Ersten Schritten" auch nicht so wirklich rüber.

Okok, wenn ihr es für wichtig haltet, dann versucht eine Begriffsdefinition abzuliefern. Vielleicht bin ich ja zu eingefahren.

So, habe zwischenzeitlich etwas rumeditiert und m.E. zu vielen Themen ganz ordentliche Kompromisse gefunden, indem ich Fußnoten benutzt habe. Das hält den eigentlichen Text kurz (teilweise sogar kürzer als bisher) und damit besser lesbar, man hat aber gleichzeitig eine schnelle Referenz woanders hin oder kann kurz erläutern, wo die FTDI-ID herkommt, die beispielhafte Angabe 1234 usw..

Die meisten Komemntare habe ich bei der Gelegenheit gelöscht, mir schien, die Richtung war zwischenzeitlich geklärt, wenn das falsch gewesen sein sollte, bitte "Aua" schreien.

Aber mit der Sch...-Formatierungssyntax komme ich überhaupt nicht klar!!! An der Stelle daher ein riesiges DANKE an drhirn, der da erst mal für ziemlich Ordnung geschaffen hat!

Und vergiss dieses Modul, wir haben es nicht erwähnt und brauchen auch nicht weiter drauf rumzureiten. Wir machen beim howto erst mal KISS, und das ist reine Zeit- _oder_ Ereignissteuerung.

Was die Frage angeht, ob es wirklich Definitionen der Begriffe braucht, hatte ich ja meine Meinung kundgetan. Für's Howto wäre die Frage, ob man FHEM-Begriffe, die man mit help aufrufen kann, irgendwie separat kennzeichnen kann bzw. will (als fetter kursiver code oder so). Aber wie gesagt, ich werde das vermutlich nicht mehr lernen, wie das geht...

Jetzt bin ich erst mal wieder betriebsblind, mit dem hinteren Teil geht's dann irgendwann weiter (bitte ggf. nochmal anstupsen, wenn's zu lange dauert...).

Gruß, Beta-User

Hallo,

hätte noch eine Idee für das Howto. Bei "Schnittstellen zur realen Welt" könnte man Sachen zeigen die ohne irgendwelche USB-Sticks funktionieren. Einfach um eine schnelle Möglichkeit zu haben damit zu spielen. Als Appetithappen sozusagen.
z.B.:
- SYSMON
- DLNARenderer   (speak "Hallo Fhem User!")
- FRITZBOX

Passt vielleicht auch in "Erste Schritte" um die Leute anzufixen ;)

Gruß
Eisix

Hallo Eisix,

Danke für die Anregung.
Die Idee, das zwar (auch) konkret, aber hardwareunabhängig zu machen, ist an sich sehr gut und konstruktiv.

Neulich hatte ich auch schon kurz über den Punkt nachgedacht, das aber dann doch wieder verworfen. Konkret war mein erster gedanklicher Aufhänger "Weather" gewesen. Das hat ich mich allerdings dann recht unsanft daran erinnert, dass Yahoo gelegentlich mal seine Web-Schnittstelle geändert hat, und das jedes mal recht ärgerlich gewesen war. Das müßte man dann also auch in Howto jedesmal auch wieder aktualisieren. (Dazu habe ich persönlich keine Lust).

Kurz meine Meinung zu den von dir angeführten Modulen:
- SYSMON: Hatte ich eine Zeitlang installiert, v.a. um Prozessortemperaturen zu loggen. Ich habe einige Linux-Erfahrung (eher user), aber ich fand das nicht sooo einfach zu konfigurieren (was sind die richtigen Parameter oder soll ich einfach den Standard verwenden?!?) und es liefert sehr viele Readings. Wäre mir vom Eindruck her zu unübersichtlich
- DLNARenderer: Kenne ich nicht, ich mache keine Sprachausgabe und habe auch kein DNLA-fähiges Gerät (zumindest vermutlich nicht bzw. ich nutze es nicht als solches). Wenn man Audio-Devices konkigurieren muß, ist es sicher kein geeignetes Einstiegsdevice, aber nochmal: Ich kenne das Modul nicht.
- FRITZBOX: War auch eines der ersten Devices, das ich mit dem Einsteiger-Guide eingerichtet hatte. An sich sehr nett, aber mittlerweile sollte man wohl sehen, dass man das mit TR064 ans laufen bekommt. Das ist dann wieder was, was einiges an Attributen benötigt, dann benötigt man einige Perl-Module, und ob man jetzt Perl-telnet (?) auch braucht oder nicht ist völlig unklar. Und man muß Passwörter usw. setzen. Ist also nach meinem Eindruck auch eher sehr hoch als Einstiegshürde, zumal dazu auch ein längerer Wiki-Artikel existiert - vermutlich nicht ohne Grund.

Wäre nach meinem persönlichen Geschmack daher eher etwas für weiterführende Dokumente, nicht direkt im Howto (Ziel war doch weiterhin, das eher komprimiert zu halten, oder?).

Überhaupt Abhängigkeit von Modulen: Mind. FRITZBOX und SYSMON benötigen weitere Perl-Module; da sollte dann jeder user doch eher einigermaßen bewußt entscheiden, was er sich "reinziehen" möchte.

Andere Meinungen bzw. andere Modulvorschläge, die sich einfacher umsetzen ließen?

[OT]Da wir hier auch Befindlichkeiten diskutieren: Mir persönlich geht es nicht darum, jemandem "Einstiegsdrogen" zu liefern oder "anzufixen". Mir liegt zum einen daran, den hier zu Beginn geäußerten Wunsch verdienter "alter Hasen" nach Entlastung zu erfüllen und zum anderen intelligenten Menschen, die an FHEM grundsätzlich interessiert sind, eine nachvollziehbare Entscheidungshilfe zu bieten, ob FHEM der Baukasten ihrer Wahl werden soll oder nicht.

Mal wieder nix für ungut, ich weiß schon, dass das jeweils nicht böse gemeint war...[/OT]

Zitat von: Beta-User am 09 März 2018, 15:15:20
So, habe zwischenzeitlich etwas rumeditiert und m.E. zu vielen Themen ganz ordentliche Kompromisse gefunden, indem ich Fußnoten benutzt habe. Das hält den eigentlichen Text kurz (teilweise sogar kürzer als bisher) und damit besser lesbar, man hat aber gleichzeitig eine schnelle Referenz woanders hin oder kann kurz erläutern, wo die FTDI-ID herkommt, die beispielhafte Angabe 1234 usw..

Das war eine ausgezeichnete Idee!

Zitat von: Beta-UserAber mit der Sch...-Formatierungssyntax komme ich überhaupt nicht klar!!!

Einfach fragen, wenn's Unklarheiten gibt. Ich schau immer da (https://www.mediawiki.org/wiki/Help:Contents/de) nach, wenn ich vergessen habe, wie etwas geht.

Zitat von: Beta-UserFür's Howto wäre die Frage, ob man FHEM-Begriffe, die man mit help aufrufen kann, irgendwie separat kennzeichnen kann bzw. will (als fetter kursiver code oder so).

Eigentlich auch eine gute Idee. Ein Text, der erscheint, wenn man den Mauszeiger drauflässt z.B. Muss ich mal schauen, ob's sowas schon gibt. Und sonst könnte man's mit einer Vorlage abbilden.

Zitat von: drhirn am 09 März 2018, 17:05:06
Das war eine ausgezeichnete Idee!

8) Sowas hört man doch gerne...

Zitat
Einfach fragen, wenn's Unklarheiten gibt. Ich schau immer da (https://www.mediawiki.org/wiki/Help:Contents/de) nach, wenn ich vergessen habe, wie etwas geht.

Na ja, das ganze erinnert mich halt an die guten alten Zeiten, als es noch ein WordPerfect 5.x für DOS gab. Aber da hatte man wenigstens die Option, die Formatierungszeichen im Ganzen zu löschen bzw. mit Funktionstasten einzufügen. Die auch noch selbst zu tippen ist nicht nur lästig und fehleranfällig, es ist auch sehr unübersichtlich - jedenfalls nach heutigen Maßstäben.
Ich mache halt c&p aus anderen Dokumenten, dann klappt das meistens ::) . Und wenn du dann hinterher drübergehst, kann man es auch ansehen.

Zitat
Eigentlich auch eine gute Idee. Ein Text, der erscheint, wenn man den Mauszeiger drauflässt z.B. Muss ich mal schauen, ob's sowas schon gibt. Und sonst könnte man's mit einer Vorlage abbilden.

War eine spontane Idee. Wenn es einfach ist und gut aussieht, dann: Klasse! wenn nicht: nicht so wichtig. Investiere die Zeit lieber in die Formatierung des gesamten Textes, ich versuche dann, es nicht wieder "zu kaputt" zu machen, wenn ich wieder was ändere ;)

Zitat von: Beta-User am 09 März 2018, 17:30:52Die auch noch selbst zu tippen ist nicht nur lästig und fehleranfällig, es ist auch sehr unübersichtlich

Musst du eigentlich nicht. Gibt eh den Editor. Kann aber gut sein, dass der bei dir nicht aktiviert ist. Wenn ja, dann in den Einstellungen siehe Screenshot.

...Man lernt nie aus, Danke!

Habe jetzt auch den erweiterten Editor aktiviert :) . Ist zwar immer noch sehr zeichen-orientiert, aber man findet wenigstens schneller die wichtigsten Formatierungsbefehle usw..

Schön wäre noch, wenn man das "live" nebendran wyswyg verfolgen könnte, aber so ist es halt wie früher: Was wirklich ausgegeben wird, sieht man erst wirklich beim "Drucken" (bzw. nach dem Starten von Windo.* bzw. der Voransicht)... Na ja, werde wohl auch das überleben ;D .

Ein bisschen Herausforderung braucht der Mensch. Sonst wird's ja fad. Und die Spannung bis man sieht, was dabei herauskommt, ist ja auch nicht ohne. ;)

So.

Habe doch nochmal drübergesehen und bin "für's erste" eigentlich ganz zufrieden :) . Die Seite könnte nach meinem Geschmack eigentlich den "Baustellen"-Status wieder verlieren (was nicht heißt, dass weitere Vorschläge nicht willkommen wären).
(das ging an @krikan mdB. um Rückmeldung bzw. Umsetzung!)

Habe nur noch ein paar Befehle eingepflegt, überflüssiges gelöscht und am Ende auf einige Befehle@commandref verlinkt, die man (nach meiner persönlichen Meinung) mit Priorität ansehen sollte. Was ich bewußt auch was weggelassen habe, was andere vielleicht für das wichtigste überhaupt halten, könnt ihr euch denken; wer sich dafür revanchieren will, darf "sleep" und "cancel" löschen ;) .

Wenn das dann sowas ist wie eine allg. akzeptierte 1. Fassung, würde ich mich ggf. bei Gelegenheit mit meinen beschränkten Englisch-Kenntnissen mal an eine Übersetzung wagen. Wäre aber _überhaupt nicht_ böse, wenn sich da jemand finden würde, dem sowas leichter von der Hand geht ::) ...

So long erst mal,

Beta-User

Und zu guter Letzt für heute auch noch ein fettes Danke für die Erinnerung, dass ich da ja noch was erledigen wollte ;) .
Habe jetzt zwar noch nicht den großen Wurf mit Cluni's Rolladenlösung gemacht, aber ein einfacher Weekdaytimer mit einem Ausführungsteil, der "TYPE=CUL_HM:FILTER=model=HM-LC-Bl1PBU-FM:FILTER=automode=1" enthält, hat jetzt auch die restlichen Devices einer bestimmten Sorte aus meiner configDB gefegt.

Als Helferlein war "setreading" tätig, vielleicht sollte ich das noch in die Liste der Befehle aufnehmen, die man kennen sollte. Aber vermutlich übersehe ich an der Stelle irgendeine Nebenwirkung 8) , die diese Art des Vorgehens hat. userattr gibt es ja auch nicht umsonst. Mal schauen ::) .

Jetzt mache ich noch eine kleine ReadingsGroup dafür, dann kann auch jeder aus meiner Familie der Steuerung leicht beibringen, dass zu frühes automatisches Rolladenöffnen nicht erwünscht ist...

Mein Status zur Diskussion:
Ich habe mich eingemischt. Die Diskussion habe ich mit allen neuen Beiträgen gelesen. Den nun geänderten Stand des howto kenne ich nicht, das habe ich nicht gelesen.

Mein Status zum Forum:
Ich bin seit vielen Jahren im usenet und Foren unterwegs. Mit diesem Forum tue ich mich schwer: Oft erhalte ich an Stelle einer Antwort ein "Lies commandref". Danke Schlauberger, hab' ich schon. Ich habe es nicht verstanden, sonst würde ich doch nicht fragen. Inzwischen verlege ich meine Fragen oft auf PN, das wirkt mir zielführender.

Mein allgemeiner Status:
Ich bin ITler, dem UNIX-Konzepte und Perl nicht fremd sind. FHEM nutze ich seit gut einem halben Jahr, das ist gut gewachsen, da ist bei mir gut was los (ich muss mal meinen Footer anpassen). Gleichwohl bin ich Anfänger, viele FHEM-Konzepte kenne ich gar nicht, manche andere verstehe ich nicht.

Zur Sache, zur Diskussion:
Vorab möchte ich nochmals sagen, dass ich das alte howto überhaupt nicht kenne (was ein Vorteil sein mag), dass ich den neuen howto-Entwurf (gestern) kenne - und das ich vor allem niemandem auf die Zehen treten möchte: Wenn ich eins in diesem Forum lernte, dann das: Alle sehr sensibel.

Inzwischen scheint mir, dass die Zieldefinition noch gar nicht klar ist: Was soll das neue howto eigentlich bewirken, was ist das Ziel?

Anfangs verstand ich: Es geht um Sicherheit eines kompletten FHEM-Systems. Da werden ja Unmengen an verschiedensten Schnittstellen aufgemacht. Die kann man klassifizieren, danach kann man in ein howto schreiben, was bei jeder Klasse zu beachten ist. Das schrieb ich in meinem ersten Beitrag.

Später las ich in der Diskussion einen interessanten Einwurf, da ging es darum, dass es um Anfänger und einen ersten Überblick ginge - das fand ich einen interessanten Einwurf.

Und soeben las ich noch die Vokabel Glossar - auch dazu komme ich noch, natürlich alles aus meiner bescheidenen Sicht.

Ich fange an:
Ein grundsätzliches howto "FHEM-Sicherheit" halte ich für unabdingbar. Das hatte ich in #23 schon näher beleuchtet.

Den Gedanken "Anfänger mit UNIX-Kenntnissen will schnelle Ersterfolge" aufnehmend sollte/könnte es ein howto "Let's start" geben: Auf der Basis eines existierenden, betriebsbereiten RPi (noch ohne irgendwelche Antennendingser) wird eine schrittweise nachvollziehbare Arbeitsanleitung gegeben, wie man FHEM aufsetzt, wie man das im Browser aufruft, wie man irgend ein erstes Device (da fiele mir mangels Antennen Internet-Wetter, sagen wir Yahoo oder Unwetterwarnung ein) aufsetzt. Wie man das dann optisch schön macht, mit "da klicken" und mit "schöne Grafiken". Denn in dem Fall kann es nur um schnelle erste Erfolge gehen.

howto-Glossar - dazu will und muss ich etwas sagen. (Ok, howto und Glossar beißt sich.)
Mir fehlt ein Glossar für Anfänger. Es fehlt mir immerzu. Also wirklich für Anfänger. Wenige wichtige Einträge. Die dann aber in normalen Deutsch - Wiki und Forum kranken für Anfänger daran, dass da eine unerständliche FHEM-Sprache gesprochen wird.

Ich meine ein Glossar, in dem verständlich gesagt wird, was eigentlich eine Device ist, was ein Actor ist, was ein Attribut ist und wie das abgekürzt wird, was ein Reading ist, was eine readingsGroup ist.

Und wenn ich mich dann kritisch selbst betrachte, müsste in jedem Glossar-Eintrag stehen, wo es weiter geht. Ich erkläre genauer, an mir selbst: Bei den hier erwähnten Sachen wie DOIF oder notify ahne ich, was das sein könnte. Ich lese solche Vokabeln ja oft, also scheint das wichtig zu sein. Aber wo ist ein Glossar, wo mir nur die für Anfänger wichtigen Begriffe erklärt werden (gern mit Link auf commandref + wiki + nachvollziehbares Beispiel).

Man kann einwenden, dass ich das selbst rauskriegen kann. Klar, ich habe ja mal studiert, kein Problem. Aber da suchst Du immerzu Nadeln in Heuhaufen. Das dauert, das dauert richtig. Und ich muss ganz nebenbei arbeiten, habe Familie, Haus und Garten.

Wenn ich mich zu jedem einzelnen Punkt (das kann ich schon) druchkämpfe, habe ich anschließend Arbeit, Familie, Haus und Garten nicht mehr, Damit würde sich dann FHEM erübrigen: Was habe ich dann noch zu überwachen, zu steuern zu regeln?

Bitte nicht auf den Schlips getreten fühlen, Beitrag gern ignorieren: Ich bin der mit der Einzelmeinung.

Zitat von: Beta-User am 09 März 2018, 16:41:21
Überhaupt Abhängigkeit von Modulen: Mind. FRITZBOX und SYSMON benötigen weitere Perl-Module; da sollte dann jeder user doch eher einigermaßen bewußt entscheiden, was er sich "reinziehen" möchte.

Andere Meinungen bzw. andere Modulvorschläge, die sich einfacher umsetzen ließen?

Das "Killer-Feature" von FHEM war für mich beim Einstieg die Anwesenheitserkennung (Handy im WLAN der Fritzbox). Das wäre evtl. für den Einstieg (ohne zusätzliche Hardware )auch ein interessanter Ansatz.

@curt:

Danke für deinen Einwurf.

Es würde mich sehr freuen, wenn du die jetzige Fassung des HOWTO wenigstens kurz überfliegen würdest.

Du hast natürlich völlig damit recht, dass das Thema Sicherheit an sich einer umfassenden und aktuellen Darstellung bedarf. Dem wird die jetzige Fassung sicher nicht gerecht. Zu unser aller Verteidigung: das war  auch nicht die ursprüngliche Zielrichtung des Howto. Dieses war allerdings im dort noch "Sicherheit" genannten Punkt seit der Einführung des "allowed" völlig veraltet, was nach meinem Eindruck der Anlaß für diesen Hilferuf war.

Die jetzige Fassung ist (nach meinem zugegebenermaßen ziemlich betriebsblinden) Verständnis jetzt wieder sehr viel besser geeignet, Leuten, wie du vor einigen Moinaten noch warst, den Einstieg etwas zu erleichtern. Wenn das gelungen ist, bin ich persönlich an der Stelle halbwegs zufriedend - besser machen geht selbstredend immer.

Gerne können wir auch aus deinem vorherigen Beitrag so etwas machen wie eine allgemeine Einführung in zu beachtende Sicherheitsaspekte - mir gehen nämlich die unbedarften Neulinge auch ziemlich gegen den Strich, die irgendwann verstehen, dass InterTechno-Befehle auch ihr Nachbar senden kann und WLAN recht einfach zu stören ist (und die ESPEasy-firmware Sicherheitslücken aufweist), nur weil ihnen das keiner rechtzeitig beigebogen hat.

Aber nochmal: es gibt Überschneidungen, aber eigentlich ist es ein Thema für ein weiteres Buch.

Und da meine Rollandensteuerung jetzt provisorisch (hoffentlich) funktioniert, wie sie soll, unterstütze ich diese Initiative auch wieder gern (wenn gewünscht). Ich gebe nur vorab zu Bedenken: Ich bin weder IT'ler noch beruflich da "irgendwie" reingerutscht. MaW: ich verstehe von diesen Dingen kaum was und versuche nur ports zu öffnen, von denen ich glaube, dass ich sie dauerhaft kontrollieren kann.

Und neben dem Überfliegen hätte ich eine weitere Bitte: Vielleicht hast du weitere Ideen, wie man das ganze noch _etwas_ besser gestaltet, indem man - ggf mit Fußnoten oder so - noch _kurze_ Erläuterungen zu den FHEM-Begrifflichkeiten einfügt, damit auch "Normalos" verstehen, was jeweils gemeint ist.

Ach und noch was: Wir sind zu zweit! Ich bin auch sehr oft der mit der etwas abweichenden Einzelmeinung ;) . Manchmal schaffe ich es, andere zum Nachdenken zu bringen, das freut mich dann sehr. Oft liege ich auch falsch. Ist weniger erfreulich, wird aber durch die anderen Erlebnisse aufgewogen ::) .

You are welcome! (Jedenfalls von meiner Seite)

Zitat von: pcbastler am 09 März 2018, 21:22:48
Das "Killer-Feature" von FHEM war für mich beim Einstieg die Anwesenheitserkennung (Handy im WLAN der Fritzbox). Das wäre evtl. für den Einstieg (ohne zusätzliche Hardware )auch ein interessanter Ansatz.

Hmmm, (sorry für die doofe Frage, ich habe da bisher auch einen Bogen drum gemacht): Da geht es um presence, also eigentlich um ein einfaches pingen, oder? Das könnte in der Tat ein guter Ansatz sein. Scheint auch nicht zu verdächtig zu sein, FHEM lahmzulegen (was leider bei vielen Web-Themen der Fall zu sein scheint). Man kann das dann zwar nicht schalten, aber das ist m.E. an der Stelle nicht so wichtig, wie die Einführung dazu, wie FHEM an Infos kommt.

Hättest du einen kurzen Textvorschlag zu diesem Teil?

Andere Meinungen?

Zitat von: pcbastler am 09 März 2018, 21:22:48
Das "Killer-Feature" von FHEM war für mich [...]

Es wäre ein interessanter Ansatz, bei neuen Nutzern (kleiner ein Jahr) mal zusammenzutragen, was die Motivation war.

Diese Teildiskussion zerstört vermutlich den Lesefluss der eigentlichen Diskussion, vielleicht kann ein Moderator diese Teildiskussion auslagern.

Das "Killer-Feature" von FHEM war für mich:
Ein Fenster stand offen. Das Alter, der Stress, man kennt das ja: Es ist früh, es regnet, es ist kalt, man muss schnell los, hastig-hastig. Mehrfach stand ein Fenster sehr einladend offen.

Da wäre doch sehr schön, wenn ich ganz kurz mit dem Handy aus der Ferne ... aber bitte ohne Cloud, ohne Drittanbieter, ohne Datenabfluss. So kam ich zu FHEM. Der oft sehr wirren Diskussion der Heise-Foren sei dank.

@curt: Du kannst gerne (passend vermutlich in Off-Topic) einen Thread dazu anfangen und auch von hier dahin verlinken, die OT-Diskussion ist noch nicht so groß, als dass das wirklich störend wäre.

[OT]Ich wollte nur nicht im Haus rumrennen und Rolläden hoch- und runtermachen, also wurden die bei der Renovierung elektrisch. Da es mir aber auch nicht gefallen hätte, alle 6 Monate die Uhr an irgendwelchen einzelnen Zeitschaltuhren von Sommer- auf Winterzeit umzustellen und umgekehrt (so mache ich das im Haus meiner Schwiegermutter), wollte ich das zentral erledigen können.

"Damals" wurde FHEM noch als einfach zu installierende Lösung "beworben", für die man nicht mehr wie eine Fritte und einen CUL braucht. Dann hat AVM den Deal gekündigt, und ich hatte Mühe, ohne Windo.*-Rechner die Fritte nach dem Umzug auf einen Pi wieder so zu säubern, dass automatische updates laufen...

Vielleicht versteht ihr jetzt besser, warum ich latent  angepisst bin, wenn jemand sagt, ein FHEM zu betreiben sei einfach >:( .
Na ja, mittlerweile kann ich das ja - jedenfalls zu meiner eigenen Zufriedenheit 8) . [/OT]

EDIT: Natürlich wollte ich auch in der Platzierung der Schalter etwas freier sein, und sicher fällt mir dann noch mehr ein.
Ich wollte euch aber auch nicht vorenthalten, dass ich jetzt meine readingsGroup dann auch soweit habe. Geht sicher noch hübscher, aber es ist ein Anfang:
defmod rg_Rollaeden readingsGroup <Gerät>,<Offen>,<automode>,<Offen-Pos.>,<Gekippt-Pos.>,<Jalousie>,<On-Hold> (Rolladen_.*|Jalousie_.*)..:level,automode,?WindowContactOpenMaxClosed,?WindowContactTiltedMaxClosed,?JalousieTurnLevel,?WindowContactOnHoldState,
attr rg_Rollaeden commands {'level' => 'pct:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100','automode' => 'automode:0,1,2,3,4,5','WindowContactOpenMaxClosed' => 'WindowContactOpenMaxClosed:10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100','WindowContactTiltedMaxClosed' => 'WindowContactTiltedMaxClosed:10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100',}
attr rg_Rollaeden room Steuerung

Zitat von: Beta-User am 09 März 2018, 21:47:26
Es würde mich sehr freuen, wenn du die jetzige Fassung des HOWTO wenigstens kurz überfliegen würdest.

Nicht in dieser Sekunde. Weil:
Mir ist die ganz grundsätzliche Intention noch nicht ganz klar. Es mag sein, dass die nur mir nicht klar sind. Aber vielleicht sind sie grundsätzlich nicht klar - in dem Fall wäre erstmal sehr klar zu definieren, was überhaupt das Ziel der Veranstaltung ist.

Für mich ist ein howto ein Kochrezept für gebildete Doofe: Linke Hand an linken Griff. Rechten Fuß auf die erste Stufe. Linken Fuß auf die ... Beispielfoto.

Das meinte ich mit einem Absatz "wir setzen mal auf bestehendem RPi ein FHEM auf, bauen eine Device, machen zwei Attribute [Foto], machen etwas Formatierung [Foto]. Und dann freuen wir uns gemeinsam am Ersterfolg (Stichwort menschliches Belohnungssystem).

Zitat von: Beta-User am 09 März 2018, 21:47:26
Zu unser aller Verteidigung:

Es gibt nichts zu verteidigen: Es lag kein Angriff vor.

Das ist das komische, das völlig ungewohnte in diesem Forum. Ansich bin ich gewohnt, ohne Schnörkel präzise zu fragen. Das funktioniert in technischen Foren (Beispiel: ubuntuusers). Genau das funktioniert in diesem Forum nicht. Ansich kannst Du einen Bot schreiben, der auf jeden Beitrag mit einem Fragezeichen als Antwort "Lies commandref" rausrotzt, damit hast Du dann das Forum aus Sicht eines Anfängers umfänglich umschrieben.

Zitat von: Beta-User am 09 März 2018, 21:47:26
Dieses war allerdings im dort noch "Sicherheit" genannten Punkt seit der Einführung des "allowed" völlig veraltet, was nach meinem Eindruck der Anlaß für diesen Hilferuf war.

Das Thema "Sicherheit" ist im eigentlichen Sinne gar kein Thema, was sich für ein howto eignet. Ansich müsste "Sicherheit" ein Artikel im Wiki werden, der dann ausschließlich die Schnittstellen nach Klassen (siehe mein Eingangsartikel) beleuchtet. Ich halte das für wirklich wichtig, da brennt im Grunde die Hütte.

Zitat von: Beta-User am 09 März 2018, 21:47:26
Die jetzige Fassung ist (nach meinem zugegebenermaßen ziemlich betriebsblinden) Verständnis

Da trifft sich "betriebsblind" mit "naiv": Ich bin im Sinne der Sache naiv. Da Naivität nicht zwingend mit Dummheit gleichzusetzen ist, hat das auch Betrachtungsvorteile.

Zitat von: Beta-User am 09 März 2018, 21:47:26
Gerne können wir auch aus deinem vorherigen Beitrag so etwas machen wie eine allgemeine Einführung in zu beachtende Sicherheitsaspekte - mir gehen nämlich die unbedarften Neulinge auch ziemlich gegen den Strich

Ja - siehe oben.
Allerdings denke ich da wirklich an einen eher kurzen Überblicksartikel, der (wie in meinem ersten Beitrag beschrieben) lediglich Server, FHEM, Schnittstellen nennt. Und all diese lediglich verständlich diskutiert. Jeder Unterpunkt hat dann je einen Link auf genauere Betrachtung (erstmal Stubs). Wiki-Syntax kann ich. Anmelden werde ich wohl auch schaffen. Die Frage ist eher: Was passiert, wenn ich einen rohen Artikel schreibe und dann noch fünf Stubs anlage - und das Ganze ohne Kenntnis der dort geltenden informellen Regeln? Ich schreibe eher ungern für die Tonne.

Zitat von: Beta-User am 09 März 2018, 21:47:26
Aber nochmal: es gibt Überschneidungen, aber eigentlich ist es ein Thema für ein weiteres Buch.

Dafür wären ja Links da.
Im Grunde würden wir einen weiteren Namensraum im Wiki schaffen, einen ganz neuen Mikrokosmos. Dazu hätte ich allerdings eine Idee: Wikipedia kennt ja das Kategoriekonzept. Keine Ahnung ob das hier goutiert wird. Aber das würde uns die Möglichkeit schaffen, eine Kategorie "Für Beginner" zu schaffen. Die vielleicht in der allerersten Zeit auch Welpenschutz hat.

Zitat von: Beta-User am 09 März 2018, 21:47:26
Und neben dem Überfliegen hätte ich eine weitere Bitte: Vielleicht hast du weitere Ideen, wie man das ganze noch _etwas_ besser gestaltet, indem man - ggf mit Fußnoten oder so - noch _kurze_ Erläuterungen zu den FHEM-Begrifflichkeiten einfügt, damit auch "Normalos" verstehen, was jeweils gemeint ist.

Ich würde das andersrum angehen - dazu muss ich leider ausholen:
Ich rede mir ja ein, dass ich die Fachsprache "wir reden IT" wirklich beherrsche. Aber (und das ist bis heute mein Problem) bei FHEM ist alles anders. Da gibt es unendlich viele Vokabeln, unendlich viele Abkürzungen, da träumt ja der Militär von. Und die haben schon eine tolle Geheimsprache, die auch irgendwie deutsch klingt. Hinzu kommt, dass in FHEM Vokabeln überdefiniert werden. Was ein Device ist, ist ansich in der IT wohldefiniert. Es mag historisch gewachsen und dadurch bedingt sein: In FHEM liegt die Wahrscheinlichkeit, dass eine Device nun wirklich im IT-Sinne eine Device ist, bei höchstens 10%. Das muss man erstmal verstehen ...

Also ich würde das von mir vorgeschlagene allgemeine Glossar befürworten. Erklärungsbedürftige Vokabeln, die dort nicht vorhanden sind, als Fußnote im Artikel.

P.S: Ich schreibe das alles irgendwie auch aus Eigennutz. Ich finde das Projekt dermaßen geil, habe unendlich viele Ideen für meinkleinHäuschen. commandref hilft mir nicht, wiki hilft mir nicht, Forensuche fördert Threads mit 80 Seiten zu Tage - soll ich jede Seite wirklich lesen? Aber im Grunde wäre es so einfach - ich lerne am besten an Beispielen.

PP.S: Beispiel: https://forum.fhem.de/index.php?action=dlattach;topic=37378.0;attach=69879;image
Boah, issja geil. Haben will! Das will ich bauen, ich muss da nichtmal das allerletzte Attribut verstehen. Es muss dann halt tun. Wo ist das howto dazu?

Hallo Curt,

Zitat
PP.S: Beispiel: https://forum.fhem.de/index.php?action=dlattach;topic=37378.0;attach=69879;image
Boah, issja geil. Haben will! Das will ich bauen, ich muss da nichtmal das allerletzte Attribut verstehen. Es muss dann halt tun. Wo ist das howto dazu?

Ist meins. Kann dir die aktuellen sourcen schicken und die devices dahinter erklären. Hast aber nie danach gefragt! Ist mühsam sich das ganze aus einem 80 Seiten Thread rauszuholen. Bastelt sich halt jeder was für sich zusammen und schreibt nicht noch eine Doku dazu die veröffentlicht wird.

Gruß
Eisix

OT
Beziehungsweise nur teilweise offtopic - es wird aber auch wider ontopic.

Zitat von: Eisix am 09 März 2018, 23:19:19
Ist meins. Kann dir die aktuellen sourcen schicken und die devices dahinter erklären. Hast aber nie danach gefragt! Ist mühsam sich das ganze aus einem 80 Seiten Thread rauszuholen.

Hallo Eisix,

ich weiß nicht mehr, was ich im Forum suchte. Jedenfalls stolperte ich Anfänger über Deinen Beitrag und den (von mir verlinkten) Screenshot. Und ich dachte mir: Das muss ich mir unbedingt speichern, wenn ich mal groß bin, will ich sowas geiles haben.

Dein Angebot nehme ich sehr-sehr gern an. Erkläre mir bitte, wie man sowas wunderschönes macht. Aber bitte nicht in dem 80-Seiten-Thread! Da findet das doch niemand. Ich habe doch nichtmal geschafft, Dein Posting dort zu finden, ich hatte nur den Screenshot als Bookmark gespeichert.

Ich nehme herzlich gern Dein Angebot wahr: Kannst Du mir das Vorgehen bitte in einem völlig neuen Thread erklären? So, dass ich das schrittweise dann auch bei mir habe?

Damit sind wir wieder ontopic: Denn das wäre ja ein howto.
Ich habe ein ganz geiles, viel gelobtes Dings - und ich gebe euch jetzt das Kochrezept. Wenn ihr euch an mein Kochrezept haltet, habt ihr das auch auf dem eigenen Tisch.

Zitat von: Eisix am 09 März 2018, 23:19:19
Bastelt sich halt jeder was für sich zusammen und schreibt nicht noch eine Doku dazu die veröffentlicht wird.

Daran krankt es - aus meiner Anfängersicht.

Ich hatte übrigens nicht erwartet, dass der Ersteller/Konstrukteur/Designer/Coder sich meldet. Das war von mir nur als Beispiel gedacht. Um so mehr freue ich mich, dass Du Dich gemeldet hast.

Witzig, wie klein die Welt manchmal ist. Irgendwie auch bezeichnend, dass ihr euch gerade hier in diesem Thread  "wiedergefunden" habt.

Was den grundsätzlichen Einwand von curt angeht: Mittlerweile sehe ich das auch kritisch, ob "HOWTO" die richtige Etikette ist. Das war ja auch die Irritation, die andere z.B. unter dem Stichwort "instructables" geäußert hatten.

Ich persönlich hätte keinerlei Problem damit, die Etikette zu ändern. Gibt es Einwände von "höherer Stelle" dazu? Vorschläge? Schnellschüsse meinerseits: "Schnelleinstieg", "Kurzreferenz"

Dass wir "Neuen" uns alle ziemlich unwohl fühlen mit der vorhandenen Doku zeigen ja auch Otto's und mein erster Post hier (und wer mag, kann ja meine User-Vorstellung "Meine Hausaufgaben"  mal nachlesen, da sieht man, wie lange mich das Thema schon umtreibt). Als "Kochrezept für Doofe" würde ich  übrigens das Einsteiger-pdf ansehen, da ist wirklich vieles einfach zum Nachkochen drin. Leider ist es an manchen Stellen veraltet und FS20 bzw. HM-lastig.
Was also wieder fehlt, ist auch nach meinem Eindruck ein schlüssiges Gesamtkonzept, das einen interessierten Starter wirklich zu einem funktionierenden "Basis-FHEM" einschließlich einer ansprechenden ersten Seite (defaultRoom mit der einen oder anderen readingsGroup, _nicht_ aber ein konkretes anderes Frontend) leitet und dann auch an die anderen Schnittstellen sauber weiter verzweigt (Floorplan, FTUI usw.).

Und meine Beobachtung ist die: Es passiert was, aber wenig. Am ehesten wird noch daran gearbeitet, wenn man "einfach mal loslegt" und die Dinge dann eben der Kritik öffentlich aussetzt, wie krikan das ja auch angeregt hat. Wir sollten nur aufpassen, dass nicht wieder jemand in 5 Jahren kommt und zurecht kritisiert, dass "unsere" Art der Darstellung völlig ... (was auch immer) war und leichter zu aktualisieren ist wie das pdf.

Zu den übrigen Stichworten:
Es gab zum wiki bisher nicht so richtige Vorgaben, außer der, dass die Darstellung neutral zu sein hat (so hatte ich das jedenfalls frei interpretiert). Ich würde das ergänzen mit: Wer was anfängt, sollte es in einem erträglichen Zustand hinterlassen...

Kategorisieren geht im Wiki, ich finde sowas wie ein "Für Beginner"-Label  übrigens eine ausgezeichnete Idee! (Sowas in die Richtung steckte auch hinter dem wine-Hinweis mit "bronce, silver & gold").

Mit dem "Einsteiger" oder "Basis" oder "...."-Label würde ich übrigens noch die Stichworte defaultRoom, readingsGroup, WeekdayTimer, readingsProxy, THRESHOLD bekleben wollen.

Just my2ct

@krikan:
Du bist ja immer noch der owner dieses Threads. Bitte um Rückmeldung, wenn das hier "zu bunt" wird.

Was ich zur Auslagerung vorschlagen würde, wäre die Sache mit den Kategorien, das ist ja etwas, was das Wiki allgemein betreffen würde. Bevor ich da aber eine Lawine mit einer Umfrage oder so lostrete: Macht sowas überhaupt Sinn, oder wäre das ein nutzloser Schnellschuß?

EDIT: Ich sehe grade, dass es hier (https://forum.fhem.de/index.php/topic,83885.0.html) eine etwas anders gelagerte, aber teilweise verwandte Diskussion gibt. Müßte man ggf. dann noch abstimmen, wie das mit dem folgenden zueinander paßt.

@all
Wenn ja, wären weitere (welche?) Level sinnvoll?

Meine Tendenz wäre: nicht zu viele und jeweils eine Erläuterung wäre vermutlich auch hilfreich. Ich würde spontan nur englische Begrifflichkeiten bevorzugen und diese Richtung andenken:

Starter: Dinge, die man schnell kennen lernen sollte, um ein funktionsfähiges FHEM zu haben
Basis: Dinge, die jeder kennen sollte. Grundlagenwissen. In Perl gedacht: if-Abfrage
Advanced: Schwieriger zu konfigurieren, benötigt ggf. etwas Perl (Umgang mit einfachen Variablen und Schleifen)
Expert: Besser erst ansehen, wenn man ca. eine Handvoll "Advanced"-Themen erfolgreich gelöst hat

[OT]Der auf Automatik eingestellte Teil meiner Rolläden machte heute morgen genau dann das, was er sollte. Das bedeutet: Mein WeekdayTimer-Provisorium funktioniert definitiv heute schon besser als die mehrfach erfolglos verschlimmbesserte vorherige Lösung ;D [/OT]

Jetzt interessiert mich dann aber langsam schon, was du mit deinen Rolläden angestellt hast, dass du dich so drüber freust ;).

Ansonsten wäre ich dafür, dass wir zuerst das HOWTO (oder wie auch immer man es nennen mag) zweisprachig zu Ende führen, bevor wir uns von anderen Ideen ablenken lassen. Oberstes Ziel muss sein, eine kurze Dokumentation für Einsteiger zu schaffen.

Aber jetzt bin ich vorläufig mal ruhig, bis ich den heutigen Kater überstanden habe. Also bis übermorgen ;D

Zitat von: Beta-User am 10 März 2018, 11:06:54
Was ich zur Auslagerung vorschlagen würde, wäre die Sache mit den Kategorien, das ist ja etwas, was das Wiki allgemein betreffen würde. Bevor ich da aber eine Lawine mit einer Umfrage oder so lostrete: Macht sowas überhaupt Sinn, oder wäre das ein nutzloser Schnellschuß?

EDIT: Ich sehe grade, dass es hier (https://forum.fhem.de/index.php/topic,83885.0.html) eine etwas anders gelagerte, aber teilweise verwandte Diskussion gibt. Müßte man ggf. dann noch abstimmen, wie das mit dem folgenden zueinander paßt.

Löst bei mir aus: Angst
Warum: Gerade das Thema Kategorien wurde schon x-mal angegangen. Es endete immer wieder in einem unstrukturierten Kategorien-Durcheinander im Wiki, weil es nicht zu Ende geführt/gedacht und dauerhaft gepflegt wurde. Anschließend musste dann jemand anderes das wieder aufräumen und dem fehlt die Zeit für den eigentlichen Inhalt. Da es nur sehr wenige aktive Wiki-Schreiber gibt, die dauerhaft über ihren "eigenen" Artikel hinaus mitarbeiten (keine Kritik!), bleibt das immer an den Gleichen hängen.
Zum Vorschlag: Schwierigkeitsgrad. Wer bestimmt die Einstufung? Das ist mMn für jeden anders und daher schwer pflegbar.
Bitte auf jeden Fall den Vorschlag mit Peter (ph1959de) abstimmen und am besten in einen separaten Thread auslagern.

Ob der Artikel in alter Tradition "HOWTO" heißt oder einen anderen sinnvollen Namen hat, ist mir persönlich gleichgültig. Entscheiden dürfen die, die die Arbeit gemacht haben (ihr).
Ansonsten stimme ich drhirns obigen Satz mit "Ansonsten..." zu.  :)
Besser Schritt für Schritt als eierlegende Wollmilichsau.

OK, Danke für die klare Rückmeldung!

Dann bleibt also vorerst noch:
- Wie taufen wir das Kind? Vorschläge? (sollte wohl am Ende dann krikan umsetzen)
- Braucht es noch ein hardwareloses Device? (M.E. eher nicht, und wenn, dann eher in dem jetzigen Anmerkungskasten rechts)
- Device erklären? (Wäre dafür, nicht wesentlich mehr als: Kann, muß aber nicht zwingend ein physisches Gerät sein. Device bei FHEM ist schlicht alles, für das eine "define ..."-Anweisung existiert bzw. eingegeben wurde/wird/werden kann.

[OT]Zu meinen Rolläden:
Hatte ich unten ja kurz angerissen. Einfach mit setreading ein Reading mit Namen "automode" an alle Rolladenaktoren verteilt (FILTER s.u.) und mit "0" vorbelegt. Jetzt kann ich die, die ich automatisch fahren will, damit beliebig kennzeichnen (habe mal an bis zu 5 Gruppen gedacht, im Moment sind die schlicht auf "1", Einstellung via notify für Urlaub, Gäste in best. Räumen+readingsGroup). Dazu kommt ein einfacher Weekdaytimer mit einem Ausführungsteil, der "TYPE=CUL_HM:FILTER=model=HM-LC-Bl1PBU-FM:FILTER=automode=1" enthält:

defmod Timer_Rolladen_Automode_1 WeekdayTimer TYPE=CUL_HM:FILTER=model=HM-LC-Bl1PBU-FM:FILTER=automode=1 !$we|06:45|on $we|08:40|on 22:30|off {fhem ("set $NAME:FILTER=STATE!=$EVENT $EVENT")}
attr Timer_Rolladen_Automode_1 commandTemplate set $NAME  $EVENT
attr Timer_Rolladen_Automode_1 group Türen und Fenster
attr Timer_Rolladen_Automode_1 icon fts_shutter_automatic
attr Timer_Rolladen_Automode_1 room Steuerung
Wenn ich dann noch lustig bin, mache ich noch ein notify, dass ggf. vor dem Endezeitraum auf hereinbrechende Dunkelheit reagiert (mit disableForIntervals), dann habe ich das auch "wie früher". Oder ich nutze (zusätzlich) sunrise&co...
[/OT]

[OT]
@curt schau Mal in dein Postfach und gib mir Rückmeldung ob du damit was anfangen kannst.
[\OT]

Habe noch ein paar kleine Änderungen vorgenommen. Da stand z.B., man solle was in die fhem.cfg eintragen ;)

Kann bitte jemand den Abschnitt "Daten aufzeichnen und darstellen" überarbeiten? Ich glaube, der ist nicht verständlich.

Und sollen wir am Schluss vielleicht noch auf die anderen Dokumente (PDF, Erste Schritte, etc.) verweisen?

So, anbei auch noch ein erster Wurf der englischen Übersetzung (ohne den vermutlich zurecht kritisierten Teil zu Daten aufzeichnen usw., das ggf. der Überarbeitung bedarf; Basis war die noch nicht überarbeitete deutsche Fassung, sollte also ggf. auch dahingehend nochmal geprüft werden, wobei das mit dem "Eintrag in die fhem.cfg" da schon raus ist).

Das pdf und die ersten Schritte sind ja im Text schon aufgeführt, das wäre also ggf. eine Doppelung.

Was die "ersten Schritte" angeht, geht es mir zwischenzeitlich wie anderen mit "Howto" - ich empfinde das nicht mehr ganz als zutreffende Begrifflichkeit. Das klingt so, als müsse man diese gehen. Einen besseren Vorschlag habe ich aber grade auch nicht. Dafür fände ich es keine schlechte Idee, dort ggf. statt eines der Dummy's ein presence-Device vorzustellen und damit zu schalten (nur aus dem Kopf, ich habe mir das nicht im Detail angesehen), und das ist beides hier ja auch nicht das Thema.

Gruß, Beta-User

Zitat von: Beta-User am 12 März 2018, 15:01:45
So, anbei auch noch ein erster Wurf der englischen Übersetzung (ohne den vermutlich zurecht kritisierten Teil zu Daten aufzeichnen usw., das ggf. der Überarbeitung bedarf; Basis war die noch nicht überarbeitete deutsche Fassung, sollte also ggf. auch dahingehend nochmal geprüft werden, wobei das mit dem "Eintrag in die fhem.cfg" da schon raus ist).

Ich lese den gerade Korrektur.

Ja, wäre eine Doppelung. Die aber meiner Meinung nach nicht stören würde. Ich persönlich klicke eher auf einen Link am Ende der Seite (nachdem ich alles gelesen habe), als irgendwo mittendrin. Würde es einfach ganz unverfänglich "Weitere Informationen" oder so nennen.

Ein presence-Device hat wieder physische Abhängigkeiten. Ich persönlich bin der Meinung, Uli hat sich beim Schreiben der "Ersten Schritte" schon richtig für den Dummy entschieden.

Wie sollen wir die englische Seite nennen? Und können wir eventuell die deutsche Umbenennen? Alles in Großbuchstaben ist irgendwie merkwürdig.

Zitat von: Christoph Morrison am 12 März 2018, 15:06:53
Ich lese den gerade Korrektur.

DANKE!

Zur Namensgebung: Hatte ja "Schnelleinstieg" oder "Kurzreferenz" vorgeschlagen und eben Leo befragt. Das macht da einen "Quick Guide" draus. Auf was besseres bin ich bisher nicht gekommen, wobei mir die Leo-Begrifflichkeit eigentlich spontan noch am besten zusagt. Wie kommen wir da am effektivsten zu einer dauerhaft(-er) befriedigenden Lösung?

Das einheitlich de+en zu verwenden wäre evtl. auch gar nicht so schlecht, weil es keine (großen inhaltlichen) Überschneidungen mit den ersten Schritten vermuten läßt und ja tatsächlich auch anders gelagert ist.

Was "erste Schritte" sonst angeht: Ist hier OT und bedarf wegen mir keiner weiteren Diskussion...

Und das mit der Linkliste: von mir aus...

"Schnelleinstieg" ergäbe dann "Quick Start". Fände ich beides eigentlich ganz gut.

...wobei "Start" vom Begriffsinhalt her mehr mit "erste Schritte" gemeinsam hat.

Allerings kann man natürlich auch die Frage stellen, wieviel "Guide" denn da drin ist. Aber deswegen sprechen wir ja drüber :) .

Hehe ;)

Wir können's auch einfach bei HowTo belassen (Howto_de, Howto_en). Aber halt nicht alles groß geschrieben ;)

Ist der Teil über Plots/Logs/FHEMWEB in der englischen Übersetzung absichtlich nicht übersetzt?
Egal. Soweit erst mal das, was übersetzt war + ein bisschen von mir.

Zitat von: Christoph Morrison am 12 März 2018, 15:45:14
Ist der Teil über Plots/Logs/FHEMWEB in der englischen Übersetzung absichtlich nicht übersetzt?

Zitat von: Beta-User am 12 März 2018, 15:01:45
[...](ohne den vermutlich zurecht kritisierten Teil zu Daten aufzeichnen usw., das ggf. der Überarbeitung bedarf;

Ergo: ja (ist ja auch nicht mehr so viel, aber doppelt wollte ich die Arbeit dann nicht machen...).

Zitat von: Beta-User am 12 März 2018, 15:49:12
Ergo: ja (ist ja auch nicht mehr so viel, aber doppelt wollte ich die Arbeit dann nicht machen...).

Ah ok, ich habe hier nicht alles nachgelesen. Hatte aber auch das Gefühl, dass das Zeug unten extrem holprig und wenig hilfreich ist. Rev und diff hängen oben an.

Danke für's Gegenlesen. Fully agreed!

Habe eben auch noch auf Basis des Textes hier und der commandref eine Rohversion für allowed erstellt: https://wiki.fhem.de/wiki/Allowed

Vielleicht mag da ja auch gleich noch jemand drübersehen (war allerdings jetzt etwas sehr auf die Schnelle, aber besser als nix...).

Ist die leere Kategorie Absicht?

Zitat von: Beta-User am 12 März 2018, 18:09:55
Habe eben auch noch auf Basis des Textes hier und der commandref eine Rohversion für allowed erstellt: https://wiki.fhem.de/wiki/Allowed

Methode "kurz-knackig-aua" ist erlaubt?

Ich bin ja Dein perfekter Testnutzer - ansich wollte (und will) ich Dich darum bitten, in diesem Thread in wirklich jedem Deiner Beiträge als Footer ein "Es geht um das howto, die aktuelle Version ist hier [link]" zu schreiben. Ich bin doch auch faul, ich suche da doch nicht immerzu.

Aber zur Sache, zu https://wiki.fhem.de/wiki/Allowed

a) Eine Einleitung hat einzuleiten. Um was geht es hier? (Das ganze andere Geraffel gehört nach unten, in "Allgemeine Hinweise", was als Punkt noch fehlt.)

b) Der erste Absatz darf nicht gleich die Lösung anbieten. Sondern muss erklären, was das Problem ist. Ganz grob: "Der externe Zugriff auf den eingebauten FHEM-Webserver sowie den eingebauten FHEM-telnet-Server wird über 'das Device' allowed gesteuert."

c) Bisheriger erster Absatz "Syntax" wird zweiter Absatz.

Zitat von: Beta-User am 12 März 2018, 18:09:55
Vielleicht mag da ja auch gleich noch jemand drübersehen (war allerdings jetzt etwas sehr auf die Schnelle, aber besser als nix...).

Done.
Nicht hauen, bitte. Ich bin im Team der Guten - ich will nichts anderes als Du. Du packst aktiv an, was ich nur kritisch anschaue, ich weiß, ich weiß.

BTW: Kannst Du bitte in wirklich jedem Deiner Forenbeiträge den eigentlichen Bezug (als Link) ganz unten posten? Du sparst uns allen viel Zeit, die günstige Mitleser mir Sucherei verplempern.

Danke für die Rückmeldungen zu "allowed (https://wiki.fhem.de/wiki/Allowed)", es braucht auch wohlmeindende und kompetente Kritiker :) .

Zu allowed:
- Es gibt jetzt eine kurze Einleitung und eine "Einführung". Der Beitrag ist immer noch kurz und knackig, aber immerhingibt es ihn jetzt (s.u.).
- Die Kategorisierung habe ich gelöscht, das war im ersten Wurf als Merker gedacht, dass da noch was einzutragen ist. Das korrekte Einsortieren im Wiki scheint aber mit der "Modulbox" automatisch zu erfolgen (hat etwas gedauert, bis auch ich den Mechanismus vielleicht verstanden habe ::) ). Ob das in der Form zielführend ist, ist eine andere Frage.

(Sorry, dass ich an der Stelle mal wieder "einfach mal anfangen" praktiziert habe, aber mir ist zufällig aufgefallen, dass der bisher nur auf der Liste der gewünschten Seiten (https://wiki.fhem.de/wiki/Spezial:Gew%C3%BCnschte_Seiten) gestanden hatte. Das war - nachdem allowed seit ca. 9 Monaten auf der Welt ist - noch unbefriedigender, als mit dem stub zu beginnen...)

[OT]
Was das ganze Thema mit den Kategorien angeht, empfinde ich das als sehr verwirrend. Die Mindmap (die ist übrigens zu klein, um was auf einem kleineren Laptop-Monitor zu erkennen, dann muß man sich zum Quelltext durcharbeiten oä. :( ) z.B. habe ich eben wieder erfolglos gesucht, dabei aber festgestellt, dass es derzeit jedenfalls faktisch eine deutlich größere Anzahl von Kategorien gibt (was vermutlich auch mal aufgeräumt gehört. Dafür gibt es eine Seite mit "gewünschten Kategorien", die leer ist ??? .
Dann hatte ich versucht rauszufinden, was richtigen Optionen/Einstellungen wären, um "meinen" ThinClient-Artikel sauber einzusortieren, was mir dann am Ende doch nicht gelungen ist... Kann natürlich sein, dass das nicht dasselbe Gewicht hat wie BeagleBone Black, aber richtig logisch ist das ganze an der Stelle nicht. Denn irgendwo sollte ja bei "Server" wenigstens die Option bestehen, "normale" x86-HW einzusortieren (Zotac, Brix, NUC und Co.).
Wenn es einfach möglich sein sollte, den Hauptakteuren im Wiki da beim Aufräumen und Ergänzen der Hilfestellung für Geegenheits-Wiki-Autoren zu helfen, bitte ich um halbwegs verständliche Instruktionen, dann "fange ich damit halt mal an"...
[/OT]

Zum "howto":
Soll es zukünftig "Quick Guide" oder "Quick Start" heißen? (Bessere Vorschläge nehmen wir auch noch an, oder?)

Votiere für "Guide". Wenn das geklärt ist, geht dann auch die dann aktuelle engl. Fassung unter dieser Flagge online und die deutsche wird "verschoben". Stimmenabgabe bis Ende der Woche?

Gruß, Beta-User

Abspann: Link zum "howto (https://wiki.fhem.de/wiki/HOWTO)"

Zitat von: Beta-User am 13 März 2018, 10:15:17Sorry, dass ich an der Stelle mal wieder "einfach mal anfangen" praktiziert habe

Nur so wird das Wiki befüllt. Nacharbeiten können dann ja andere. Passt also schon, finde ich.

ZitatSoll es zukünftig "Quick Guide" oder "Quick Start" heißen? (Bessere Vorschläge nehmen wir auch noch an, oder?)

Ich bin da wertneutral

ZitatAbspann: Link zum "howto (https://wiki.fhem.de/wiki/HOWTO)"

;D

Ich votiere für "Quick Start". Ein Guide ist IMHO wieder etwas ausführlicher und findet sich eher im Erste-Schritte-PDF. Es geht ja wirklich erst mal nur darum, einen Überblick zu bekommen.

vielleicht nur als kleine idee....

bei
https://wiki.fhem.de/wiki/HOWTO#Wichtige_Befehle_f.C3.BCr_die_erste_Zeit
könntest du auch noch die links auf die wiki seiten der befehle setzen.
(mir ist bewusst das die commandref der _master_ ist :) )

Done, wo vorhanden...

Darf ich's umdrehen? Zuerst commandref, dann ein Link zum Wiki? Das immer-gültige zuerst.

Hallo Beta-User, mal kurz zu Deinen Off-Topics:

Zitat von: Beta-User am 13 März 2018, 10:15:17
Das korrekte Einsortieren im Wiki scheint aber mit der "Modulbox" automatisch zu erfolgen (hat etwas gedauert, bis auch ich den Mechanismus vielleicht verstanden habe ::) ).

Ja, abhängig vom gewählten Modultyp wird automatisch eine Kategorie gesetzt; die Zuordnung weiterer Kategorien ist natürlich möglich, muss aber manuell erfolgen.

Zitat von: Beta-User am 13 März 2018, 10:15:17
Ob das in der Form zielführend ist, ist eine andere Frage.

In wiefern zielführend? Wie gesagt: das Setzen weiterer Kategorien ist möglich (und sicherlich auch sinnvoll, aber nicht automatisch über den Modultyp möglich).

Zitat von: Beta-User am 13 März 2018, 10:15:17
dass der bisher nur auf der Liste der gewünschten Seiten gestanden hatte

Das passiert "automatisch", sobald jemand irgendwo die Seite mit [[allowed]] verlinkt (oder allgemein einen Text in [[]] stellt, den es nicht als eigene Wiki Seite gibt; mögliche Gründe also: Tippfehler, echte Absicht, eine bestimmte Seite anzulegen, Gedankenlosigkeit, ...).

Zitat von: Beta-User am 13 März 2018, 10:15:17
Dafür gibt es eine Seite mit "gewünschten Kategorien", die leer ist...

Auch hier: passiert "automatisch", sobald jemand eine noch nicht vorhandene Kategorie setzt (kann natürlich auch ein simpler Tippfehler in einem Kategorienamen sein).

Zitat von: Beta-User am 13 März 2018, 10:15:17
Die Mindmap (die ist übrigens zu klein...

Die Mindmap war seinerzeit (vor Jahren) nur ein Hilfskonstrukt um die Kategoriestruktur zu visualisieren. Ich werde bei Gelegenheit noch mal suchen, ob es dafür hilfreichere MediaWiki Tools gibt (ich glaube, der damalige Wiki-Admin wollte die zu der Zeit existierenden Tools nicht benutzen - Gründe weiss ich nicht mehr; da sind wir aber jetzt u.U. mehr Freiheiten).

Zitat von: Beta-User am 13 März 2018, 10:15:17
Denn irgendwo sollte ja bei "Server" wenigstens die Option bestehen, "normale" x86-HW einzusortieren (Zotac, Brix, NUC und Co.).

Denen würde ich vorerst die Kategorie "Server" verpassen - sobald mehrere Seiten zu einem Thema in dieser Oberkategorie auftauchen, sollten wir über eine eigene Unterkategorie nachdenken.

Mach gern zu solchen Dingen einen eigenen Thread hier in diesem Forenbereich auf - lässt sich hier sicherlich leichter diskutieren, als auf Wiki (Diskussions-)Seiten.

Peter

Zitat von: Beta-User am 13 März 2018, 11:15:28
Done, wo vorhanden...

super

Zitat von: drhirn am 13 März 2018, 11:18:28
Darf ich's umdrehen? Zuerst commandref, dann ein Link zum Wiki? Das immer-gültige zuerst.

ist mir recht!


nur jetzt sind die links leider "kaputt" (siehe screenshot) :(

Zitat von: drhirn am 13 März 2018, 11:18:28
Darf ich's umdrehen? Zuerst commandref, dann ein Link zum Wiki? Das immer-gültige zuerst.

Gibt es einen Grund, warum Du in vielen Fällen den Namen des Befehls durch "commandref" ersetzt hast? Ich würde da den Befehl erwarten. So ist es etwas unübersichtlich und erst unterscheidbar, wenn man mit dem Mauszeiger über den Link geht (d.h. für Tablet-/Handy-Benutzer gar nicht?).

Peter

Zitat von: ph1959de am 13 März 2018, 12:03:52
Gibt es einen Grund, warum Du in vielen Fällen den Namen des Befehls durch "commandref" ersetzt hast? Ich würde da den Befehl erwarten. So ist es etwas unübersichtlich und erst unterscheidbar, wenn man mit dem Mauszeiger über den Link geht (d.h. für Tablet-/Handy-Benutzer gar nicht?).

vermutlich copy&paste-fehler

so wäre es (glaube ich) richtig
==Wichtige Befehle für die erste Zeit==
*{{Link2CmdRef|Anker=list|Lang=de|Label=list}} - ([[list|Wiki]])
*{{Link2CmdRef|Anker=define|Lang=de|Label=define}}
*{{Link2CmdRef|Anker=defmod|Lang=de|Label=defmod}}
*{{Link2CmdRef|Anker=version|Lang=de|Label=version}} - ([[version|Wiki]])
*{{Link2CmdRef|Anker=update|Lang=de|Label=update}} - ([[update|Wiki]])
*{{Link2CmdRef|Anker=shutdown|Lang=de|Label=shutdown}}
*{{Link2CmdRef|Anker=notify|Lang=de|Label=notify}} - ([[notify|Wiki]])
*{{Link2CmdRef|Anker=at|Lang=de|Label=at}} - ([[at|Wiki]])
*{{Link2CmdRef|Anker=sleep|Lang=de|Label=sleep}}
*{{Link2CmdRef|Anker=cancel|Lang=de|Label=cancel}}
*{{Link2CmdRef|Anker=watchdog|Lang=de|Label=watchdog}} - ([[watchdog|Wiki]])

Uhh, sorry! Da hatte ich wohl einen Komplett-Blackout. Änder ich natürlich gleich!

Danke für die Erläuterungen, langsam wird das Bild auch an der Stelle etwas klarer.

Ich wollte (und will eigentlich auch weiterhin) keinen separaten Thread aufmachen. Das wäre für eine konkrete kleine Anwenderfrage ok, aber ich will nicht "das ganze Internet" diskutieren oder Grundsatzfragen aufwerfen, sondern "nur" die Dinge halbwegs ordentlich zu Ende bringen, die ich angestoßen habe...

Mit zielführend war gemeint, dass insbesondere "allowed" zwar irgendwie auch ein "Hilfsmodul" ist (so jedenfalls die Festlegung des Autors in der commandref), diese Kategorisierung aber aus Nutzersicht (Wiki...) welche Aussage haben soll? Die sachlich korrekte Sortierung entsprechend commandref ist ok, aber ich fände hier Stichworte wie "Sicherheit", "FHEM-Verwendung" (ist es das nicht irgendwie fast immer?) oä. hilfreich. Da ich aber eben in der (wie ich gelernt habe) automatisch erstellten Liste nichts gefunden habe, was ich ergänzend gerne unten reingeschrieben hätte, bleibt es eben bis auf weiteres ohne eine derartige Angabe.

Das mit den Kategorien in der "Server-Hardware" ist auch geklärt, das kommt eben schlicht daher, dass z.B. die beiden BBB-Varianten in anderen Artikeln als Kategorie angegeben sind und daher in "Unterkategorien" auftauchen und nicht unten bei "Seiten". Ob das jeweils Sinn macht, sei mal dahingestellt, denn einer der Artikel verweist nur auf sich selbst, die anderen behandeln Email-Themen unter (Debian-)Linux (also was generelles und völlig HW-unabhängiges), im anderen Fall geht es um das auch bei anderen SBC's bestehende Problem, wie mit einer (noch) fehlenden Systemzeit umzugehen ist...

Wie gesagt, darüber kann man insgesamt lange diskutieren, aber wie bereits gesagt: das ist nicht mein Anliegen...

Zitat von: drhirn am 13 März 2018, 11:18:28
Darf ich's umdrehen? Zuerst commandref, dann ein Link zum Wiki? Das immer-gültige zuerst.

Klar, hatte keine speziellen Hintergedanke bei der ursprünglichen Variante und die nils_-Fassung gefällt mir gut. @drhirn: Machst du dann damit c&p :) .

Zitat von: Christoph Morrison am 13 März 2018, 10:35:46
Ich votiere für "Quick Start". Ein Guide ist IMHO wieder etwas ausführlicher und findet sich eher im Erste-Schritte-PDF. Es geht ja wirklich erst mal nur darum, einen Überblick zu bekommen.

Leuchtet mir ein, auch wenn ich die damit bestehende "Nähe" zu "ersten Schritten" wieder nicht so klasse finde. Aber it's always compromizing...

Zitat von: Beta-User am 13 März 2018, 12:24:07
Mit zielführend war gemeint, dass insbesondere "allowed" zwar irgendwie auch ein "Hilfsmodul" ist (so jedenfalls die Festlegung des Autors in der commandref), diese Kategorisierung aber aus Nutzersicht (Wiki...) welche Aussage haben soll? Die sachlich korrekte Sortierung entsprechend commandref ist ok, aber ich fände hier Stichworte wie "Sicherheit", "FHEM-Verwendung" (ist es das nicht irgendwie fast immer?) oä. hilfreich. Da ich aber eben in der (wie ich gelernt habe) automatisch erstellten Liste nichts gefunden habe, was ich ergänzend gerne unten reingeschrieben hätte, bleibt es eben bis auf weiteres ohne eine derartige Angabe.

Ich verstehe was Du meinst - daher auch der Hinweis auf das was automatisch möglich ist.

Aber deine Ergänzungen zu dem Thema ... lassen mich fragen (mich selbst und auch andere - Christian/Krikan?), ob sich nicht aus dem überlicherweise auch über die Modul-Infobox verlinkten Forenbereich eine weitere sinnvolle Kategoriezuordnung ableiten lässt.

Peter

[Teilweise OT]

Zitat von: drhirn am 08 März 2018, 11:45:25
Andererseits könnte es uns davor retten, dass alle anfangen, FHEM auf Windows zu installieren. Ein Raspberry ist eine kleine Einstiegshürde.

Aus gegebenem Anlaß (https://forum.fhem.de/index.php/topic,85682.0.html) greife ich den Punkt auch nochmal auf. (Vorab: ich habe keine umfangreiche Analyse gemacht, sondern gebe mal wieder nur Eindrücke wieder)

Stand der Dinge ist der, dass
- ein Einsteiger (verstanden als versierter Windows-Nutzer) immer noch sehr gut beraten ist, als Serverplattform ein (ggf. virtualisiertes) Linux zu wählen und einen Bogen um das zu machen, was er kennt (OS X-Anwender sind da außen vor). Die meisten Anleitungen (wie diese hier auch) gehen dabei standardmäßig davon aus, dass ein recht aktuelles Debian-Derivat (idR. Raspbian) läuft, oft eben auf einem Pi.
- dies nirgends im Wiki ausdrücklich oder jedenfalls deutlich erkennbar in die Richtung leitend steht.

"Früher" war das etwas anders, da gab es eine andere "Lieblingsplattform" für Einsteiger (von AVM), auf die dann so verwiesen wurde, dass Leute, die anderes vor hatten (Windows) zumindest die Chance hatten zu erkennen, dass sie damit von eben diesem (Linux-basierten) Standard abweichen werden und ggf. in entsprechende Probleme laufen.

"Heute" sollte es so sein, dass ein installationswilliger Mensch entweder wirklich
- frei wählen kann, welche Basis er nehmen will (hat er jedenfalls nach meiner Kenntnis eigentlich halt doch nicht oder nur unter Inkaufnahme erheblicher "Schmerzen") oder
- Hinweise erhalten sollte, wie er zweckmäßigerweise vorgehen sollte.

Die "gemischten Gefühle" zum Thema Pi kann ich  sehr gut nachempfinden - Themen wie die Frage, ob das gewerblich da Werbung wäre, über die Schlagworte SD-Karten, RTC und (vor allem) der Vermischung von Steuerung und Hardware bei Nutzung der GPIO's kann man lange und ausführlich diskutieren. Auch ist sowas immer irgendwie subjektiv, was gegen die allg. Wiki-Prinzipien wäre. Dennoch werde ich das Gefühl nicht los, dass man dazu irgendwo (bzw. ggf. an mehereren Stellen) ein paar einfache und klare Worte verlieren sollte. Vielleicht nicht einseitig zugunsten des Pi (ich habe nicht umsonst Versuche mit anderer HW gemacht und mein FHEM läuft jetzt auf einer anderen Plattform), aber bislang fehlt mir da eine zündende Idee.

Stellen, an die sowas ggf. gehören könnte: "Planung (https://wiki.fhem.de/wiki/Planung)" (hat eigentlich einen ganz anderen Fokus, jedenfalls soweit man das bei diesem stub schon erkennen kann) und "Server Hardware (https://wiki.fhem.de/wiki/Kategorie:Server_Hardware)" (Die Einleitung ist hier "sehr neutral" und fängt an mit: ...Windows). Die Installationsanleitung für Windows (https://wiki.fhem.de/wiki/Windows_-_FHEM_installieren) ihrerseits schweigt sich dazu aus, dass das eher als "experimentell" zu bezeichnen ist (Jedenfalls gibt es weder vorne noch hinten einen optisch deutlich wahrnehmbaren Hinweis dazu)...

Aber vielleicht übersehe ich ja auch was und der Selbstversuch von "the ratman" gibt doch nicht den aktuellen Stand der Dinge zu Windows wieder?

Zitat von: ph1959de am 13 März 2018, 12:37:56
Aber deine Ergänzungen zu dem Thema ... lassen mich fragen (mich selbst und auch andere - Christian/Krikan?), ob sich nicht aus dem überlicherweise auch über die Modul-Infobox verlinkten Forenbereich eine weitere sinnvolle Kategoriezuordnung ableiten lässt.

Wäre Automatisierung - bringt m.E. auch keinen wirklichen Mehrwert für Wiki-Leser.
Eine stringentere Vorgabe in den Kategorien wäre m.E. angezeigt, zumal das mindmap ja auch alles andere als aktuell zu sein scheint (ich habe es nur in Teilen angesehen und mich gefragt, warum z.B. FHEMWEB nicht als Frontend aufgeführt wird und wie die willkürliche HW-Auswahl bei den Servern zustande kam).

Zitat von: Beta-User am 13 März 2018, 10:15:17
Zu allowed:
- Es gibt jetzt eine kurze Einleitung und eine "Einführung". Der Beitrag ist immer noch kurz und knackig, aber immerhingibt es ihn jetzt (s.u.).

Ich finde den Artikel jetzt ziemlich prima. Auf den ersten Blick wird ohne Schnörkel klar um was es geht und wie man es macht. So stelle ich mir alle Artikel für Anfänger vor.

Einen Satz würde ich anders fassen, so: "Es wird dringend empfohlen, für den Webserver FHEMWEB mithilfe des Attributes HTTPS eine HTTPS-Verbindung zu aktivieren."

Zu telnet bin ich mir nicht sicher. Also erstmal ganz unabhängig von jeder Doku: Braucht der gemeine FHEM-Admin denn telnet? Gibt es da sinnvolle Anwendungen?

Ich selbst dachte immer (immer ist gut, ich bin ein halbes Jahr dabei): Oh, telnet, das wird wohl ein Rudiment aus "es ist halt so gewachsen" sein. Und ich dachte immer: Wenn man das umschubst, fällt das niemandem auf.

Also aus meiner subjektiven Sicht braucht das der Anfänger nun überhaupt nicht. Eher ist das Problem, dass das wohl mit der Erstinstallation in der fhem.cfg ist. Wenn dem so ist, wäre es wohl klug, dem Nutzer zu erzählen, wie man telnet ausschaltet.

P.S: Quick-Start

Danke für die Rückmeldungen.

Habe das HTTPS-Thema als Empfehlung in leicht modifizierter Form (kann mehrere FHEMWEB-Instanzen geben) übernommen, und der Artikel findet sich jetzt hier (https://wiki.fhem.de/wiki/Quick-Start), nachdem die Namensgebung eine recht eindeutige Tendenz unter den Beteiligten Diskussionsteilnehmern aufweist.

Die englische Fassung ist daher auch hier (https://wiki.fhem.de/wiki/Quick-Start/en) bereits online gegangen. Da es zumindest zum Thema plotting auch bereits einen englischen Beitrag (https://wiki.fhem.de/wiki/Creating_Plots) gibt, wäre es vermutlich das einfachste, das so zu basteln, dass man nur mit ein paar erläuternden Worten dorthin verlinkt - wenn nicht jemand schneller ist, schaue ich mir das bei Gelegenheit mal an...
EDIT: kurz gesehen, und da steht daneben: Veraltet...
Der in dem Hinweis verlinkte Artikel scheint aber wieder nur auf deutsch verfügbar zu sein - vielleicht mag den ja jemand übersetzen... Und das eine oder andere (einfache) grafische Beispiel sagt an der Stelle mehr als 1000 Worte.

footer: allowed (https://wiki.fhem.de/wiki/Allowed). Für den Rest verzichte ich heute, da ist der Beitrag nicht lang genug, als das sich das lohnt 8) .

Gruß, Beta-User

Zitat von: curt am 14 März 2018, 03:51:41
Zu telnet bin ich mir nicht sicher. Also erstmal ganz unabhängig von jeder Doku: Braucht der gemeine FHEM-Admin denn telnet? Gibt es da sinnvolle Anwendungen?

Hab ich in diesem Thread auch schon mal gefragt. Weil ich's nämlich auch noch nie verwendet habe ;). Aber leider keine Antwort bekommen.

Zu telnet versuche ich als Blinder mal von Farbe zu reden:

1. Die Diskussion ist hier m.E. falsch aufgehoben: Derjenige bzw. die Leute, die entschieden haben, dass FHEM standardmäßig mit dieser Schnittstelle in der fhem.cfg ausgeliefert wird, finden diese nach wie vor erforderlich. Ergo kann es vorliegend nur darum gehen, nachvollziehbar darzustellen, dass da eine Schnittstelle ist, die man folglich sinnvollerweise absichern sollte.

Damit ist das folgende ausdrücklich [OT]:
2. Ob das anders sein sollte, ist eine zweite Frage. Für telnet würde ich sagen: tendenziell erhalten und - wie vorliegend ja auch erfolgt - lieber einfach erklären, dass man das mit absichern sollte.
- Erstens gibt es nach meiner Wahrnehmung einige angeflanschte Lösungen, die diese schnelle, texbasierte und das System vergleichsweise wenig belastende Schnittstelle nutzen, um Infos darüber auszutauschen (u.a. TabletUI _könnte_ darauf basieren). Also werden wenigstens technische Experten es schätzen, wenn sie nicht danach suchen müssen, ob sowas vorhanden ist.
- Zweitens könnte auch das FHEMWEB-Modul ja mal kaputt sein oder das System sonst langsam reagieren (letzteres hatte ich schon mal bei Hitzeproblemen). Dann hat man eben eine zweite Alternative, die deutlich weniger Prozessorleistung erfordert und zumindest Notmaßnahmen ermöglicht. Finde ich nicht verkehrt.

3. Bevor also telnet nicht mit ausgeliefert und dargestellt wird, würde ich initialUsbCheck standardmäßig deaktivieren - jedenfalls auf arm-Rechnern. Das scheint bei Pi3-Modellen nämlich zu verhindern, dass das System überhaupt hochfährt, und das fällt nicht unbedingt in die Kategorie "einsteigerfreundliche Lösung"...
Vorteile bringt es auch nur bei CUL&Co., die wiederum Techniken bedienen, die man auch nicht unbedingt in den Vordergrund stellen sollte (da wären wir indirekt wieder beim Thema "Sicherheit") - FS20 und 433MHz-"Gruscht" (ausdrücklich pers. Meinung, bitte keine Kommentare von mir bekannten InterTechno-Liebhabern ;) ). Für HM gibt's eigentlich für Anfänger besser zu handhabende Lösungen, und alles andere muß sowieso mit Bedacht konfiguriert werden.

Damit will ich's aber auch - jedenfalls von meiner Seite - sein Bewenden haben lassen ::) .

Und nochmal ausdrücklich: Das ist m.E. alles [/OT]

Gruß, Beta-User

So, und zu guter letzt noch die Info, dass auch https://wiki.fhem.de/wiki/Allowed/en online ist mdB. um kritische Durchsicht (gerne direktes editing dort).

Zitat von: Beta-User am 14 März 2018, 11:15:03
- Zweitens könnte auch das FHEMWEB-Modul ja mal kaputt sein oder das System sonst langsam reagieren (letzteres hatte ich schon mal bei Hitzeproblemen). Dann hat man eben eine zweite Alternative, die deutlich weniger Prozessorleistung erfordert und zumindest Notmaßnahmen ermöglicht. Finde ich nicht verkehrt.

Ok, das ist ein überzeugendes Argument. Denn sonst hätte ich vorgeschlagen, dass Du im Artikel lieber erklärst, wie der Anfänger telnet komplett deaktiviert. Ok, könnte man trotzdem dort erklären.

Zitat von: Beta-User am 14 März 2018, 11:15:03
Und nochmal ausdrücklich: Das ist m.E. alles [/OT]

Finde ich nicht.

footer: allowed (https://wiki.fhem.de/wiki/Allowed).

Zitat von: Beta-User am 14 März 2018, 12:19:14
So, und zu guter letzt noch die Info, dass auch https://wiki.fhem.de/wiki/Allowed/en online ist mdB. um kritische Durchsicht (gerne direktes editing dort).

Erledigt. Hast du noch weitere englische Texte zur Korrektur?

Vielleicht eine kurze Anmerkung: Entgegen der Gepflogenheiten im Deutschen benutzt man im Englischen deutlich weniger Bindestriche. Vor allem dann wenn man Zahlen zusammensetzt (fifty-one, aber nur von 21 bis 99) oder wenn die Bedeutung uneindeutig ist (re-cover vs. recover). Gerne auch wenn Wörter schwer zu lesen werden (bell-like vs. belllike). Ein allowed device würde ich nur dann mit Bindestrich schreiben, wenn allowed im Kontext so missverstanden werden könnte, dass es ein erlaubtes Device anstelle eines Devices vom Typ allowed sein könnte.

Thx für's Korrekturlesen, außer dem hier schon erwähnten Artikel zu der Struktur der Doku (https://wiki.fhem.de/wiki/Dokumentationssstruktur/en) kann ich mich an keine weiteren englischen Leichen erinnern, die im Keller liegen könnten ;D ...

@Christian und Peter:
Gäbe es denn weitere Dinge, die Ihr Euch wünschen würdet? (Es lesen hier scheinbar einige mit, die ggf. da mehr Talent haben als ich ::) . Ihr könntet die Chance nutzen...)

Auf der (allgemeinen!) todo-Liste sehe ich damit im Moment noch den Abschnitt über loggen und plotten (d+(evtl. extended) en). Das ist aber inhaltlich nicht so mein Steckenpferd...
Als Ansatz fände ich es nicht schlecht, im Quick-Start kurz das logging zu erläutern und dann mit ein, zwei optisch ansprechenden Beispielen, was man damit an grafischer Darstellung erzeugen kann auf https://wiki.fhem.de/wiki/Plots_erzeugen (bzw. dann eine Übersetzung davon) zu verweisen. Dort würden sich m.E. dann auch noch ein paar (nicht viele, aber eben) hübsche Bilder gut machen...

Danke für die ordentliche "Beerdigung" der verbliebenen "englischen Leiche" ::) .

Jetzt habe ich doch noch einen Thread zu Wiki-Themen (https://forum.fhem.de/index.php/topic,85785.0.html) eröffnet (FAQ und Tipp der Woche).

Diskussion ausdrücklich (jedenfalls von meiner Seite) erwünscht...

Gruß, Beta-User

So, nach etwas "Üben" mit dem gplot-Editor: Es gibt noch eine Neufassung des Abschnitts loggen+plotten: https://wiki.fhem.de/wiki/Quick-Start#Daten_aufzeichnen_und_darstellen

Wenn das korrigiert bzw. redigiert ist, erzeuge ich ggf. nochmal eine "Leiche" ::) .

So, ab hier https://wiki.fhem.de/wiki/Quick-Start/en#Record_and_Present_Data bis zum Ende zur kritischen Durchsicht freigegeben :) .

Von mir aus gerne mit [gelöst] zu kennzeichnen, allerdings steht das Neuverzweigen von fhem.de dann noch aus ;) .

Thx für die kritische Begleitung, bis dahin erst mal und schönen Freitag noch,

Beta-User

Vielen Dank an Beta-User, Stefan und natürlich alle anderen Beteiligten für die Erstellung und Gedanken zu den hier disktuierten Artikeln.
Habe die Links auf fhem.de angepasst.

Beim Überfliegen des Artikel ist mir aufgefallen, dass diese Infos aus dem HOWTO:

ZitatThe default configuration will install FHEM into /opt/fhem, edit the Makefile to change this. You can also start FHEM directly from where you unpacked it, installation is optional. To install & start FHEM type:

      make
      cd /opt/fhem
      perl fhem.pl fhem.cfg

jetzt nicht mehr vorhanden sind. Sie gehören eigentlich auch nicht ins Quick-Start, sind aber mMn dennoch wichtig. Habt ihr Ideen, wie man das unterbingen kann?

telnet halte ich als Zugangsweg für sehr wichtig und deshalb weiterhin erwähnt werden.

FHEM auf Windows ist sicherlich weniger getestet und erprobt als auf Linux. Jedoch tue ich mich schwer, davon abzuraten. Ich selbst betreibe -problemlos- eine produktive Windows-Installation und sämtliche FHEM-Tests zu EnOcean und ZWave mache ich unter Windows. FHEM habe ich dabei nach https://wiki.fhem.de/wiki/FHEM_Installation_Windows installiert. Die andere Anleitung im Wiki zu FHEM Windows ist mir zu kompliziert.

Eine automatische Kategorisierung im Wiki anhand von Foren halte ich nicht für hilfreich. Die Forenzuordnung ist als Kriterium mMn zu grob und auch zu zufällig.

Wenn ich offene Punkte/Fragen überlesen habe, dann bitte nachfassen.

Danke und Gruß, Christian

Hallo Christian,
hallo zusammen,

Danke für die Rückmeldung, bis auf die folgenden Anmerkungen ist mir jetzt nichts aufgefallen, was dringlich wäre.

Das "howto" war auf der Startseite des Wiki unter dem pdf verlinkt, soweit ich mich erinnere. Da könnten dann links zu den neuen Doks hin, oder?

Was den "rausgefallenen" Teil angeht, sind das m.E. zwei Infos, die ich wie folgt verteilen würde:
- Installation aus den sourcen gehört m.E. direkt auf fhem.de in den Abschnitt Unix / OSX und könnte unverändert dort wiedergegeben werden wie von dir zitiert
- Im Quick-Start selbst könnte man nochmal den Hinweis aufgreifen, dass - mit Ausnahme des Startscripts - (by default) alle Daten unter /opt/fhem zu finden sind (wg. Sicherung/Backup etc.). Steht in der d-Version jetzt  in einer Infobox bei "Installation".

Auf fhem.de hatte ich eben  noch zwei Erwähnungen bzw. links auf das "howto" (Documentation + After installation...). Ist die geänderte Fassung schon online?

Macht es noch Sinn, in den beiden Quick-Starts wechselseitig auf die andere Sprachversion hinzuweisen (für die d-Version habe ich das eben eingepflegt)?

Telnet:
Da gab es erst jüngst wieder einen weiteren Fall im Forum, in dem das als Notzugang absolut wichtig war. Ergo sehe ich das umso mehr auch so, dass da keine Empfehlung rein sollte, das auszubauen (habe es (d-Version) in eine Fußnote für Neulinge gepackt, dass man das für solche Fälle benötigen könnte)...

Windows:
Diese Installationsanleitung kannte ich (vorrangig mangels Suche danach) noch nicht - wäre es nicht auch da sinnvoll, zumindest von der bebilderten Anleitung auf die portable Variante zu verweisen?
Ansonsten bin ich persönlich da letztlich leidenschaftslos, Redmond ist zum Glück nicht meine Baustelle 8) . Letztlich scheint es auch davon abzuhängen, welche (Perl-) Module man einsetzt, oder? Mein pers. Eindruck ist halt, dass man Einsteigern eher nicht dazu raten sollte, bzw. insgesamt mehr den einen oder anderen Ratschlag für den Start zu geben. Aber ja, das ist mind. zweischneidig, und ggf. auch schnell überholt.

Bitte um Rückmeldungen zu den Änderungen, mit dem Text bin ich nicht soooo glücklich, aber ich wollte es mal wieder nach dem Motto "korrigieren ist einfacher" erst mal drin haben ;) . Wenn das dann paßt und für gut an der Stelle befunden wird, kommt dann gerne wieder ein erster engl. Vorschlag, wenn's nicht jemand vorher erledigt.

;D footer (https://wiki.fhem.de/wiki/Quick-Start)

Schönes WE!

Zitat von: Beta-User am 17 März 2018, 09:06:51
Das "howto" war auf der Startseite des Wiki unter dem pdf verlinkt, soweit ich mich erinnere. Da könnten dann links zu den neuen Doks hin, oder?

Nein, war es nicht. Im Wiki gab es afaik keine Verlinkung zum HOWTO. Wenn Du eine passende Stelle findest, bau es ruhig in die Hauptseite ein.

Zitat- Installation aus den sourcen gehört m.E. direkt auf fhem.de in den Abschnitt Unix / OSX und könnte unverändert dort wiedergegeben werden wie von dir zitiert

Kommt auf Todo. Wollte sowieso noch Kleinigkeiten anpassen; vielleicht schaffe ich das heute noch.

Zitat
Auf fhem.de hatte ich eben  noch zwei Erwähnungen bzw. links auf das "howto" (Documentation + After installation...). Ist die geänderte Fassung schon online?

War vor meinem Post online. Habe es direkt im Live-System geändert.  8) Mache einmal einen Reload.

ZitatMacht es noch Sinn, in den beiden Quick-Starts wechselseitig auf die andere Sprachversion hinzuweisen (für die d-Version habe ich das eben eingepflegt)?

Keine Meinung. Mir wäre das nicht eingefallen.

ZitatWindows:
Diese Installationsanleitung kannte ich (vorrangig mangels Suche danach) noch nicht - wäre es nicht auch da sinnvoll, zumindest von der bebilderten Anleitung auf die portable Variante zu verweisen?

Mach ruhig.

Persönlich mag ich keine Vorauswahl in der Doku zum Betriebssystem geben. FHEM läuft auch unter Windows. Unter Linux gibt es mehr Anwender und mehr Erfahrung/Developer, aber viele Probleme im Forum sind durch mangelnde Linux-Kenntnisse der Win-User (mit)verursacht.

Eigentlich müsste man betriebssystemspezifisch auf Probleme bei einzelnen Modulen aufmerksam machen. Das ist aber zu aufwendig.

Für mich ist das schlimmste Problem unter Windows, dass das serial-port Modul unter Win nicht vernünftig gepflegt ist und deshalb dessen Installation unter Umständen eine Bastelei ist.

Arghhh, FF macht mit "F5" was anderes als einen vollst. reload - wieder was gelernt...

Den link auf die D-Version habe ich jetzt in der engl. Version rein gemacht, da die fhem.de-Seite auf die engl. Fassung verlinkt. (den Rest erst mal noch nicht).

Was die Wiki-Homepage angeht: Meinungen dazu? Ich hätte an "Wie fange ich an?", dort unter pdf gedacht.

Na ja, ich bin kabel-affin, da wäre das Gefrickel mit dem perl-serial-Modul ein nogo (neben diesem OS an sich, aber das ist eine andere Diskussion ;D ). Aber lassen wir das, wir können das ja ggf. aufgreifen, wenn die Zahl derer, die wirklich Windows machen größer werden sollte und wir dann sehen, was wirklich alles nicht geht ;) . Kann ja wirklich sein, dass das weniger Aufwand ist, als allen Linux-Basics beizubringen ::) . K.A., was dann mit solchen Themen wie mosquitto etc. ist, die häufig auf derselben Maschine laufen ::) .

Den Link bzw. Hinweis bastle ich ggf. bei Gelegenheit rein, jetzt ist erst mal was anderes angesagt, habe eine Ladung Arduinos aus China erhalten, die wollen bespielt werden :) .

Zitat von: Beta-User am 17 März 2018, 09:06:51
Telnet:
Da gab es erst jüngst wieder einen weiteren Fall im Forum, in dem das als Notzugang absolut wichtig war. Ergo sehe ich das umso mehr auch so, dass da keine Empfehlung rein sollte, das auszubauen (habe es (d-Version) in eine Fußnote für Neulinge gepackt, dass man das für solche Fälle benötigen könnte)...

Und das Beste daran: Ich hab das gestern auch mal in einem Thread als Lösungsweg vorgeschlagen ;D

Zitat von: Beta-UserArghhh, FF macht mit "F5" was anderes als einen vollst. reload - wieder was gelernt...

Alle Browser, oder? F5 = Reload mit Cache, STRG+F5 = Reload ohne Cache

Zitat von: Beta-User am 16 März 2018, 15:13:02
So, ab hier https://wiki.fhem.de/wiki/Quick-Start/en#Record_and_Present_Data bis zum Ende zur kritischen Durchsicht freigegeben :)

Bin dran / fast durch.
Soweit alles gegengelesen und korrigiert wo ich es für nötig hielt.

Zitat von: Christoph Morrison am 17 März 2018, 13:54:59
Soweit alles gegengelesen und korrigiert wo ich es für nötig hielt.

Vielen Dank.
Gruß, Christian

Zitat von: Christoph Morrison am 17 März 2018, 13:54:59
Soweit alles gegengelesen und korrigiert wo ich es für nötig hielt.

Schließe mich an :) .

Da hier einige kritische Geister mitlesen:

Ich habe einige "Kleinigkeiten" bei den "Phasen des Projekts" geändert.

Vielleicht mag ja jemand querlesen, noch was ergänzen oder streichen, wenn ich irgendwo über's Ziel raus sein sollte.

M.E. sollte das weiterhin eher kurz gefasst bleiben, aber den einen oder anderen Tip/Link könnten diese Seiten alle noch vertragen ;) .

Gruß, Beta-User

Benutzer Trelle hat auf der QuickStart-Diskussionsseite eine Änderung in den Raum gestellt: https://wiki.fhem.de/wiki/Diskussion:Quick-Start
Wie seht ihr das?

Ich stimme ihm zu. at sollten wir in der Tat nicht als Eventhandler bezeichnen.

Typisches "da fehlt die Klammerung" Problem. Man kann das auch als "at, (notify und andere Eventhandler, wie z.B. DOIF...)" lesen.

Dann vielleicht versuchen den Satzbau verständlicher um zu stellen  ;D

Na ja, genau genommen behandelt ein at einen Zeit-Event, so gesehen ist es schon ein Eventhandler

gb#

Im Prinzip hat trelle Recht, auch wenn er keine Lösung anbietet.

Eigentlich müßte das ein weiterer Unterabschnitt sein mit "Kommandos" oä. als Überschrift, die Einleitung sollte dann in diese Richtung gehen: "at, weekdayTimer und andere Module zur zeitabhängigen Steuerung einerseits und notify ... andererseits für eine ereignisabhängige Steuerung ..."
Das ist in der Tat dort - je nach Lesart und eigenem Verständnis - etwas verkürzt dargestellt. Streicht man nur at an der Stelle raus, wird es auch irgendwie unvollständig, da oben bei at gar nichts zu Kommandos steht.

Zwei Anmerkungen noch zu dem Einschub mit DOIF:1. ist unschön, dass im englischen Text nur ein Unterabschnitt besteht - wer 8.1 sagt, sollte auch sagen, was 8.2 ist...2. (Achtung, persönliche Meinung): In dem Text wurde isnsgesamt bisher weitestgehend auf konkrete Beispiele verzichtet zugunsten eines: "Wenn es dich interessiert, dann schau da weiter nach...". Hier findet sich ein konkretes Beispiel, das den Eindruck vermittelt, das sei sehr einfach. Da aber DOIF aufgrund der Vielzahl der optionalen Attribute und der von den üblichen Standards abweichenden Syntax aber "anders" ist und schnell sehr komplex werden _kann_, würde ich mir wünschen, dass wir an der Stelle keine stilistische Abweichung vornehmen und es von mir aus bei dem Hinweis belassen, dass DOIF eine Kombination von zeit- und ereignis-basierter Steuerung ermöglicht...

Just my2ct.

Beta-User

Das at-Problem sehe ich nicht als kritisch an.

Mich stört bei dem DOIF-Einschub aber schon allein die Überschrift https://wiki.fhem.de/wiki/Quick-Start#Kombinierte_Zeit-_und_Ereignissteuerung mit bloßer Erwaehung von DOIF in dem Abschnitt. Das suggeriert dem Leser, dass mit notify keine kombinierte Zeit- und Ereignissteuerung möglich ist. Das stimmt aber so nicht und lenkt mMn den Einsteiger in eine komplett falsche Richtung. Eine ahnliche Diskussion hatten wir bereits bei der DOIF-Ergaenzung im "Erste Schritte in FHEM" im Wiki.

Gruß, Christian

Ich gebe Christian da Recht. Im Quickstart sollten die Basic Sachen rein. Notify, at und watchdog. DOIF kann man ja als Erweiterung sehen.

Zur Klarstellung: Ich habe grundsätzlich kein Problem damit, wenn DOIF im Quickstart erwähnt/behandelt wird.
Nur sollten dadurch beim Leser keine falschen Eindrücke entstehen. Meiner Meinung nach entsteht genau dieser falsche Eindruck nach der Änderung https://wiki.fhem.de/w/index.php?title=Quick-Start&type=revision&diff=27474&oldid=27242. Das liest sich jetzt so als wäre DOIF der modernere Nachfolger von notify, at und Co; erst durch DOIF wäre eine kombinierte Zeit- und Ereignissteuerung möglich. Das ist falsch. Deshalb hätte ich den Abschnitt gerne etwas neutraler gefasst. Auch die angefügten "Warn"hinweise zum Einsteiger-PDF durch die Änderung sind mir persönlich zu viel; wer liest das jetzt noch!?

notify "erzwingt" Perl-Nutzung bei komplexeren Problemen und lehrt deshalb ein grundlegendes Verständnis der Programmiersprache Perl in der FHEM entwickelt wird.
DOIF hat seine eigene Syntax, die man (ggfs. zusätzlich zu Perl) lernt; hat dafür diverse Funktionen integriert für die man sonst andere Module (oder Perl) benötigt.
Ob man jetzt im Einzelfall DOIF oder notify und Co. nimmt, bleibt jedem selbst überlassen.

Und damit neben Kritik zu Einzelpunkten, das eigentlich Wichtige nicht vergessen wird: Ein großes Dankeschön an trelle, der im Wiki, Forum, und beim Modul exzellente Arbeit abliefert.  :)

Zitat von: krikan am 17 Juli 2018, 14:27:46
Und damit neben Kritik zu Einzelpunkten, das eigentlich Wichtige nicht vergessen wird: Ein großes Dankeschön an trelle, der im Wiki, Forum, und beim Modul exzellente Arbeit abliefert.  :)

@trelle: Für den Fall, das ich dir mit meinen Anmerkungen versehentlich zu nahe getreten sein sollte: War nicht böse gemeint, die deutlichen Worte sind nur eine unerwünschte Nebenwirkung meiner persönlichen DOIF-Aversion (ich will das alles nicht nochmal wiederholen, also sagen wir einfach, ich bin zu doof für die vielen Argumente) ::) .

In der Sache bin ich übrigens voll bei Christian:
- Mal ab von Kleinigkeiten (wie der Einführung ins cfg-Editieren) ist das pdf nach wie vor super! Und den Transfer von FS20 zu "was-auch-immer" muß man tendenziell immer leisten, das wäre auch kaum anders, wenn dort ZWave dargestellt wäre...
- Was das Thema Kombination von Zeit- und Ereignissteuerung angeht, könnte man das in eine Art Linkliste verkürzen, die neben einem Link auf einen passenden Abschnitt der DOIF-Doku auch https://wiki.fhem.de/wiki/If-condition und https://fhem.de/commandref.html#disabledForIntervals enthält, evtl. noch https://forum.fhem.de/index.php/topic,27247.msg201711.html#msg201711 und sonst ggf. was wem auch immer noch dazu einfällt. 

Wenn das tendenziell Zustimmung findet, bau' ich's gerne (an beiden genannten Stellen) so um (wenn sonst niemand schneller ist).

Just my2ct
Beta-User

Mit Quick Start und notify wurden der Begriff Eventhandler auf Module mit bestimmten Eigenschaften gelenkt ohne ihn in Bezug auf FHEM zu definieren.

Es wurde versucht durch eine beispielhafte Aufzählung im fließenden Text den Begriff zu erklären. Aufzählungen im fließenden Text machen ihn schwerer lesbar.
Deshalb habe ich für Eventhandler einen Eintrag im Glossar angefangen. Damit könnten alle Aufzählungen im Text entfallen, da der Eintrag im Glossar diese Auflistung enthält.

In diesem Zusammenhang, stellte sich die Frage:"Ist at ein Eventhandler im eigentlichen Sinne?" Events erscheinen im Eventmonitor, ablaufende Timer nicht.

Ich würde at als Timehandler bezeichen oder nur als Timer, wie dann auch WeekdayTimer. Oder sollte das ein Eventhandler sein?


Wer unvoreingenommen zu den Eventhandlern recherchiert, dem wäre aufgefallen, das bis zu meiner Ergänzung, DOIF in übertriebener Weise unterrepräsentiert war. Ich habe bewusst auf hervorhebende Attribute verzichtet, wie sie aber zu notify im Text von Quick Start zu finden sind, z.B. "wird ein Eventhandler benötigt. Die einfachste Form eines solchen ist ein Device vom Typ notify", wo bleibt dort die Objektivität.

DOIF gehört zu den 3 am häufigsten verwendeten Eventhandlermodulen, https://fhem.de/stats/statistics.html

Ein objektiver Redakteur wird das Beispiel in der vorhandenen Form im Artikel bestehen lassen.

Wenn es nur einen Punkt 8.1 gibt, dann liegt es daran, dass die vorgergehenden Abschnitte nicht überschrieben sind, sondern nur fett markiert sind, wie mir jetzt aufgefallen ist, das lässt sich leicht ändern und war nicht Beabsichtigt.

@ Beta-User:
Du schreibst:

ZitatIn dem Text wurde isnsgesamt bisher weitestgehend auf konkrete Beispiele verzichtet ...

Da das im konkreten Abschnitt nicht der Fall war, habe ich mich zur Ergänzung ermutigt gefühlt.

Der Zugriff auf Readings mit [device:reading] ist FHEM übliche Syntax (https://fhem.de/commandref_DE.html#set).

Du schreibst selbst von Deiner " persönlichen DOIF-Aversion", daher möchte ich Dich bitten, bei der Erstellung eines Artikels davon Abstand zu nehmen, denn bei der Erstellung eines Artikels muss Sachlichkeit und Objektivität im Vordergrund stehen.

Zusammengefasst:

Der DOIF-Abschnitt muss bleiben, wie er ist.
at ist kein Eventhandler, sondern ein Timer.

Eine Ergänzung gibt es noch:

@krikan
Die ergänzenden Hinweise zum Einsteigerleitfaden sind als Erläuterung gedacht, zu dem floskelhaften Hinweis

ZitatDiese ist in den wesentlichen Teilen weiterhin aktuell

Wenn man nicht erklärt was die wesentlichen Teile sind und welche es nicht sind, dann ist dieser Hinweis sinnfrei.
Ich habe versucht es knapp zu halten, besser wäre es, das Einsteiger PDF nicht direkt zu referenzieren, sondern über eine Wiki-Seite, mit Hinweisen zu nicht enthaltenen Neuerungen und veralteten Informationen, das könnte zu einer Stichpunktsammlung für eine Neuauflage werden.

Konkret schlage ich vor in Quick Start den Satz

Zitatat, notify und andere Eventhandler, wie z.B. DOIF[11], sequence[12], watchdog[13] usw. verwenden entweder vordefinierte FHEM-Kommandos, SHELL-Scripte oder Perl-oneliners als Argumente.

zu ändern auf

ZitatTimer und [[Eventhandler]] verwenden vordefinierte FHEM-Kommandos, SHELL-Scripte oder Perlcode als Argumente.

Zitat von: Ellert am 17 Juli 2018, 19:35:30
Wenn man nicht erklärt was die wesentlichen Teile sind und welche es nicht sind, dann ist dieser Hinweis sinnfrei.

Diese Ergänzung liefert auch nur wenig mehr Infos:

Zitat
allerdings werden neue Eventhandler, wie [[DOIF]] und andere nach Anfang 2014 erschienene und grundlegende Module nicht beschrieben. Das kann zu Folge haben, dass Hardware in den Vordergrund gerückt wird, die heute eher als auslaufend anzusehen ist oder Module beschrieben werden, die nicht mehr unterstützt werden

Die einzige sinnvolle Info daraus ist der Link auf DOIF und der Rest bringt auch niemanden wirklich weiter:
Welche grundlegenden Module sind denn nach Anfang 2014 erschienen und nicht beschrieben oder welche werden nicht mehr unterstützt? (Es waren niemals alle Module beschrieben, sondern eine Auswahl.)
Welche Hardware ist als auslaufend anzusehen?
Meine persönliche Ansicht zur Ergänzung hatte ich geschrieben; zwingenden Änderungsbedarf sehe ich nicht.

Gegen die von Dir vorgeschlagene at=Timer spricht mMn nichts und stellt sicherlich klarer.

Aber ich sehe zwingenden Änderungsbedarf im von Dir selbst als "DOIF-Abschnitt" bezeichneten Punkt https://wiki.fhem.de/wiki/Quick-Start#Kombinierte_Zeit-_und_Ereignissteuerung. Nochmals: Dadurch wird dem Leser vermittelt, dass DOIF das (einzige) Mittel zur kombinierten Zeit- und Ereignissteuerung ist. Das stimmt einfach nicht; das ging schon immer ohne DOIF und warum sollte man das nicht genauso darstellen. Das gleiche Problem haben wir beide bereits bei Erste Schritte diskutiert und ich habe bisher kein Argument gelesen/verstanden, warum die kombinierte Zeit- und Ereignissteuerung DOIF vorbehalten ist. Ob man mit "DOIF=kombinierte Zeit- und Ereignissteuerung" dem Modul wirklich gerecht wird, bezweifel ich ebenfalls weiterhin. Aber das ist Deine Entscheidung.

Gruß, Christian

Zitat von: krikan am 17 Juli 2018, 20:34:55
Diese Ergänzung liefert auch nur wenig mehr Infos:Die einzige sinnvolle Info daraus ist der Link auf DOIF und der Rest bringt auch niemanden wirklich weiter:
Welche grundlegenden Module sind denn nach Anfang 2014 erschienen und nicht beschrieben oder welche werden nicht mehr unterstützt? (Es waren niemals alle Module beschrieben, sondern eine Auswahl.)
Welche Hardware ist als auslaufend anzusehen?
Meine persönliche Ansicht zur Ergänzung hatte ich geschrieben; zwingenden Änderungsbedarf sehe ich nicht.

Gegen die von Dir vorgeschlagene at=Timer spricht mMn nichts und stellt sicherlich klarer.

Aber ich sehe zwingenden Änderungsbedarf im von Dir selbst als "DOIF-Abschnitt" bezeichneten Punkt https://wiki.fhem.de/wiki/Quick-Start#Kombinierte_Zeit-_und_Ereignissteuerung. Nochmals: Dadurch wird dem Leser vermittelt, dass DOIF das (einzige) Mittel zur kombinierten Zeit- und Ereignissteuerung ist. Das stimmt einfach nicht; das ging schon immer ohne DOIF und warum sollte man das nicht genauso darstellen. Das gleiche Problem haben wir beide bereits bei Erste Schritte diskutiert und ich habe bisher kein Argument gelesen/verstanden, warum die kombinierte Zeit- und Ereignissteuerung DOIF vorbehalten ist. Ob man mit "DOIF=kombinierte Zeit- und Ereignissteuerung" dem Modul wirklich gerecht wird, bezweifel ich ebenfalls weiterhin. Aber das ist Deine Entscheidung.

Gruß, Christian

Zu:

ZitatDadurch wird dem Leser vermittelt ...

Wird durch die ausschliessliche Erwähnung von at als Timer mit den Worten

ZitatDie einfachste Methode, zeitgesteuert Befehle ausführen zu lassen, ist ein at.

nicht auch der Eindruck erweckt als gäbe es nichts anderes als at umd alles Andere ist zu kompliziert. Eswird eine Meinung geäußert, das gehört nicht in einen Wiki-Artikel.
Ich hätte nichts in dagegen in dem Abschnitt DOIF gleichberechtigt zu verlinken.

Das gleiche gilt für den Abschnitt "Reaktion auf Ereignisse" für notify, ich wiederhole mich gern,

ZitatDie einfachste Form eines solchen ist ein Device vom Typ notify

, aber wie Du selbst sagst, wird man schnell zu Perl "gezwungen" und das ist nicht "Quick Start" und dort wird auch nur eine Meinung wiedergegeben, die dazu verleitet notify sei das Mittel der Wahl.
Auch hier könnte ich DOIF gleichberechtigt einfügen zumal der Eventmonitor auch die Erstellung von DOIF unterstützt.

Und natürlich kann auch der Abschnitt "Kombinierte Zeit- und Ereignissteuerung" von einem Experten um ein alternatives Beispiel ergänzt werden. Das wollte ich nicht ausschliessen.

Den Eindruck und Deine Befürchtung kann ich verstehen, die zu wecken ist von mir nicht beabsichtigt, denn at und notify wurden bereits erwähnt, da blieb DOIF nur noch übrig um die Kombination zu beschreiben. Wenn Du meinem Vorschlag zustimmst sollte das Thema entschärft sein.

Beim Hinweis zum Einsteiger PDF könnte
Diese ist in den wesentlichen Teilen weiterhin aktuell, allerdings werden neue Eventhandler, wie DOIF und andere nach Anfang 2014 erschienene und grundlegende Module nicht beschrieben. Das kann zu Folge haben, dass Hardware in den Vordergrund gerückt wird, die heute eher als auslaufend anzusehen ist oder Module beschrieben werden, die nicht mehr unterstützt werden. vollständig gestrichen werden.

Dann kann jeder selbst entscheiden, was aktuell ist. An der Commandref kommt man sowieso nicht vorbei.

"einfachste" kann je nach Lesart/Interpretation auch bedeuten: primitivste, mit weniger eingebauten Funktionen,..
Habe bei "einfachste" kein Störgefühl; empfinde DOIF dadurch nicht abgewertet oder notify/at und Co aufgewertet.
DOIF hat nun einmal mehr Funktionen als notify und Co im Modul direkt eingebaut, da der Ansatz ein anderer ist.

DOIF kann notify, at und Co sicherlich oftmals durch ein Modul/eine Definition ersetzen. Dafür muss man eben die spezielle Syntax und Attribute von DOIF lernen. DOIF erzwingt damit ein Lernen der vielfältigen DOIF-Syntax/Attribute bzw. insbesondere auch im Perl-Modus zusätzlich Perl. notify und Co zwingen zu Perl. Lernen muss man wohl bei allen Varianten; nur was man Lernen muss ist unterschiedlich.

Zwang muss übrigens kein Nachteil sein.

Ich würde DOIF nicht überall anführen, sondern in einem Abschnitt belassen, da es sonst verwirrend wird. Der allumfassende Ansatz von DOIF passt mMn besser wie bisher zusammenhängend erwähnt nach den "Spezialisten" notify, at, ... .

Habe mir das Thema DOIF im Artikel nochmals angesehen:

Der gesonderte Absatz zu DOIF sollte entfernt werden, da mit einer einfachen Verlinkung von DOIF im Artikel genug Hinweise vorhanden sind. Derzeit wird wie bereits mehrfach angeführt Falsches suggeriert und eine Richtigstellung bläht den Artikel unnötig in falsche Richtungen auf. Über die Links zu DOIF gibt es genügend weitere Literaturhinweise und es kann nicht jedes Modul detailliert erläutert und aufgeführt werden. Das war nie die Intention des Artikels.

Entscheidend für meine Meinung ist aber, dass es -wie ich sehr überrascht festgestellt habe- keinen vollständigen englischen Commandref Eintrag zu DOIF gibt, sondern stattdessen nur eine Feature-Beschreibung (das ist keine commandref!). Die Wiki-Seite ist eine verlagerte fhem.de Seite und da ist Englisch -wie eigentlich auch in der commandref- zwingend. Ich mag insbesondere auch daher DOIF keinen separaten Absatz einräumen; wie sollen nicht deutschsprachige einen vernünftigen Einstieg in DOIF bekommen!?

Gruß, Christian

In der aktuellen deutschen Fassung findet sich der Hinweis (https://wiki.fhem.de/wiki/Quick-Start#Grundlegendes_zum_Steuern_Ihrer_Ger.C3.A4te), dass eventuell "...  oder Module beschrieben werden, die nicht mehr unterstützt werden."

Hat mir dazu jemand ein konkretes Beispiel für ein weggefallenes Modul aus dem pdf? Sonst würde ich gerne diesen Teil rausnehmen (nur was die Module angeht, bei der HW hat der Hinweis seine Berechtigung).

Finde auf die Schnelle nur eine kurze Erwähnung von GDS.

Und welche Hardware ist auslaufend? FS20? Wirklich?

Na immerhin was, aber rechtfertigt das den Warnhinweis in der jetzigen Form?

Was FS20 angeht, ist das "Hörensagen". Aktuell kann man das bei ELV noch kaufen, gerüchteweise wird aber nichts mehr produziert.

Bevor wir uns aber mit Details rumplagen, die morgen schon wieder veraltet sind, stelle ich daher mal folgenden Vorschlag in den Raum:

ZitatFür Einsteiger empfiehlt sich die Lektüre der [Einführung in die Automatisierung mit FHEM (http://fhem.de/Heimautomatisierung-mit-fhem.pdf!)]. Zwar sind dort Neuerungen wie der Wechsel des default Style zu f18, Module wie allowed oder DOIF (https://wiki.fhem.de/wiki/DOIF) nicht behandelt und die Auswahl an verfügbaren Hardwaresystemen hat sich seit dessen letzter Aktualisierung weiter erhöht. Dennoch bietet diese Einführung nach wie vor einen recht umfassenden Überblick in die allgemeinen Vorgehensweisen und Möglichkeiten mit FHEM.

ZitatFür Einsteiger empfiehlt sich die Lektüre der [Einführung in die Automatisierung mit FHEM]. Zwar sind dort Neuerungen wie der Wechsel des default Style zu f18, Module wie allowed oder DOIF nicht behandelt und die Auswahl an verfügbaren Hardwaresystemen hat sich seit dessen letzter Aktualisierung weiter erhöht. Dennoch bietet diese Einführung nach wie vor einen recht umfassenden Überblick in die allgemeinen Vorgehensweisen und Möglichkeiten mit FHEM.

Finde ich auch o.k.

Ich auch für den deutschen Teil, wenn

ZitatWechsel des default Style zu f18

das schon umgesetzt ist. (Dann habe ich das verpasst)

...da hatte ich Rudi wohl falsch verstanden...https://forum.fhem.de/index.php/topic,82351.msg818789.html#msg818789

Betrifft im Moment nur die demo-cfg.

Habe daher jetzt folgendes drin, das sollte für die nähere und fernere Zukunft passen:

ZitatFür Einsteiger empfiehlt sich die Lektüre der [Einführung in die Automatisierung mit FHEM (http://fhem.de/Heimautomatisierung-mit-fhem.pdf!)]. Zwar sind dort Neuerungen wie der Style f18 (https://wiki.fhem.de/wiki/FHEMWEB), Module wie allowed (https://wiki.fhem.de/wiki/Allowed) oder DOIF (https://wiki.fhem.de/wiki/DOIF) nicht behandelt und die Auswahl an verfügbaren Hardwaresystemen hat sich seit dessen letzter Aktualisierung weiter erhöht. Dennoch bietet diese Einführung nach wie vor einen recht umfassenden Überblick in die allgemeinen Vorgehensweisen und Möglichkeiten mit FHEM.

Zwei Anmerkungen dazu:
- Wann kommt 5.9? (Geht eigentlich an einen anderen Addressaten, aber alleine allowed und f18 als würden es m.E. rechtfertigen, mal wieder "so zu tun", als gäbe es was neues....)

- Zu f18 sollte sich irgendwann auch mal jemand erbarmen, da was im Wiki (zu FHEMWEB?) zu ergänzen. Eilt aber nicht, vielleicht mach' ich's bei Gelegenheit, wird aber dauern, bis ich dazu käme...

ZitatWann kommt 5.9?

Gute Frage, wenn ich meine, dass f18 rund genug ist fuer die Allgemeinheit, oder irgendwer eine bessere Begruendung leifert.
Das allowed Modul gibt es mAn aber auch in schon in 5.8, d.h. fuer all die, die von update nichts mitbekommen haben.

Erster Schnellentwurf der neutralen Fassung: https://wiki.fhem.de/wiki/Quick-Start#Kombinierte_Zeit-_und_Ereignissteuerung
Das DOIF-Beispiel könnte man auch noch als notify-Beispiel angeben. Bin aber unsicher, ob wir nicht ohne Beispiele auskommen (und ohne vernünftigen PC tippt es sich schwer). Das DOIF-Beispiel ist in dem Absatz auch im direkt verlinkten Wiki-Artikel genauso enthalten.

Zitat von: krikan am 03 August 2018, 19:35:39
Erster Schnellentwurf der neutralen Fassung: https://wiki.fhem.de/wiki/Quick-Start#Kombinierte_Zeit-_und_Ereignissteuerung
Das DOIF-Beispiel könnte man auch noch als notify-Beispiel angeben. Bin aber unsicher, ob wir nicht ohne Beispiele auskommen (und ohne vernünftigen PC tippt es sich schwer). Das DOIF-Beispiel ist in dem Absatz auch im direkt verlinkten Wiki-Artikel genauso enthalten.

Das wäre ein Ansatz, wobei das etwas überladen ist und etwas präziser sein könnte.

ZitatDOIF verwendet dazu eine vom Modulmaintainer entwickelte eigene Syntax während notify wie andere Module auf die Programmiersprache Perl, in der FHEM entwickelt wird, zurückgreift.

"vom Modulmaintainer entwickelte" halte ich für überflüssig, trägt nicht zur Sache bei.

"eigene Syntax" korrekt wäre "erweiterte Perl-Syntax" alles in der Bedingung ist Perl, erweitert um die Syntax in eckigen Klammern.

Und auch notify verwendet nicht die originale Perlsyntax, sondern ergänzt das Suchmuster um ^$. "während notify wie andere Module auf die Programmiersprache Perl... zurükgreift" ist unpräzise, trägt nicht zum Thema bei und macht den Satz kompliziert.

Das gilt auch für den Einschub "in der FHEM entwickelt wird" das kann man schon auf der Wiki Startseite lesen und muss hier nicht erwähnt werden.

Die Reihenfolge der Erwähnung der Module sollte in der üblichen alphabetischen Reihenfolge geschehen, um dem Vorwurf der Subjektivität entgegenzuwirken.

Darauf basierend ein modifizierter Vorschlag https://wiki.fhem.de/w/index.php?title=Quick-Start&action=edit&section=18

Das ist knapp und dann passt auch noch ein notify Beispiel rein.

Zitat von: Ellert am 03 August 2018, 21:39:03
Das wäre ein Ansatz, wobei das etwas überladen ist und etwas präziser sein könnte.
"vom Modulmaintainer entwickelte" halte ich für überflüssig, trägt nicht zur Sache bei.

"eigene Syntax" korrekt wäre "erweiterte Perl-Syntax" alles in der Bedingung ist Perl, erweitert um die Syntax in eckigen Klammern.

Dass DOIF (im DOIF-Modus) eine selbstentwickelte erweiterte Perl-Syntax mit intensiver Steuerung durch Attribute verwendet, ist eine wichtige Info. Quelle mit Verwendungsinfos für den Anwender sind
somit die deutsche DOIF-commandref und spezielle DOIF-Erläuterungen im Wiki, Forum usw.
notify baut im Wesentlichen bei erweiterten Funktionswünschen auf Perl auf. Quelle für Infos ist jede Perl-Quelle im Internet, Buch usw.
Diese Info halte ich für grundlegend, egal wie man es formuliert und unterbringt.

ZitatUnd auch notify verwendet nicht die originale Perlsyntax, sondern ergänzt das Suchmuster um ^$.

Ja, im Suchmuster findet eine (einfache) Ergänzung statt. Im hier eigentlich wichtigen Bereich (command) ist es aber iW Perl (neben FHEM-command und shell-command).
Die Ergänzung "mit erweitertem Suchmuster" verbindet Auslöser mit command-Bereich des Devices in mich verwirrender Weise. Eigentlich müsste man bei DOIF dann u.a. noch das Thema "Ereignissteuerung" versus "Ereignissteuerung durch Event" auseinanderpflücken, aber das geht zu weit.
Im Fazit halte ich die Ergänzung "mit modifiziertem Suchmuster" für nicht optimal, aber letztlich bei allen notwendigen Verkürzungen für ok.

Die anderen Änderungen finde ich in Ordnung.

Bitte passe die englische Fassung doch auch entsprechend an. Danke.

Ich habe den Vorschlag angeschaut, und mein erster Gedanke war, dass niemand die eigene und die "gegnerische" Philosophie neutral darstellen kann, ich vermutlich auch nicht :)

DOIF ist fuer mich "ein Tool fuer alle Probleme", wo man sich darauf verlassen muss, dass fuer das eigene Problem ein "Rezept" gibt, sonst wird es komplizierter als mit notify/at. Es gibt aber viele Rezepte, und fuer viele Benutzer mag das einfacher sein, als mit perl anzufangen. Der Ausdruck "erweiterte Perl Syntax" ist euphemistisch: ich kann an dem gezeigten Beispiel kein perl erkennen. Der Seitenhieb auf notify mit "modifizierter Suchmuster" ist ein Randnotiz, und bei der Vorstellung fuer Anfaenger irrelevant.

Uebrigens: notify ist keineswegs nur fuer perl da, wenn jemand shell/python/C/etc verwenden will, kann das gerne mit"" machen.

Zitat von: rudolfkoenig am 04 August 2018, 08:48:48
Ich habe den Vorschlag angeschaut, und mein erster Gedanke war, dass niemand die eigene und die "gegnerische" Philosophie neutral darstellen kann, ich vermutlich auch nicht :)

DOIF ist fuer mich "ein Tool fuer alle Probleme", wo man sich darauf verlassen muss, dass fuer das eigene Problem ein "Rezept" gibt, sonst wird es komplizierter als mit notify/at. Es gibt aber viele Rezepte, und fuer viele Benutzer mag das einfacher sein, als mit perl anzufangen. Der Ausdruck "erweiterte Perl Syntax" ist euphemistisch: ich kann an dem gezeigten Beispiel kein perl erkennen. Der Seitenhieb auf notify mit "modifizierter Suchmuster" ist ein Randnotiz, und bei der Vorstellung fuer Anfaenger irrelevant.

Uebrigens: notify ist keineswegs nur fuer perl da, wenn jemand shell/python/C/etc verwenden will, kann das gerne mit"" machen.

Es ist nicht als Seitenhieb gedacht, zu Anfang hat mich die Modifikation irritiert, deshalb habe ich es erwähnt.

Der Perlanteil ist in dem Beispiel nur das " and ", also alles ausserhalb der eckigen Klammern ist Perl, so der Modulautor https://forum.fhem.de/index.php/topic,89871.msg823512.html#msg823512

Ich würde den Satz

ZitatDOIF verwendet eine erweiterte Perl-Syntax. Notify und andere Module verwenden Perl mit modifiziertem Suchmuster.

streichen, denn welche Syntax verwendet wird, geht aus den verlinkten Beiträgen hervor.

Nichts zu Unterschieden zu schreiben, verhindert Diskussionen und Auseinandersetzungen; hilft aus meiner Sicht aber niemanden und ist Notlösung. Ob es uns gelingt ist eine andere Frage.

Anderer (vereinfachender) Ansatz zum Unterschied:
at wird ausschließlich zu bestimmten Zeitpunkten ausgeführt/getriggert (und die komplette Logik ist in Perl usw. abzubilden).
notify wird ausschließlich bei zutreffendem Suchmuster ausgeführt/getriggert (und die komplette Logik ist in Perl usw. abzubilden.)
DOIF wird zu Zeitpunkten und bei Ereignissen iS von DOIF ausgeführt, die durch eine selbstentwickelte (Bedingungs?)-Syntax im define in Verbindung mit verschiedenen gesetzten Attributen festgelegt wird und beeinflußt damit auch die Logik. -> es gibt mehr Ausführungsvarianten als bei notify, at.

Verständnisschwierigkeiten habe ich bei der Verwendung des Wortes "Ereignissteuerung" in DOIF (http://fhem.de/commandref_DE.html#DOIF_Ereignissteuerung). Ereignissteuerung iS von DOIF bezieht sich auf alle Ereignisse eines Devices, wobei Ereignis hier wohl nicht der englischen Übersetzung von Ereignis (=Event) entspricht, sondern nur die Readings und Status umfasst. Was ist mit den Events(=Ereignis) ohne Setzen eines Readings? Dann gibt es die http://fhem.de/commandref_DE.html#DOIF_Ereignissteuerung_ueber_Auswertung_von_Events, diese Art der "Ereignissteuerung" wertet alle Events (=Ereignisse) aus. Wenn ich es falsch verstanden habe, dann bitte korrigieren. Eine Definition dazu habe ich im Wiki nicht gefunden. Wenn ich nicht falsch liege, finde ich die Verwendung von Ereignis und Ereignissteuerung ohne genaue Hinweise im Quickstart verwirrend.

Gruß, Christian

Ich verstehe die Begriffe Event Ereignis folgendermaßen, wenn es um die Bezeichnung der Auslöserangabe des DOIF-Präprozessors geht

Ereignis, Ereignissteuerung, bezeichnet Auslöser, die dem Präprozessor über [<device>:<reading>] und Varianten davon bekannt gemacht werden. Hier steht das Ereignis o. Event im Hintergrund und die Bezeichnung und Wert der sichtbaren Gerätevariablen im Vordergrund.

Event, Eventsteuerung bezeichnet Auslöser, die dem Präprozessor über ["<device regex>:<reading regex>"] und Varianten davon bekannt gemacht werden. Hier steht das Ereignis oder Event im Vordergrund, vergleichbar mit Notify.

Diese Unterscheidung ist gewachsen zur Unterscheidung der als erstes eingeführten Ereignissteuerung von der später entwickelten Eventsteuerung.

Wenn es nicht um die Unterscheidung der Angaben für den Präprozessor geht, dann werden die Begriffe auch gleichbedeutend verwendet. Daher ist ist die Verwendung von "Zeit- und Ereignissteuerung" zutreffend, denn hier geht es nicht um die Auslöserangabe für den Präprozessor

Wenn zu der Erwähnung eines Moduls Erläuterungen angegeben werden, dann sollten wir die Angaben verwenden, die der Modulautor in der Kurzbeschreibung verwendet.
Er wird wissen, wie er sein Modul am besten beschreibt. Diese Angabe ist neutral, hinsichtlich der Vorlieben des Artikelschreibers.

Ich halte es nicht für notwendig weitere Angaben zu machen, Du bist ja auch gegen das Aufblähen. Der interessierte Leser wird den Verweisen folgen und sich dann unbeeinflusst Module wählen, dafür sind die Artikel Timehandler und Ereignishandler gedacht.

ZitatDOIF wird zu Zeitpunkten und bei Ereignissen iS von DOIF ausgeführt, die durch eine selbstentwickelte (Bedingungs?)-Syntax im define in Verbindung mit verschiedenen gesetzten Attributen festgelegt wird und beeinflußt damit auch die Logik. -> es gibt mehr Ausführungsvarianten als bei notify, at.

Der Zusatz sieht für mich kompliziert zu lesen und nicht Anfänger tauglich aus. Ich verstehe auch nicht, was das Ziel dieser Erläuterung sein soll.

Damit ist -anders formuliert- im Bereich des DOIF-Moduls die Bedeutung von Event(-steuerung), Ereignis(-steuerung) kontextbezogen.

Je nach Kontext gilt:
"Ereignis = Event" oder "Ereignis ungleich Event"
Ereignissteuerung im engeren Sinne, Ereignissteuerung im weiteren Sinne als Oberbegriff usw.
Das ist im Bereich von DOIF erklärbar.

Wenn ich mir jetzt das modul-übergreifende Quickstart und FHEMWiki anschaue:

In https://wiki.fhem.de/wiki/Quick-Start#Reaktion_auf_Ereignisse wird zunächst Ereignis und Event implizit und durch Verlinkung auf https://wiki.fhem.de/wiki/Event gleichgesetzt. So wie ich es außerhalb von DOIF auch verstehe.
Im folgenden Abschnitt https://wiki.fhem.de/wiki/Quick-Start#Kombinierte_Zeit-_und_Ereignissteuerung vermittelt die Überschrift noch Ereignissteuerung im weiteren Sinne; also" Ereignis = Event".
Das gewählte DOIF-Beispiel verwendet nun aber mit [sensor:brightness] die DOIF-Variante "Ereignis ungleich Event" und verändert damit ohne Erläuterung in einem Startartikel die Bedeutung der Begriffe Event/Ereignis.

Irritierend wird es, wenn jemand versucht das Gelernte aus dem Abschnitt "Reaktion auf Ereignisse" auf den DOIF-Abschnitt zu übertragen. Der Befehl "trigger" der bei "Event=Ereignis" zum Simulieren  vorgeschlagen wird, funktioniert im DOIF-Abschnitt mit dem DOIF-Beispiel nicht. Dort muss man bspw. "setreading" zum Simulieren nehmen, da nun "Event ungleich Ereignis".

Änderungsvorschlag für das DOIF-Beispiel im Quickstart, wenn meine Gedankengänge stimmen:
[sensor:brightness] durch  [sensor:"brightness"] ersetzen, da wir dann nach meinem Verständnis auch im DOIF-Abschnitt wieder "Event=Ereignis" im Beispiel haben und die Begriffe im gesamten Artikel gleiche Bedeutung besitzen.

Mein "Zusatz" ist keinesfalls wiki-reif und Notwendigkeit zur Erläuterung von Unterschieden schwindet bei gleicher Bedeutung der Begriffe.

Nach ein wenig Schlaf:
Mein Änderungsvorschlag führt zu einem anderen Ergebnis beim DOIF und das ist auch nicht ideal.
Mir fehlt gerade eine andere Idee, dies zu lösen. Vielleicht bin aber auch nur ich von der Verwendung der Begrifflichkeiten irritiert.

Technisch reagiert DOIF auf die Events in FHEM, die Auslöserangabe ist aber nicht immer so nahe am Event wie das Suchmuster im Notify.
Und die Auslöserangabe veranlasst eine Weiterverarbeitung des Events. Im Fall von [sensor:brightness] wird auf den Eventteil sensor brightness reagiert  und ReadingsVal($NAME,$EVTPART0,"") zurückgegeben, statt $EVTPART1.
Insofern kann DOIF mit trigger getestet werden, aber die Vorverarbeitung muss bei der Interpretation des Ergebnisses berücksichtigt werden.

Zitatsensor:brightness.* { Log 1, (ReadingsVal($NAME,$EVTPART0,"") < 40 ? "True" : "False")}

würde auch in einem Notify zu einem unerwarteten Ergebnis führen und nur mit setreading das richtige Ergebnis liefern.

Wenn es um die Beschreibung der Art und Weise geht wie man in DOIF einen Auslöser formulieren kann, dann könnte es mit einigen Worten im DOIF Beispiel gemacht und auch das Ereignis angeführt werden. Mein Vorschlag https://wiki.fhem.de/wiki/Quick-Start#Kombinierte_Zeit-_und_Ereignissteuerung Das ist dann aber nicht mehr schlank.

Danke für Deine Ausdauer bei den Erklärungen und Änderungen.  :)
Da die Beteiligung am Thema "relativ gering" ist, denke ich mittlerweile, dass nur ich diese Verständnisprobleme habe/sehe (und keiner traut sich das zu schreiben).

Aus meiner (eingefahrenen?) untechnischen Anwendersicht ist das Ergebnis des gezeigten notifys zwangsläufig so und "korrekt":

Würde ReadingsVal bei einem Event, der nicht als Reading gesetzt wird, einen "alten" evtl. vom Eventwert abweichenden Readingwert liefern, wäre ich irritiert.

Zitat von: krikan am 09 August 2018, 19:46:32
(und keiner traut sich das zu schreiben).

Ich oute mich  ::)
Ich lese fleißig mit, finde das Zwiegespräch manchmal etwas akademisch - und traue mich nicht mitzumachen  ;D

Gruß Otto

Mir hat die Diskussion geholfen das DOIF-Beispiel genauer zu beschreiben. Sachverhalte werden einem oft klarer, wenn man sie formulieren muss. Auch den Hinweis DOIF mit setreading zu testen, werde ich noch aufgreifen.

Ich möchte einen anderen Aspekt aufgreifen, die Frage: "Sollte Telnet unter 'Quick-Start#Reaktion auf Ereignisse' als Beispiel für die Anzeige von Events verwendet werden?

Ich denke das Beispiel sollte entfernt werden, aus folgenden Gründen:

Wie Telnet aufgerufen wird, ist bereits unter "Quick-Start#Erster_Aufruf_von_FHEM" erwähnt und zu einer Seite "Telnet" verlinkt, die das Beispiel enthält.

Unter Mac-OS und Windows muss der Telnet-Client erst installiert werden, bevor das Beispiel funktioniert.

Die Bedienung von FHEM über FHEMWEB ist komfortabler.

Die Nutzung eines Web-Frontends ist übliche Praxis, bei Routern, ESPs, Servern, usw.

Telnet wird für Anfänger zu sehr in den Fordergrund gerückt und der mangelnde Komfort könnte abschreckend wirken.

Siehe auch
https://forum.fhem.de/index.php/topic,72860.msg777763.html#msg777763
https://forum.fhem.de/index.php/topic,72860.msg778249.html#msg778249
https://forum.fhem.de/index.php/topic,72860.msg780999.html#msg780999
https://forum.fhem.de/index.php/topic,72860.msg781036.html#msg781036

Ich habe nichts gegen die Entfernung von telnet-Details aus der HOWTO einzuwenden, es reicht mir zu erwaehnen, dass es auch gibt.

Ob FHEMWEB oder telnet komfortabler ist, haengt vom Bediener und Aufgabe ab, aber es ist sicher abschreckend fuer den durchschnittlichen FHEM Benutzer, der Kommandozeile mit DOS gleichsetzt. Leider ist die Beschreibung der Bedienung ueber FHEMWEB komplizierter, bzw. erfordert vermutlich Screenshots, die nach eine Weile veraltet sind.

Zitat von: rudolfkoenig am 10 August 2018, 14:16:57
Ich habe nichts gegen die Entfernung von telnet-Details aus der HOWTO einzuwenden, es reicht mir zu erwaehnen, dass es auch gibt.

Ob FHEMWEB oder telnet komfortabler ist, haengt vom Bediener und Aufgabe ab, aber es ist sicher abschreckend fuer den durchschnittlichen FHEM Benutzer, der Kommandozeile mit DOS gleichsetzt. Leider ist die Beschreibung der Bedienung ueber FHEMWEB komplizierter, bzw. erfordert vermutlich Screenshots, die nach eine Weile veraltet sind.

Mir geht es nicht darum Telnet aus dem HOWTO zu entfernen, es sollte nur nicht unter diesem Punkt stehen https://wiki.fhem.de/wiki/Quick-Start#Reaktion_auf_Ereignisse

Ich habe einen Vorschlag eingearbeitet in dem steht Telnet nicht mehr so sehr im Vordergrund.

Gleichzeitig habe ich die Wirkungkette Gerät->Event->Eventhandler->Verarbeitung->Befehl deutlicher gemacht.

https://wiki.fhem.de/wiki/Quick-Start#Reaktion_auf_Ereignisse