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

Ellert · 17 Juli 2018, 21:55:39

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

Code Auswählen

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.

krikan · 19 Juli 2018, 09:53:53

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

krikan · 24 Juli 2018, 21:26:06

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

Beta-User · 03 August 2018, 12:44:03

In der aktuellen deutschen Fassung findet sich der Hinweis, 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).

krikan · 03 August 2018, 13:03:47

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

Und welche Hardware ist auslaufend? FS20? Wirklich?

Beta-User · 03 August 2018, 13:59:44

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

Ellert · 03 August 2018, 14:05:28

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.

krikan · 03 August 2018, 14:10:48

Ich auch für den deutschen Teil, wenn

ZitatWechsel des default Style zu f18

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

Beta-User · 03 August 2018, 14:26:43

...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]. Zwar sind dort Neuerungen wie der Style 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.

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

rudolfkoenig · 03 August 2018, 17:05:56

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.

krikan · 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.

Ellert · 03 August 2018, 21:39:03

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.

krikan · 04 August 2018, 08:26:10

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.

rudolfkoenig · 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.

Ellert · 04 August 2018, 09:18:18

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.