[geklärt] Eventhandler und Timehandler - "allgemein", "speziell" u.a.

Begonnen von Beta-User, 30 Juli 2018, 12:45:28

Vorheriges Thema - Nächstes Thema

Beta-User

Hallo zusammen,

die neuen Artikel Eventhandler und Timehandler sind m.E. sehr gelungen. Allerdings leuchtet mir die Unterscheidung in "Allgemein" und "Speziell" nicht in allen Fällen wirklich ein.


Im Artikel zu Timehandler heißt es z.B.:
ZitatSpezielle Timehandler dienen der Lösung besonderer wiederkehrender Aufgaben, der Benutzer hat nur eingeschränkte Möglichkeiten die Verarbeitung, das Ergebnis oder Teile davon selbst zu bestimmen.

Jedenfalls im Fall des WeekdayTimer paßt diese Unterscheidung nicht:

Man kann mit einem "at" wiederkehrend einfachste Dinge tun (wie "set xy on") oder beliebigen Perl-Code aufrufen, z.B. in einer myUtils-Routine. Dasselbe geht auch mit einem WeekdayTimer, wobei da zusätzlich deutlich mehr  Optionen bestehen, von der Weitergabe von "on" und "off" als einfache Events bis hin zum Aufruf von beliebigem Perl-Code. Das mag beim wdt nicht so deutlich aus der Doku abzulesen sein, ist aber kein wirkliches Problem.

Konkreter Vorschlag wäre,
- den wdt bei den allg. Timehandlern anzusiedeln.
- die Einleitung für die "speziellen" zu ändern, etwa in diese Richtung: "Zur Lösung einiger häufig vorkommenden zeitgesteuerter Aufgaben stehen weitere Timehandler zur Verfügung, die in der Regel dazu dienen, die für den jeweiligen Anwendungsfall typischen Rahmenbedingungen mit zu berücksichtigen. Dies kann allerdings Einschränkungen der Funktionalität auf den jeweiligen Anwendungsbereich mit sich bringen."
- RandomTimer mit aufzunehmen (m.E. als "speziell")

Insgesamt stellt sich hier die Frage, ob es an der Stelle auch die sehr technisch geprägten Begrifflichkeiten braucht.


Eventhandler
Was die Unterscheidungsformulierung angeht, gilt dies ähnlich für Eventhandler, wobei hier die Begriffsdefinitionen gut hinpassen.
Vorschlag:
"Spezielle Eventhandler lösen typische Aufgaben. Dies kann - abhängig vom konkreten Modul - mit Eingeschränkungen für den Anwender bei möglichen Eingriffen in die Verarbeitung und/oder erzeugten Ergebnisse verbunden sein."

Hier wäre m.E. noch der Zweipunktregler THRESHOLD gut aufgehoben.

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

Ellert

#1
Danke für die Anregungen.

zu Timehandler: Ich bin für knappe Formulierungen, ich würde den von Dir zitierten Satz ersetzen durch
ZitatSpezielle Timehandler bieten Lösungen für typische Anwendungsfälle.
das trifft die den Unterschied besser, als die alte Formulierung. Dann wäre es kein Problem wdt als speziellen Timehandler zu lassen.
RandomTimer kommt dazu, den habe ich vergessen.

zu Eventhandler: Die speziellen Eventhandler beschreibe ich dann so
ZitatSpezielle Eventhandler bieten Lösungen für typische Anwendungsfälle.
THRESHOLD und PID20 könnten mit dazu gezählt werden.

Edit:
Was meinst Du mit "technisch geprägten Begrifflichkeiten"?

Beta-User

Das mit den kurzen Formulierungen gefällt mir gut.

Was den wdt angeht, sehe ich das nach wie vor nicht ganz so. Im einfachsten Fall sendet man ein "on" oder "on-for-timer" zu wiederkehrenden Zeiten an ein Device, da gibt es keinen Unterschied zu at oder DOIF, nur dass man - im Unterschied zu at - in der Wahl der Zeiten über die Woche sehr viel freier ist. Das ist imo immer noch "general puprose", und auch die Option, z.B. Ein- und Ausschaltbefehl in einem Device direkt festzulegen macht die Aufgabe nicht "speziell".

