Warum will jeder DOIF verwenden?

[Pfriemler]

Jetzt setze ich mich mal dazu in die Nesseln:
Ich setze DOIF ein, seit es gefühlt ein Viertel der Funktionen hatte die es jetzt hat.
FHEM-mäßig betrachte ich mich als maximal fortgeschrittener Anfänger. Ich bin auch älter, komme auch aus der BASIC-Zeit und mir hat die DOIF-Syntax vom Fleck weg spontan zugesagt. Trotzdem halten sich bei mir DOIFs und notifys die Waage.
Das hat mehrere Gründe:
1. manche Dinge sind mit notifys klein und kompakt realisierbar. Wurde hier genügend bebeispielt. Dafür bemühe ich kein DOIF. Außerdem können notifys mit kunstvollen Regexen und akribischer, leider auch sehr sensibler Zeichensetzung (KEIN Anfänger versteht, was ein Punkt bewirken soll - die Krone des Unverständnisses ist aus meiner Sicht der Retrigger-Punkt am Ende eines Watchdogs) auf kleinstem Raum unglaublich komplexe Dinge vollbringen, sie können dadurch Dutzende Definitionen ihrer selbst ersetzen - aber sie sind komplett unlesbar für den, der nicht jemals gleichwertiges vollbracht hat. Wenn man es einmal aber verstanden hat, ist man begeistert, was damit alles geht. Aber der Weg dahin kann sehr lang sein.
2. auch schon gesagt: ein DOIF kann etliche at's, notifys und watchdogs ersetzen. Und gerade das ist die Stärke: Das Gefleddere an Einzelaktionen und -definitionen, welches ich entweder dank eines Elefantengedächtnisses, einer umfassenden privaten Dokumentation oder anhand des unverzichtbaren "probably associated with" (welches bei regexlastigen notifys systembedingt völlig versagt) nach Monaten mühsam zusammensuchen und in einem Dutzend Browsertabs parallel geöffnet halten muss, finde ich bei DOIF in genau einem DEF-Fenster wieder, wenn ich es konsequent umgesetzt habe. Klar sind DOIFs dadurch komplexer als notifys & Co. Aber gerade die Chance, alle ein bestimmtes System, ein Interface, einen Aktor betreffenden Aktionen an einer Stelle zusammen zu definieren, finde ich persönlich viel angenehmer.
3. Gar nicht mehr missen möchte ich die Möglichkeit, einzelne Bestandteile eines DOIFs (nicht ganzer Bedingungsdefinitionen, das ginge mit disable in notifys noch viel einfacher) partiell zu deaktivieren oder meine Definition reichlich zu kommentieren - das hat mir schon öfter den A... gerettet.

Um auf die Eingangsfrage zu kommen: Ich glaube, DOIFs sprechen vor allem Nicht-IT-Fachleute an. (Die Idee mit dem Baukastensystem zum Zusammenklicken finde ich übrigens super, aber genau sowas hätte ich mir schon längst bei Direktverknüpfungen in HomeMatic gewünscht - es ist in dem Umfang vermutlich gar nicht realistisch in FHEM umsetzbar. Nein, sollte auch nicht wirklich.). Es senkt die Einstiegshürde beträchtlich (wenn man es entsprechend einfach umsetzt - ich selbst nutze vielleicht 15% der Möglichkeiten die DOIF inzwischen bietet). Und es macht einfache Abläufe gesammelt an einem Ort sehr viel übersichtlicher. Mit der Klammerhierarchie hatte ich noch nie ernste Probleme.
Auch schon gesagt: Es ist ein großer Luxus in FHEM, dass man ein Ziel mit so vielen unterschiedlichen Möglichkeiten umsetzen kann. In jedem Fall ist es eine Bereicherung für FHEM.

[chrille76]

Ich würde mich als Anfänger bezeichnen und würde gern die Ursprungsfrage beantworten. Warum ich relativ schnell bei DOIF gelandet bin? Weil es gleich bei meiner ersten Automatisierung überhaupt im Gegensatz zum notify funktioniert hat!

