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

Begonnen von krikan, 06 Juni 2017, 12:05:45

Vorheriges Thema - Nächstes Thema

Beta-User

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
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

drhirn

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?

CoolTux

Ich stimme ihm zu. at sollten wir in der Tat nicht als Eventhandler bezeichnen.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

rudolfkoenig

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


CoolTux

Dann vielleicht versuchen den Satzbau verständlicher um zu stellen  ;D
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Benni

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

gb#

Beta-User

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
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

krikan

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

CoolTux

Ich gebe Christian da Recht. Im Quickstart sollten die Basic Sachen rein. Notify, at und watchdog. DOIF kann man ja als Erweiterung sehen.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

krikan

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

Beta-User

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
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Ellert

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.

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.




Ellert

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.

Ellert

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.

krikan

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