Zitat von: Ellert am 01 August 2018, 13:20:35
Was meinst Du mit "technisch geprägten Begrifflichkeiten"?
Genau das, was Du jetzt in der Einleitung weglassen würdest,  "Verarbeitung", "Ergebnis" usw.. Das weiter unten darzustellen, ist m.E. ok, mir ging es um den Einleitungssatz, sorry, wenn das mit "an der Stelle" nicht hinreichend deutlich zum Ausdruck kam.

PID20 hatte ich gar nicht auf dem Schirm, aber wahrscheinlich gibt es da noch mehr, was in der Liste fehlt. THRESHOLD und RandomTimer waren auch nur die Module, die mir spontan eingefallen sind.

Was die neuen kurzen Erläuterungen der Module angeht, habe ich gemischte Gefühle:
Es ist häufig sehr schwierig, in wenigen Worten einen Eindruck von den Möglichkeiten zu vermitteln. Zu knapp ist da m.E. kontraproduktiv, zu viel ist andererseits "schwer zu verdauen". Meine _Meinung_ dazu: Wenn es eine Kurzbeschreibung gibt, sollte diese einen Eindruck typischen Verhaltens vermitteln (daher z.B. meine Erweiterung zu at - das geht auch wiederholend... Und nur am Rande: wie ich neulich gelernt habe, kann man dort und anderswo dazu noch disabledForIntervals verwenden, um beliebigen Perl-Code auszuführen, so lange er am Ende einen Wahrheitswert liefert (so hatte ich jedenfalls diesen Beitrag von Rudi neulich verstanden), um eine "disable-Condition" abzubilden. Von daher enthält also auch at direkt bereits Möglichkeiten, die über eine reine Zeitsteuerung rausgehen.)

Wenn das mit den Kurzbeschreibungen keinen Sinn macht, sollte man _insgesamt_ den Leser auf die entsprechenden Beiträge verlinken; der soll sich dann selber ein Bild machen.
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

#3
Ich hänge nicht daran wdt als speziell einzuordnen, jedoch nennt der Modulautor in seinem Kurztext einen speziellen Zweck "sendet Parameter an devices zu einer Liste mit festen Zeiten"
Damit erklären sich auch die Kurzbeschreibungen, sie stammen aus den Modulen und der Modulautor hat sie zu verantworten. Das ist dann konsistent zu dem lokalen Inhaltsverzeichnis der Commandref.
Die Aufzählungen sind verlinkt, im Wiki, wie üblich über den Namen und über die Referenz auf den externen Link zur Commandref. Die Kurzbeschreibung soll nur eine kurze Info sein und darstellen, wo der Modulautor den Schwerpunkt seines Moduls sieht. Es sollte halt nur eine übersichtliche Aufzählung bleiben.

Edit
disabledForIntervals, den Beitrag hatte ich auch gesehen, letztlich wird ein Zeitintervall dynamisch erzeugt.

Beta-User

Ah, ok, Danke für die Erläuterung, wo das herkommt.
Werde mal bei Gelegenheit den Maintainer vom wdt kontaktieren. Da der Wechsel aus wenig erfreulichem Anlaß war und evtl. andere Dinge wichtiger waren, nehme ich mal an, der "neue" hat diesem Detail bisher keine so große Beachtung geschenkt, zumal man an diese Stelle nur kommt, wenn man "modular" wählt.

Auch Rudi könnte da nachbessern ;D .
Die Kurzbeschreibungen geben die tatsächlichen Optionen jedenfalls nicht mal ansatzweise wieder ;D ;D ;D .
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

Übrigens: wdt bindet ein Wochenprofil an nur ein device, das ist auch eher speziell als allgemein.

Beta-User

...so scheinbar die Definition.