Siehe: https://forum.fhem.de/index.php/topic,52675.msg517542.html -> Speziell Post #11

Gruß

[Damian]

ob DOIF oder notify hat alles seine Vor und Nachteile wenn komplexer wird. zB. 2 Timer und wenn das Ereignis in der Zwischenzeit wieder verschwunden ist (Fenster ist wieder zu) dann laufen meist die Timer noch und melden noch unsinnig weiter.

Ich habe mir daher komplexe Meldungen über die 99_myUtils (Beispiel von Benni) gelöst, das meine Wünsche alle erfüllt.
https://forum.fhem.de/index.php/topic,36504.0.html
Mit einem ziemlich global gehaltenem notify ( notify .*:(open|tilted) ) werden hier mit einem einzigen notify ( und eines für "closed" ) alle Fenster und Türen durch gezieltes setzen von Attributen überwacht und 1. die Anzahl der Wiederholungen und 2. die verschachtelten Timer gesteuert. Das Schöne daran, die Timer werden auch wieder gelöscht wenn vorzeitig abgebrochen wird.

Der Aufbau mit DOIF und notify alleine wäre mir dazu zu kompliziert und vor allem die Anzahl der doifs und notifys zu viel. Aber prinzipiell ist für mich der notify verständlicher und vor allem die Syntax leichter zu verstehen. Aber ich finde es soll jeder das nehmen womit er sich leichter tut, es merkt ohnehin jeder bald wo die Grenzen liegen.

LG

In der aktuellen Doku zu DOIF-Modul sind folgende zwei Beispiele zum Thema "verzögerte Fenster-Meldung", die aufzeigen, wie man mit einem DOIF etwas generalisieren kann. An diesem Beispiel kann man sehen, dass DOIF und at bzw. sleep sich keinesfalls ausschließen müssen, sondern sich sogar ergänzen können:

Verzögerte "Fenster offen"-Meldung

Code Auswählen Erweitern

define di_window_open DOIF (["^window_:open|tilted"])
(defmod at_$DEVICE at +00:05 set send window $DEVICE open)
DOELSEIF (["^window_:closed"])
(delete at_$DEVICE)

attr di_window_open do always

Alternative mit sleep

Code Auswählen Erweitern

define di_window_open DOIF (["^window_:open|tilted"])
(sleep 300 $DEVICE quiet;set send window $DEVICE open)
DOELSEIF (["^window_:closed"])
(cancel $DEVICE quiet)


P. S. Ich weiß, dass man es auch mit einem notify und etwas Perlcode genauso machen kann

[Garbsen]

Aber nun gut.

Ich denke, dass alle die hier Ihren Senf dazu geben, egal ob Modulentwickler (welches auch immer), Supporter etc. ein große Lob verdient haben.

Und egal wie die Vorlieben liegen (Modul bezogen)    das ich bei FHEM geblieben bin, ist auf jeden Fall der Community hier zu verdanken !!!

Gruß und macht weiter so.

Sascha

Schön gesagt! Und ich schließe mich dem gerne und nachdrücklich an.

[l.with]

In der aktuellen Doku zu DOIF-Modul sind folgende zwei Beispiele zum Thema "verzögerte Fenster-Meldung", die aufzeigen, wie man mit einem DOIF etwas generalisieren kann. An diesem Beispiel kann man sehen, dass DOIF und at bzw. sleep sich keinesfalls ausschließen müssen, sondern sich sogar ergänzen können:

Verzögerte "Fenster offen"-Meldung

Code Auswählen Erweitern

define di_window_open DOIF (["^window_:open|tilted"])
(defmod at_$DEVICE at +00:05 set send window $DEVICE open)
DOELSEIF (["^window_:closed"])
(delete at_$DEVICE)

attr di_window_open do always

Alternative mit sleep

Code Auswählen Erweitern

define di_window_open DOIF (["^window_:open|tilted"])
(sleep 300 $DEVICE quiet;set send window $DEVICE open)
DOELSEIF (["^window_:closed"])
(cancel $DEVICE quiet)


