Autor Thema: [geklärt] Eventhandler und Timehandler - "allgemein", "speziell" u.a.  (Gelesen 985 mal)

Online Beta-User

  • Hero Member
  • *****
  • Beiträge: 3990
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.:
Zitat
Spezielle 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
« Letzte Änderung: 04 August 2018, 06:46:35 von Beta-User »
Server: HP-T5740 mit Debian stretch (i386) + aktuellem FHEM | ConfigDB | VCCU mit einiger HM-Hardware | MySensors seriell (2.3.1-beta@RS485, div. konkrete Hardware, u.a. einige DS18B20) | Milight@ESP-GW@MQTT2 | zigbee2mqtt@MQTT2 | SIGNALduino | MapleCUN

Offline Ellert

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3140
Antw:Eventhandler und Timehandler - "allgemein", "speziell" u.a.
« Antwort #1 am: 01 August 2018, 13:20:35 »
Danke für die Anregungen.

zu Timehandler: Ich bin für knappe Formulierungen, ich würde den von Dir zitierten Satz ersetzen durch
Zitat
Spezielle 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
Zitat
Spezielle 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"?
« Letzte Änderung: 01 August 2018, 13:26:51 von Ellert »

Online Beta-User

  • Hero Member
  • *****
  • Beiträge: 3990
Antw:Eventhandler und Timehandler - "allgemein", "speziell" u.a.
« Antwort #2 am: 01 August 2018, 14:09:08 »
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".

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-T5740 mit Debian stretch (i386) + aktuellem FHEM | ConfigDB | VCCU mit einiger HM-Hardware | MySensors seriell (2.3.1-beta@RS485, div. konkrete Hardware, u.a. einige DS18B20) | Milight@ESP-GW@MQTT2 | zigbee2mqtt@MQTT2 | SIGNALduino | MapleCUN

Offline Ellert

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3140
Antw:Eventhandler und Timehandler - "allgemein", "speziell" u.a.
« Antwort #3 am: 01 August 2018, 15:34:28 »
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.
« Letzte Änderung: 01 August 2018, 15:44:19 von Ellert »

Online Beta-User

  • Hero Member
  • *****
  • Beiträge: 3990
Antw:Eventhandler und Timehandler - "allgemein", "speziell" u.a.
« Antwort #4 am: 01 August 2018, 16:01:38 »
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-T5740 mit Debian stretch (i386) + aktuellem FHEM | ConfigDB | VCCU mit einiger HM-Hardware | MySensors seriell (2.3.1-beta@RS485, div. konkrete Hardware, u.a. einige DS18B20) | Milight@ESP-GW@MQTT2 | zigbee2mqtt@MQTT2 | SIGNALduino | MapleCUN

Offline Ellert

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3140
Antw:Eventhandler und Timehandler - "allgemein", "speziell" u.a.
« Antwort #5 am: 02 August 2018, 09:15:56 »
Übrigens: wdt bindet ein Wochenprofil an nur ein device, das ist auch eher speziell als allgemein.

Online Beta-User

  • Hero Member
  • *****
  • Beiträge: 3990
Antw:Eventhandler und Timehandler - "allgemein", "speziell" u.a.
« Antwort #6 am: 02 August 2018, 16:18:28 »
...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-T5740 mit Debian stretch (i386) + aktuellem FHEM | ConfigDB | VCCU mit einiger HM-Hardware | MySensors seriell (2.3.1-beta@RS485, div. konkrete Hardware, u.a. einige DS18B20) | Milight@ESP-GW@MQTT2 | zigbee2mqtt@MQTT2 | SIGNALduino | MapleCUN

Offline Ellert

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3140
Antw:Eventhandler und Timehandler - "allgemein", "speziell" u.a.
« Antwort #7 am: 02 August 2018, 19:20:21 »
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
Zitat
Zur 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.
« Letzte Änderung: 02 August 2018, 19:27:08 von Ellert »

Online Beta-User

  • Hero Member
  • *****
  • Beiträge: 3990
Antw:Eventhandler und Timehandler - "allgemein", "speziell" u.a.
« Antwort #8 am: 02 August 2018, 19:55:40 »
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.).

Zitat
Machen 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-T5740 mit Debian stretch (i386) + aktuellem FHEM | ConfigDB | VCCU mit einiger HM-Hardware | MySensors seriell (2.3.1-beta@RS485, div. konkrete Hardware, u.a. einige DS18B20) | Milight@ESP-GW@MQTT2 | zigbee2mqtt@MQTT2 | SIGNALduino | MapleCUN

Online krikan

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 6043
Antw:Eventhandler und Timehandler - "allgemein", "speziell" u.a.
« Antwort #9 am: 02 August 2018, 21:17:34 »
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.

Offline Ellert

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3140
Antw:Eventhandler und Timehandler - "allgemein", "speziell" u.a.
« Antwort #10 am: 03 August 2018, 07:49:55 »
Ich zitiere aus einem zentralen Artikel des Wiki: https://wiki.fhem.de/wiki/Dokumentationsstruktur
Zitat
Es 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.
« Letzte Änderung: 03 August 2018, 07:52:10 von Ellert »

Offline Ellert

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3140
Antw:Eventhandler und Timehandler - "allgemein", "speziell" u.a.
« Antwort #11 am: 03 August 2018, 08:18:59 »
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 %.

Online krikan

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 6043
Antw:Eventhandler und Timehandler - "allgemein", "speziell" u.a.
« Antwort #12 am: 03 August 2018, 08:26:09 »
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.
« Letzte Änderung: 03 August 2018, 08:29:33 von krikan »

Offline Ellert

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3140
Antw:Eventhandler und Timehandler - "allgemein", "speziell" u.a.
« Antwort #13 am: 03 August 2018, 08:42:19 »
Ich zitiere nochmals aus https://wiki.fhem.de/wiki/Dokumentationsstruktur
Zitat
Dabei 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?

Online krikan

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 6043
Antw:Eventhandler und Timehandler - "allgemein", "speziell" u.a.
« Antwort #14 am: 03 August 2018, 10:34:55 »
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:
Zitat
Ich zitiere nochmals aus https://wiki.fhem.de/wiki/Dokumentationsstruktur
Ich auch:
Zitat
Fü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?

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