Sorry, wenn ich eher aus der praktischen Ecke komme und - ohne vorher nochmal die commandref gegengeprüft zu haben schlicht angemerkt habe, was Fakt ist. Tatsächlich ist es nämlich so, dass der Ausführungsteil eigentlich gar kein spezielles Device usw. benötigt, sondern auch ganz normalen FHEM-Befehle ohne Parametrierung mit $NAME und $EVENT schlucken würde, und auch beliebiger Perl-Code kann ausgeführt werden.

Devspec geht ebenfalls, wie meistens, wenn irgendwo in der commandref von <device> die Rede ist :) .

Funktionierendes Beispiel für devspec und Perl-Code (allerdings mit Parametrierung):
defmod Timer_Rolladen_Automode_1 WeekdayTimer TYPE=CUL_HM:FILTER=model=HM-LC-Bl1PBU-FM:FILTER=automode=1 !$we|{sunrise("CIVIL",0,"06:45","08:00")}|on $we|{sunrise("CIVIL",0,"08:40","09:00")}|on {sunset("CIVIL",0,"20:45","22:20")}|off {fhem ("set $NAME:FILTER=STATE!=$EVENT $EVENT")}
attr Timer_Rolladen_Automode_1 commandTemplate set $NAME  $EVENT


Das eröffnet ungeahnte Möglichkeiten, die eigentlich weit entfernt sind von einer simplen Zeitschaltuhr für ein einzelnes Device (was z.B. auch eine structure sein könnte ;) ). Understatement ist also an der Stelle noch freundlich ausgedrückt.
Jedenfalls ist der praktische Unterschied zu at neben der "sturen" Wiederholungsoption, die at ermöglicht, eine Definition, die eben funktionsbedingt mehr Angaben braucht.

Btw.: wir können uns gerne mal bei einem Bier intensiver darüber unterhalten, warum ich es als unlauter empfinde, wenn interessierten Menschen dein Lieblingsmodul als "einfach" "verkauft" wird. M.E. wäre es ehrlicher, wenn von Anfang an klargestellt würde, dass die Verwendung für komplexere Szenarien die Einarbeitung in eine sehr spezielle Syntax erfordert. Dann hat jeder von Anfang an die Wahl, in was er sich einarbeiten will.
Aber die Behauptung, das sei einfach, ist und bleibt unlauter (genauso, wenn jemand behauptet, FHEM einzusetzen sei einfach. Das stimmt auch nur bis zu einem bestimmten Punkt).

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

#7
Ja, wenn das so ist und die commandref derart ungenau, dann häng wdt im Wiki um.

Einfach, unlauter - Das sind Meinungen, die nicht ins Wiki gehören.
M.E. wäre es ehrlicher, wenn von Anfang an klargestellt würde, dass die Verwendung für komplexere Szenarien die Einarbeitung in eine sehr spezielle Syntax erfordert.
Machen wir einen Anfang und reduzieren diesen Abschnitt https://wiki.fhem.de/wiki/Quick-Start#Zeitabh.C3.A4ngige_Kommandos auf
ZitatZur Zeitsteuerung benötigt man einen Timehandler.
Der interessierte Leser wird dann dem Link zum Timehandler folgen und hat dann beim Weiterlesen die Auswahl inkl. weiterführender Verknüpfung zu vollständigen Informationen als Grundlage seiner freien Wahl.

Damit wird der Quickstart schlanker, für den eiligen Leser.

Beta-User

Zitat von: Ellert am 02 August 2018, 19:20:21
Einfach, unlauter - Das sind Meinungen, die nicht ins Wiki gehören.
Fully agreed.
Es ist auch ok, wenn man versucht, Wertungen weitestgehend zu vermeiden, auch wenn das vermutlich niemals vollständig gelingen wird. Ob etwas "einfach" ist oder eher "komplex", ist eine Bewertung. Man kann versuchen, das zu verobjektivieren, indem man eine Mehrheitsmeinung zum Maßsstab macht, aber bereits daran sieht man, wie relativ das alles ist.