P. S. Ich weiß, dass man es auch mit einem notify und etwas Perlcode genauso machen kann

Damit könnte ich tatsächlich einige notify ersetzen.
Ich habe aber noch eine Verständnisfrage: Wie ist "send" definiert?

Herzliche Grüße
Lars

[Damian]

Damit könnte ich tatsächlich einige notify ersetzen.
Ich habe aber noch eine Verständnisfrage: Wie ist "send" definiert?

Herzliche Grüße
Lars

Gar nicht. Das waren nur Beispiele, um zu zeigen, wie man das betroffen Device meldet. Jeder hat da sein eigenes Benachrichtungssystem. Wenn send ein dummy wäre, dann könntest du im Status die Meldung sehen.

[pula]

Hmm... Um auch meinen Senf dazu zu geben.
Ich habe doif auch nur sehr mäßig im Einsatz - wenn es irgendwie geht, löse ich Dinge eher mit notify, at und perl. Ist aber sicher Geschmacks-Sache. Als ich mit fhem begonnen habe, hatte ich noch mehr doifs im Einsatz, aber aus einem Grund, an den ich mich eigentlich nicht mehr erinnere, hab ich dann die meisten doif durch notify abgelöst...

Cheers,

Pula

[spi3845]

So eine ähnliche Frage habe ich unter https://forum.fhem.de/index.php/topic,69704.0.html auch gestellt. Ich nutze erst seit kurzem fhem und bin schon in viele Fettnäpfe getreten. Mit meiner Rollladensteuerung bin ich schnell bei DOIF gelandet, hatte aber den Eindruck, dass ich meinen Code in wenigen Wochen nicht mehr werde nachvollziehen können und wollte wissen, wie ich das noch anders lösen kann. Daraus ist eine Diskussion zu notify/at/DOIF entstanden am Beispiel besagter Rollladensteuerung. Inzwischen habe ich die Steuerung mit notify nachgebildet und kann sie besser nachvollziehen, da bei DOIF die Reihenfolge der DOELSEIF-Zweige auch wichtig ist (erst die spezielleren Bedingungen, dann die allgemeineren?) und ich bei meinen vielen Zweigen den Überblick verloren habe. Dafür scheint mir DOIF einfacher bei zeitlichen Ereignissen oder wenn insgesamt nur wenige Bedingungen benötigt werden.

[screetch82]

also ich bin Anfänger und hatte gleich am Anfang DOIF im kopf bevor ich wusste das dies ein extra modul ist und keine standartfunktion.
Schon im Informatikunterricht hatte ich in der Schule bei Pascal if then usw gelernt und dann ist doif nicht weit weg ala wenn  wert X oder Status X dann tue ZZZ

[leif]

Vielleicht kann sich auch mal ein wirklicher Anfänger dazu äußern, warum er (oder sie...) DOIF verwendet bzw. verwenden will.

Auch wenn es ein alter Thread ist stößt man ja relativ schnell wieder darauf - also mal meine Gedanken als frischer Einsteiger. Mir stellte sich nämlich derzeit die Frage "Warum nutzen manche überhaupt notify wenn es mit DOIF geht, was viel logischer klingt?". 

DOIF beschreibt einfach wesentlich besser was es macht - unter ein Notify kann man sich erst einmal nichts vorstellen. Da gingen meine Gedanken sofort in Richtung Notification, etwas dass ich mir also erst im wesentlich späteren Verlauf angeschaut hätte wenn ich mir selbst Benachrichtigungen schicken möchte. "Trigger" oder was auch immer - aber mit "notify" hätte ich niemals mit etwas assoziiert dass Dinge schalten bzw ausführen kann.

