Autor Thema: Unterstützung bei Aktualisierung von https://fhem.de/HOWTO_DE.html gesucht!  (Gelesen 12116 mal)

Offline krikan

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 6123
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

Offline Ellert

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3233
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.

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

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.


Offline krikan

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 6123
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.
« Letzte Änderung: 07 August 2018, 06:30:35 von krikan »

Offline krikan

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 6123
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.

Offline Ellert

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3233
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.

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

Offline krikan

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 6123
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.

Online Otto123

  • Hero Member
  • *****
  • Beiträge: 10671
    • Otto's Technik Blog
(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
Viele Grüße aus Leipzig
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7490+7412,WRT1900ACS-OpenWrt,Sonos,ET9200,Arduino nano,ESP8266
Zustimmung Zustimmung x 2 Liste anzeigen

Offline Ellert

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3233
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
Zustimmung Zustimmung x 1 Liste anzeigen

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 19532
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.
Zustimmung Zustimmung x 1 Liste anzeigen

Offline Ellert

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3233
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

Offline Ellert

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3233
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