Das wird sich immer mit dem (m.E. _auch_ vorhandenen) Anspruch eines Wiki beißen, auch einem Einsteiger eine gewisse Grund-Orientierung zu ermöglichen.

Und (auch) zum Austausch von Meinungen, die man zum Treffen mancher Entscheidungen halt vornehmen muss, muss man sich halt entweder zusammensetzen oder irgendwo diskutieren. Bin dabei bestrebt, Objektives und Meinung einigermaßen klar kenntlich zu machen, und finde das hier unkomplizierter als anderswo (wiki-Seite, z.B.).

ZitatMachen wir einen Anfang und reduzieren diesen Absatz https://wiki.fhem.de/wiki/Quick-Start#Zeitabh.C3.A4ngige_Kommandos auf [...]
Damit wird der Quickstart schlanker, für den eiligen Leser.
Finde ich gut. Mag sich jeder selber eine Meinung bilden :) .

Den wdt hänge ich bei Gelegenheit um.

[OT]Vielleicht an der Stelle nochmal eine kurze Erklärung, warum ich so empfindlich bin: Ich bin auch mal auf ein paar Werbeversprechen im Zusammenhang mit FHEM und deinem Lieblingsmodul angesprungen, die vermittelt haben, alles sei "ganz einfach" (Fritzbox, CUL und ab die Post). War es.

Dann ging ohne Verbiegen der FritzBox-FW nix mehr, und die Syntax eines Moduls wurde so verfeinert, dass ich am Ende dachte: Hätte mir mal besser gleich die Grundlagen angeschaut, damit wäre ich jetzt besser dran...

Hätte man mir gleich gesagt: Alles nicht so schwer, aber es erfordert eine längere Einarbeitung und permanente Pflege und vor allem den Willen, sich mit Perl-Programmierung (oder besagter Alternative) zu beschäftigen, wäre ich heute vermutlich auch hier (manches war klar, aber man verdrängt es doch leicht), aber nicht so kritisch gegenüber dem blauäugigen Versprechen, irgendetwas sei "einfach".

Diese Klarheit wünsche ich mir gegenüber Einsteigern, das ist nach meinem _Empfinden_ nicht mehr wie fair.
[/OT]
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

Zitat von: Ellert am 02 August 2018, 19:20:21
M.E. wäre es ehrlicher, wenn von Anfang an klargestellt würde, dass die Verwendung für komplexere Szenarien die Einarbeitung in eine sehr spezielle Syntax erfordert.
Machen wir einen Anfang und reduzieren diesen Abschnitt https://wiki.fhem.de/wiki/Quick-Start#Zeitabh.C3.A4ngige_Kommandos aufDer interessierte Leser wird dann dem Link zum Timehandler folgen und hat dann beim Weiterlesen die Auswahl inkl. weiterführender Verknüpfung zu vollständigen Informationen als Grundlage seiner freien Wahl.

Damit wird der Quickstart schlanker, für den eiligen Leser.
Das wäre allenfalls für das deutsche Quickstart eine Möglichkeit. Für das englische Quickstart hingegen ist es wenig zielführend, wenn man bei solchen Grundlagen direkt auf deutschen Seiten landet. Das schreckt jeden Nicht-Deutschsprachigen von der FHEM-Nutzung ab. Damit ist man quasi zwangsläufig bei Abweichungen zwischen deutschen und englischen Quickstart und verursacht zusätzlichen Pflegeaufwand.

Letztlich ist das Problem alleine in der entgegen https://forum.fhem.de/index.php/topic,18962.0.html nicht vorhandenen (vollständigen) englischen commandref von DOIF begründet. Dies macht das Modul für jeden Nicht-Deutschsprachigen nahezu unbenutzbar und Hinweise im englischen Quickstart auf DOIF sind wenig angebracht.

Ellert