Und dann kommt halt hinzu dass man mit der frischen Installation an nichts herangeführt wird. Ich denke die wenigsten werden sich am Anfang die Doku oder gar das PDF Buch zu Gemüte führen, denn bei der heutigen Vielzahl an Systemen steht erst einmal der Vergleich an. Ich hatte mir auch erstmal direkt FHEM, OpenHab2, Domoticz, HomeAssistant usw installiert und habe auch jetzt noch FHEM und HomeAssistant parallel im Betrieb weil ich mich noch nicht entschieden habe. Da möchte man doch erst einmal zu schnellen Ergebnissen kommen und schauen womit sich das angedachte Szenario am einfachsten umsetzen lässt. Da werden ein paar YouTube Videos geschaut, Tutorials abgeändert usw, aber ein richtig tiefes eintauchen kommt doch erst viel später wenn man sich endgültig entschieden hat, da es sonst viel zu viel Zeit beanspruchen würde.

In sofern finde ich dass der Einstieg bei HomeAssistant etwas besser gelöst ist - vor allem mit deren neuen Ansatz. Nach dem ersten Start erscheint direkt eine Infobox mit ein paar hilfreiche Links zu den Ressourcen und deren neues Benutzerinterface gestaltet es sehr leicht direkt die ersten Geräte zu integrieren und einfache Automatisierungen zu realisieren. Da bringt einem quasi das Interface direkt auf den "richtigen" Weg und sobald die Wünsche komplexer werden ließt man sich dann halt mehr ein.

Wenn es in FHEM in der Benutzeroberfläche eine Möglichkeit gäbe durch wenige Klicks Eventänderungen mit Aktionen zu verknüpfen und dafür Notifiy verwendet werden würdem diese wahrscheinlich auch viele in der Zukunft weiterhin nutzen. Aber so wie es derzeit ist scheint DOIF für viele Kompletteinsteiger einfacher zu sein bzw "logischer" zu klingen.

Und dann ist da noch dieser Wiki Eintrag zum Notify
https://wiki.fhem.de/wiki/Notify

Also ich fand den als Anfänger eher abschreckend. Warum nimmt man ausgerechnet KNX als Beispiel? Was ist EIB? Was sollen die Zahlen 0/0/50 ? Ich wusste nicht einmal was KNX sein soll.

Für Einsteiger wäre es doch deutlich leichter wenn man praxisnahe Beispiele nehmen würde. Philips Hue oder ähnliches was heute fast jeder Einsteiger verwendet. Auch das finde ich bei Home Assistant wieder etwas besser gelöst. Dort worden schon direkt nach der Installation "gängige" Geräte wie die Hue Bridge erkannt und man hat direkt etwas zum "ausprobieren" während man hier an Dinge herangeführt wird die für viele überhaupt nicht praxisnah sind.

Ich hoffe das klang jetzt nicht "abwertend" oder so, aber das ist der erste Eindruck als Einsteiger. Ohne die praxisnahen YouTube Videos von haus-automatisierung hätte ich direkt wieder aufgegeben weil bei FHEM der erste Eindruck "von Programmierern, für Programmierer" schreit.

[Amenophis86]

Und dann ist da noch dieser Wiki Eintrag zum Notify
https://wiki.fhem.de/wiki/Notify

Also ich fand den als Anfänger eher abschreckend. Warum nimmt man ausgerechnet KNX als Beispiel? Was ist EIB? Was sollen die Zahlen 0/0/50 ? Ich wusste nicht einmal was KNX sein soll.

Du darfst dich gerne dran machen den Artikel umzuschreiben. Gerade als Anfänger erkannt man, was fehlt oder für einen längeren Benutzer klar ist, für einen Anfänger allerdings nicht.

weil bei FHEM der erste Eindruck "von Programmierern, für Programmierer" schreit.

Und genau das ist es / war es. Teilweise hat es sich geändert, ab FHEM war (soweit mit bekannt) nie als klick-bunti-tolli-System gedacht, sondern "Von Programmierern, für Programmierer". Es hat sich sicher einiges getan und der Ansatz wird nicht mehr zu 100% verfolgt, aber wenn man den Kommentaren des Hartenkerns von FHEM folgt, dann wird es vorerst auch so bleiben. Ich denke zumindest so lange, bis jemand eine klick-bunti-tolli-System-Oberfläche für FHEM programmiert hat. Aber das dürfte eine Mammutaufgabe sein, welche noch keiner angegangen ist, außer ein paar "neue" Nutzer immer mal wieder gefordert haben.