#10
Ich zitiere aus einem zentralen Artikel des Wiki: https://wiki.fhem.de/wiki/Dokumentationsstruktur
ZitatEs bleibt deshalb nicht aus, dass die Dokumentation manchmal nicht ganz aktuell ist, manchmal in sich widersprüchlich oder anderen Quellen widersprechend, oder manchmal nicht in der Wunschsprache verfügbar ist.

Mit diesem (leichten) Chaos müssen wir leben, Beschwerden darüber werden in der Regel nicht gut aufgenommen.

Ellert

Gibt es Bedarf an englischsprachigen Texten im Wiki?

Im Forum stehen 2088 englischsprachige Beiträge etwa 500 000 deutschsprachigen Beiträgen gegenüber, das sind etwa 0,4 %.

krikan

#12
Zitat von: Ellert am 03 August 2018, 07:49:55
Ich zitiere aus einem zentralen Artikel des Wiki: https://wiki.fhem.de/wiki/Dokumentationsstruktur
Das Zitat passt hier überhaupt nicht.

Nochmals: Quickstart ist Verlagerung einer fhem.de - Seite ins Wiki und hat eine Sonderrolle im Wiki (wie auch "Erste Schritte"). Quickstart muss zwangsläufig in deutsch und englisch vorliegen.

Offizielle Hauptsprache von FHEM bleibt Englisch, auch wenn DOIF sich nicht an die Hinweise für Entwickler (=englische commandref) hält.

Es sollte jedem einleuchten, dass bei einer Software (FHEM), die Englisch als Hauptsprache angibt, die wichtigen Seiten auch komplett in Englisch vorliegen und nicht unnötig auf deutsche Seiten verlinken.

DOIF hält sich nicht an die Entwicklungsrichtlinien und es gibt daher keinen Grund DOIF im englischen Artikel zu erwähnen. Das vertreibt nicht-deutschsprachige Anwender, insbesondere verbunden mit solchen von Dir eingefügten Aussagen:  "But it lacks on new event handler like DOIF and other basic modules..". Das schadet FHEM.

Schreibt erst einmal die englische commandref zu DOIF, dann können wir uns inhaltlich mit der Aufnahme im Quickstart auseinandersetzen.

Ellert

Ich zitiere nochmals aus https://wiki.fhem.de/wiki/Dokumentationsstruktur
ZitatDabei gibt es keine zentrale Steuerung (wie etwa in einem ähnlich großen Industrieprojekt), sondern nur ein paar Regeln, an die sich (mehr oder weniger) alle halten

Im englischsprachigen Quickstart wird auf den deutschsprachigen Einsteigerleitfaden verwiesen. Ist Dir das entgangen?

krikan

Warum gehst Du nicht auf das eigentliche Problem sowie meine Argumente ein und lieferst Lösungsansätze? Schreibe ich zu undeutlich/unverständlich? Entschuldige bitte, aber eine Diskussion ist für mich so schwierig und wenig zielführend.

Also zu Deinen neuen Hinweisen:
ZitatIch zitiere nochmals aus https://wiki.fhem.de/wiki/Dokumentationsstruktur
Ich auch:
ZitatFür die an der Entwicklung von FHEM beteiligten Softwareentwickler (Modulautoren) gibt es eine einzige verpflichtende Vorgabe: Offizielle Module müssen über eine englischsprachige CommandRef verfügen.
Hat DOIF nicht oder kannst Du DOIF nur mit der englischsprachigen commandref (Feature-Liste) irgendwie nutzen?

ZitatIm englischsprachigen Quickstart wird auf den deutschsprachigen Einsteigerleitfaden verwiesen. Ist Dir das entgangen?
Nein.
Das ist nur ergänzend, falls das dort geschriebene zutrifft: "are able to read german". Ansonsten kann man problemlos mit der englischen commandref klarkommen; außer bei DOIF, das eine solche nicht hat.
Als englischsprachiger FHEM-Interessent, würde ich auf das "neue" verlinkte Modul DOIF klicken und keine vollständige englische commandref finden. Folgegedanke: neue Module gibt es nur auf deutsch erklärt, dann beschäftige ich mich nicht mehr mit FHEM und schon werden wir weniger international.

Gruß, Christian

Beta-User

Und wenn ihr schon mit der "Dokumentationsstruktur" rumargumentiert: das hat auch nur "jemand" mal geschrieben, weil es nirgends dokumentiert war, aber als notwendig erachtet wurde, verbunden mit dem Versuch, die bereits vorhandenen Infos einigermaßen sinnvoll mit einzubinden.

Da mag es durchaus Verbesserungspotential geben, zumal auch dort im wesentlichen "nur" der Ist-Zustand wiedergegeben war/ist - einschließlich der Nachlässigkeiten einiger weniger Modulautoren beim Thema englische commandref. Das jetzt als "Entschuldigung" dafür zu nehmen, dass es ja von den Projektverantwortlichen (zu denen ich als "Urautor" des bezogenen Artikels nicht gehöre) alles nicht so erst gemeint war, ist fast schon nicht mehr lustig >:( .

Klar ist jedenfalls, dass "Wunschsprache" was anderes ist als die "Pflichtsprache" (Englisch).

(Muß mir das mal ansehen, es gab und gibt _zwei_ Vorgaben: Englische Commandref + 3 Monate Support im Forum)
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

Das Modul wird in der bestehenden Form nicht abgewiesen, daraus schliesse ich, dass alle zwingenden Vorgaben ausreichend erfüllt sind.

Alle weitergehenden, hier vorgetragenen Forderungen und Bedenken sind persönlicher Natur und daher irrelevant hinsichtlich der Entscheidung, ob Wikibeiträge erscheinen dürfen oder nicht. Alles andere ist Zensur.


Beta-User

Ziemlich digitale Denke, oder nicht? Dazu noch sehr formalistisch.
Zitat von: Ellert am 03 August 2018, 14:47:19Das Modul wird in der bestehenden Form nicht abgewiesen, daraus schliesse ich, dass alle zwingenden Vorgaben ausreichend erfüllt sind.
_Das_ wäre Zensur, oder etwa nicht? (Also das Zurückweisen eines Moduls wegen einer als schlecht empfundenen englischen commandref).

Übrigens wäre mir nicht bekannt, dass es jemanden gäbe, der eine qualitative Beurteilung vornehmen würde, ob die commandref oder das Modul an sich irgendwelchen Vorgaben entspricht. Es gab nach meiner Erinnerung, die aber nicht in der Bronzezeit anfängt, auch nur einen oder zwei Fälle, in denen Nachbesserung verlangt wurde; da hatte der jeweilige Autor gemeint, eine Kopie der deutschen Commandref mit Englischen =pod würde den Anforderungen auch genügen (oder ein Link auf die deutsche CR, irgend so eine offensichtliche Mogelei halt) .
Das ist hoffentlich nicht das Niveau der Diskussion, die wir gemeinschaftlich anstreben sollten. Aber die Commandref zu DOIF+Tools geht im Englischen auf 2-3 A4-Blätter, im Deutschen ist sie gefühlt genauso umfangreich wie die commandref im Übrigen.
Da stimmt doch was grundlegend nicht, oder?

Nicht mal das berühmte "?" ist erläutert...

ZitatAlle weitergehenden, hier vorgetragenen Forderungen und Bedenken sind persönlicher Natur und daher irrelevant hinsichtlich der Entscheidung, ob Wikibeiträge erscheinen dürfen oder nicht. Alles andere ist Zensur.
Wieder sehr digital, und nach meinem _Empfinden_ insbesondere auch nicht den umfangreichen und sachlichen Stellungnahmen von krikan angemessen (der im Übrigen auch andere Leute schubst, wenn was nicht korrekt ist)...
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

Ja, "das Zurückweisen eines Moduls wegen einer als schlecht empfundenen englischen commandref" wäre Zensur, daher wird es nicht gemacht.

Wo der Modulautor seinen Schwerpunkt setzt, bleibt ihm überlassen und das ist auch gut so.

Ich habe für DOIFtools in der deutschen Befehlsreferenz englischsprachige Beispiele, angegeben, die sehe ich für einen englischlesenden Benutzer als ausreichend an.

In DOIF sieht es ähnlich aus, aber da bin ich der falsche Addressat.

Das Fragezeichen ist übrigens erklärt, es gibt sogar einen Eintrag im Inhaltsverzeichnis https://fhem.de/commandref_DE.html#DOIF_Zeitintervalle_Readings_und_Status_ohne_Trigger und eine Erwähnung in der Kurzreferenz unter "Trigger verhindern"

Bei einer potentiellen Leserschaft von 0,4% müssen sich die Leser anstrengen, wenn der Anteil der nicht deutschsprechenden englischsprachigen Nutzer einen ernstzunehmenden Anteil darstellt, wird ein Modulautor den Schwerpunkt verschieben müssen, wenn die Akzeptanz des Moduls weiterhin gewährleistet sein soll.
Der Schwerpunkt ist eine Abwägung von Aufwand und Nutzen.

13 Jahre englischsprachige Befehlsreferenz haben zu keiner nennenswerten Verbreitung über den deutschsprachigen Raum hinaus geführt.
4 Jahre deutschsprachiger Schwerpunkt in der DOIF-Befehlsreferenz führt dazu, dass in mehr als 50% der FHEM-Installationen DOIF verwendet wird. Und das, obwohl DOIF in den allgemeinen Einsteigerdokumenten nicht oder unangemessen untergeordnet Erwähnung findet.

Ich habe den englischen Quickstart eigentlich nur der Vollständigkeit halber angepasst, bei 0,4% potentieller Leserschaft ärgere ich mich schon fast des Aufwandes wegen.
Von mir aus können die, nach krikans Meinung störenden Verweise, nicht die Texte aus dem englischsprachigen Quickstart entfernt werden, ich hänge nicht daran.

Mein theoretischer Leser wird durch die Eigenschaftenliste neugierig und übersetzt sich die deutschsprachige Befehlsreferenz und stellt sie ins Wiki, er ist allerdings Chinese  ;)