Aber wir kommen von DOIF / Notify / AT ab. Wenn du Probleme, oder Verbesserungen siehst, dann bist du herzlich eingeladen diese zu ändern / verbessern. Davon lebt FHEM und deswegen klappt das System auch so gut.

[maci]

Jetzt muss ich mich auch mal dazu äussern.

Ich denke, das DOIF deshalb so erfolgreich ist, weil viele User, den Denkansätzen aus anderen Programmierumgebungen folgen.
Wenn Wert erfüllt, dann mache das? Ist eigentlich eine klassische IF Abfrage, aber ich habe bei klassischen IF Abfragen oft das Problem, dass sie nicht funktionieren.
Ein DOIF hingegen schon, wenn mal einmal weiß wie es geht.
Ich verwende bei Abfragen nach mehreren Abhängigkeiten immer das DOIF.
Vielleicht auch deshalb, weil ich beim klassischen IF immer Probleme habe.

notify verwende ich sehr gerne, denn das ist die Klassik bei FHEM Einstieg. Genau so wie AT.
Notify ist eigentlich auch eine IF Abfrage, nur denkt selten jemand darauf.
Das notify macht ja auch nur etwas, wenn eine Bedingung erfüllt ist.
Richtig ist:

Ein notify reagiert auf ein Ereignis (Event). Der Auslöser (Trigger) dafür wird als RegEx festgelegt. Es erfolgt also keinerlei Bedingungsabfrage. Passt das Event mit der festgelegten Trigger RegEx über ein wird es aus geführt. Es werden dann entsprechende Befehle verarbeitet. Im normal Fall FHEM Befehle. set Lampe1 on, oder set Klima off. ... aus dem Beitrag von CoolTux

[Wernieman]

Um mal anders herum anzufangen:
Was mich an DOIF stört:

Es verleitet dazu, alles in einem Statement zu erledigen, was bekanntermaßen schlechter Programmierstiel ist. Leider "fallen" vor allem Anfänger darauf rein, genau so zu arbeiten. Wer weiß denn nach 1 Monat noch, was ein 10 Zeilen-Statement zu macht?

Genau das gleiche kann man mit notify erledigen. Man brauicht eventuell dazu mehrere und Dummys, dafür ist es aber einfacher zu lesen und vor allem zu debuggen.

[Pfriemler]

Ich bin da genau gegenteiliger Meinung. Aus Programmiersicht mag das stimmen, aber die sinnfällig zu einem Gerät gehörigen Dinge in einem DOIF zu vereinen statt sie über ein halbes Dutzend notifys zu verteilen, und das in einem optisch strukturierten DOIF zusammen auf einen Blick überschauen zu können, ist einer der Vorzüge. Was man zusammen in ein DOIF packt und was nicht, lernt man auch mit der Zeit.
Im Grunde sind DOIFs im Idealfall nicht weniger als vollständige Steuerprogramme für einzelne Geräte und damit sehr viel näher am Verständnis für den ungeübten Programmierer (von denen es ja hier einige geben soll  ).
Und das vielgelobte Associated With versagt bei Notifys, die ausgeklügelte Regex verwenden, ohnehin prinzipbedingt.

Hinweisen wollte ich aber auch darauf, dass gerade für notify inzwischen leistungsfähige Assistenten bereitstehen, sowohl für die Eventauswahl (Eventmonitor) als auch füt Aktionen (Dropdowns in der Definition).

Und ja: warum die standardisierte Option zur Reaktion auf ein Ereignis notify heißt, muss man auch erst mal verstehen.

Plus für FHEM: wer das Einsteigerdoc nicht liest, macht sich den Einstieg unnötig schwer.

[FranzB94]

Hi!

... Programmierstiel

Arbeitest Du damit? So ein Teil hat die Welt bisher mMn noch nicht erfunden.

Gruss Franz