Beta-User

Und wenn es 0,0001% wären, die gerne eine vernünftige englische commandref hätten: DAS ist die (fast einzige) verpflichtende Vorgabe... Darüber zu diskutieren ist hier nicht der richtige Ort, diese Frage ist m.E. eindeutig geklärt.

Und wenn "alles da" ist, ist es auch ein leichtes, das mit ein paar netten englichen Sätzen drumrum zu garnieren für eine zulässige Commandref. Jedenfalls macht die ständige Wiederholung, dass es ja eine deutsche commandref gibt (in der das "?" natürlich ausgiebigst erläutert ist), macht den Hinweis nicht falsch, dass die Vorgabe NICHT EINGEHALTEN ist.
Aber wie gesagt: Diese Diskussion ist mindestens unter deinem intellektuellen Niveau.

Vielleicht findet sich ja jemand, der das Problem lösen möchte (gerne dein fiktiver Leser mit chinesischen Sprachkenntnissen).... Das wäre eine Chance, auch die Doku ggf. zu straffen, damit 100% der FHEM-User (oder zumindest 100%-1 Person) glückliche DOIF-User werden können und verstehen, was sie da eigentlich tun...
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

Wir hatten unser Thema bereits geklärt.

Das Thema Befehlsreferenz ist OFF-TOPIC, aber es füllt das Sommerloch, insofern muss ich richtig stellen:

Ein offizielles Modul erfüllt alle notwendigen Vorgaben, sonst wäre es kein offizielles Modul geworden.

Daher ist die Aussage falsch "dass die Vorgabe NICHT EINGEHALTEN ist".

Aber nicht jeder ist bereit der Argumentation zu folgen - weil sie keinen Spielraum bietet.