Warum will jeder DOIF verwenden?

[Thorsten Pferdekaemper]

Die Behauptungen der Fragestellung sind sehr subjektiv und die Fakten sind ungenau recherchiert.

Ich habe das absichtlich so formuliert, um zumindest ein paar Antworten zu provozieren. Ich meine das auch gar nicht über alle Forumsbereiche und Installationen hinweg, sondern speziell hier im Anfängerforum. Zumindest meinem Gefühl nach kommen hier einige schnell mit DOIF an und wenn man mal notify vorschlägt wird man eher ignoriert.
Nein, ich führe dazu keine Statistik und was ich zu dem Thema von mir gebe ist sehr unwissenschaftlich.
Gruß,
   Thorsten

[Morgennebel]

Ich verwende nur DOIF. Keine at/notify.

Grund ist die hervorragende, komplette Doku in der commandref, die mit vielen Beispielen und Lösungsansätzen kommt. Und die toller Support im DOIF-Forum.

Ciao, -MN

[Ellert]

Ich habe das absichtlich so formuliert, um zumindest ein paar Antworten zu provozieren. Ich meine das auch gar nicht über alle Forumsbereiche und Installationen hinweg, sondern speziell hier im Anfängerforum. Zumindest meinem Gefühl nach kommen hier einige schnell mit DOIF an und wenn man mal notify vorschlägt wird man eher ignoriert.
Nein, ich führe dazu keine Statistik und was ich zu dem Thema von mir gebe ist sehr unwissenschaftlich.
Gruß,
   Thorsten

Nur am Rande, die Statistik wird über das Forum bereitgestellt, für jeden einsehbar: https://fhem.de/stats/statistics.html

Gut, dann lasse ich mich auch zu einer weiteren Antwort provozieren.

Ich fing mit FHEM als DOIF eingeführt wurde.
Da hatte zunächst at genutzt, um das Gartenlicht zuschalten.
Vier Definitionen (morgens ein, morgens aus, abends ein, abends aus) für eine Schaltuhr, fand ich unübersichtlich.

Aus Neugier hatte ich mir alle Module in der Commandref angesehen, dabei erschien mir DOIF als das vielseitigere Modul, bei dem ich ohne Perl-Kenntnisse auskommen würde.

• Einfacher Zugriff auf Readings mit [gerätename:readingname] statt ReadingsVal("gerätename","gerätename","defaultwert")
• Simple Angabe von Zeitspannen mit Wochentagsbeschränkung [06:00-08:00|8]
• Es musste nicht überlegt werden, wann Zeichen zu verdoppeln sind und die zusetzenden Klammern hielten sich in Grenzen.
• Die Perl-Kenntisse wurden nebenbei geliefert, da alles ausserhalb der eckigen Klammern Perl ist.
• Überzeugt hatte mich auch die vollständige Dokumentation der Funktionen mit Beispielen, die kaum Fragen offen lies.
• Und nicht zu vergessen, die geduldige und hilfsbereite Betreuung durch Damian.

Während ich zu einer Frage zum at  häufiger abweisende Antworten las wie: "Die Frage wird hier schon zum x-ten Mal gestellt, benutze mal die Suche".
Wobei sich die Frage stellt, warum der so häufig nachgefragte Sachverhalt nicht in der Befehlsreferenz klar gestellt wird.
Das ist allerdings Off-Topic und gehört in den Thread: Warum ist at so unbeliebt?  Was natürlich nicht der Fall ist.

[Tueftler1983]

Ich komme mit dem aufbau, der Syntax in notify nicht klar.
Mir fällt DOIF leichter ich habe 8 notify die ich nur via drag und drop und leichten Änderungen eingerichtet habe und ca 30 DOIF die ich alle selbst geschrieben habe.

[raimundl]

Ich bin ein absoluter DOIF - Fan!
Hätte es DOIF zum Zeitpunkt des Kennenlernens von FHEM nicht gegeben, wäre FHEM für mich wahrscheinlich ein interessantes Probierprojekt geworden und hätte nie den Stellenwert bekommen, den es heute in der Hausautomatisation bei mir einnimmt.

Für mich war DOIF eine Brücke um Null Perl Kenntnisse und geringe Linuxkenntnisse auszugleichen. Ein bedeutender Faktor ist auch, dass ich bei DOIF eine durchgehende und leicht zu verstehende Dokumentation an einem Ort habe. Bei den anderen Möglichkeiten ist schon ein sehr hoher Suchaufwand notwendig um ans Ziel zu kommen.   

So kann ich heute in die Hausautomatistion investieren, weil ich mir sehr sicher bin, für alle meine Wünsche eine Lösung zu erreichen.

Natürlich ist mir bewusst, dass FHEM auch ohne DOIF eine, ich möchte sagen, sensationelle Lösung ist und ich bewundere die Bereitschaft und das Wissen aller jener, die hier mitarbeiten.

Zur Veranschaulichung meiner obigen Aussagen ein Praxisbeispiel:
Vor kurzem habe ich das tolle Modul "70_GSMSMS senden und empfangen von SMS Nachrichten" installiert.

Der Autor brachte auch ein Beispiel einer Anwendung:

Code Auswählen Erweitern

Ich kann über eine eingehende SMS "Status" von jedem Handy bestimmte zustände und
Messwerte per SMS abfragen. Dabei wird die Rufnummer dynamisch ausgetauscht.
(siehe my $MSGStatus_1)

# Statusabfrage über SMS (Code = Status)
define Status_GSMModem_N notify GSMModem.*Message.*Status {\
my $MSGStatus_1 = ReadingsVal("GSMModem","From","");;\
my $MSGStatus_2 = Value("Alarm_Aktiv").'<br>';;\
$MSGStatus_2 = $MSGStatus_2.myMessageStatus();;\
fhem("set GSMModem MSGTxt $MSGStatus_2");;\
fhem("set GSMModem MSGNumber $MSGStatus_1");;\
fhem("set GSMModem MSGSend")\
}
attr Status_GSMModem_N room Alarm

Dazu kommt noch ein nicht unerheblicher Teil im

bei mir ist in 99_myUtils.pm noch eine Funktion hinterlegt:

# Statusanfrage Zusammenstellen #########################
sub myMessageStatus {
    my $status = "";
    $status = $status."WZ ".Value("Wohnen_Temp")."<br>";
    $status = $status."SZ ".Value("Schlafen_Temp")."<br>";
    $status = $status."KE ".Value("Keller_Temp")."<br>";
    $status = $status."WS ".Value("KS300_Wetter")."<br>";
    $status = $status."EVU ".Value("EVU_Tag")."<br>";
    $status = $status."RE ".Value("RE_Fuellstand");
    $status =~ s/ Bat: ok//g;
    $status =~ s/ KWh//g;
    $status =~ s/ %//g;   
    return $status;
}

der Dummy  Value("Alarm_Aktiv") kommt aus einem eigenen
Alarmmodul. Das Modul Schreibt in den Dammy alle anstehenden
Alarmtexte rein. (Das alles ist etwas kompakter mit Email, Telefonanruf, SMS usw.)


Und dann meine Lösung mit DOIF:

Code Auswählen Erweitern

define SMSAbfrage DOIF ([SMS:Message] eq "Status")
(set SMS MSGTxt [div. Readings])   
(set SMS MSGNumber [SMS:From])
(set SMS MSGSend)
attr wait 5
attr checkRaedingEvent 1
attr do always

Meine umfangreiche Stellungnahme sehe ich nicht rein als Antwort in diesem Thread, sondern ich wollte damit Dank zum Ausdruck bringen an alle die FHEM zu so einer sensationellen Entwicklung geführt haben. Natürlich ist mir bewusst, dass ich auch einen Teil beizutragen habe. Ich kann schon auf einige erfolgreiche Hilfestellungen von mir verweisen.

LG

[KölnSolar]

Naja, ich verstehe Thorsten.
das

[gerätename:readingname]

ist weder perl noch FHEM. Das

ReadingsVal("gerätename","gerätename","defaultwert")

schon.
und auch das

[06:00-08:00|8]

ist DOIF spezifisch. Somit aus meiner Sicht für Einsteiger weniger geeignet(und nur darum ging es Thorsten ja) Für Fortgeschrittene, die sofort die Spezialitäten der Syntax verstehen, zur Codereduzierung aber sehr hilfreich.
Und auch über gute Doku kann man sich trefflich streiten. Zumindest überfordert die Komplexität des DOIF einen Anfänger eher.

Zum Vergleich: Ich würde auch niemand raten mit dem Alarmanlagenmodul seine FHEM-Gehversuche zu machen, obwohl ICH das Modul toll finde.

Und was konkret ist an einem notify, abgesehen von korrekten RegExps  , so schwer ? Was konkret fehlt in der Doku zum Verständnis ?

[Thorsten Pferdekaemper]

Hi,
mir ging es gar nicht darum, das "bessere" oder "schlechtere" zu finden. Ich will hier auch gar nicht meine eigene Meinung zum DOIF verbreiten. Es ging mir nur darum, zu verstehen, warum Anfänger oft zuerst darauf zu stoßen scheinen obwohl das offensichtlich das komplexere Tool ist. Ich würde als Anfänger erst einmal die Finger von etwas lassen, was so viel Doku braucht. Wie gesagt: Deswegen ist es ja nicht schlechter.
Ich glaube aber, dass ich das jetzt verstanden habe. Danke für die Beiträge.
Ich werde auf jeden Fall auch in Zukunft Anfängern immer zuerst notify und at empfehlen. Für mich sieht das immer noch für den einfacheren Einstieg aus und es hilft auch eher, wie Arbeitsweise von FHEM zu verstehen.
Gruß,
   Thorsten

[Mitch]

Ich bin nicht der Meinung, das es das komplexere Tool ist. Was komplex ist, ist das was im Hintergrund abläuft, aber damit hat man als User ja nichts zu tun.
Ich finde für einen Anfänger ist DOIF das leichtere "Tool".
Klar, man lernt damit kein Perl.

Und ein ganz klarer Vorteil ist die extrem gute Doku und deutsch und englisch, sowie der Support.

[KölnSolar]

da haben wir wohl unterschiedliche Ansichten, was komplex bedeutet. DOIF commandref

It combines the functionality of a notify, at-, watchdog command with logical queries.

Complex problems can be solved with this module, which would otherwise be solved only with several modules at different locations in FHEM.

Und für die wenigen und trivialen at(*,+,Zeit)- und notify-Elemente(event) bedarfs dann auch keiner umfangreichen Doku. Und support ? Ist doch (fast) selbsterklärend.

Klar, man lernt damit kein Perl.

Lernt man mit at und notify auch nicht.
Edit: Schade eigentlich, dass sich nicht mal ein paar newbies zu Wort melden 

[Ellert]

Naja, ich verstehe Thorsten.
das  ist weder perl noch FHEM. Das  schon.
und auch das  ist DOIF spezifisch. Somit aus meiner Sicht für Einsteiger weniger geeignet(und nur darum ging es Thorsten ja) Für Fortgeschrittene, die sofort die Spezialitäten der Syntax verstehen, zur Codereduzierung aber sehr hilfreich.
Und auch über gute Doku kann man sich trefflich streiten. Zumindest überfordert die Komplexität des DOIF einen Anfänger eher.

Zum Vergleich: Ich würde auch niemand raten mit dem Alarmanlagenmodul seine FHEM-Gehversuche zu machen, obwohl ICH das Modul toll finde.

Und was konkret ist an einem notify, abgesehen von korrekten RegExps  , so schwer ? Was konkret fehlt in der Doku zum Verständnis ?

@KölnSolar:
Leider irrst Du Dich und behauptest fälschlicher Weise:

das [gerätename:readingname] ist weder perl noch FHEM

aus der Commandref:

Ab featurelevel 5.7 ersetzt das set und setreading Befehl
    [device:reading] mit dem Wert des Readings für device, falls sowohl device, als auch Reading existiert, und nicht leer ist.
    [device:reading:d] wie ohne :d, aber alles nicht-numerische wird entfernt, siehe ReadingsNum

Es ist eindeutig FHEM und dass es Perl ist habe ich nicht behauptet, da musst Du Dich verlesen haben.

Das ist eine sehr fragwürdige Argumentation:

[06:00-08:00|8] ist DOIF spezifisch. Somit aus meiner Sicht für Einsteiger weniger geeignet

Warum ist etwas weniger geeignet, wenn es DOIF spezifisch ist? Kannst Du zur Unterstützung Deiner Argumentation und Meinung ein mehr für Einsteiger geeignetes Beispiel posten?

Du deutest hier etwas an:

Und auch über gute Doku kann man sich trefflich streiten.

Würdest Du diese Aussage fairerweise präzisieren und ein Beispiel einer, Deiner Meinung nach, sehr guten Dokumentation in der Commandref anführen.

[Wuppi68]

notify ist 100% Ereignisorientiert

DOIF vesteckt dieses ein wenig sodaß es für viele FHEMler als Zustandsorientiert aussieht

Wie ist denn die "normale" Denke?

a) Wenn ich zu Hause bin und es dunkel ist --> mach die Lampe an (DOIF)
b) Wenn ich nach Hause komme und es dunkel ist --> mach die Lampe an (notify)

im Fall a ist die Bedingung gedanklich ein wenig einfacher zu erfassen

[KölnSolar]

@Ellert
Mir scheint Du willst mich missverstehen.  Ich habe doch gar nicht die gute Doku des DOIF angezweifelt. Wozu also Deine Frage ? Meine Aussage bezog sich auf die Doku von at und notify, die andere im Gegensatz zu mir, als schlecht empfanden.

Warum ist etwas weniger geeignet,

hab ich auch nicht gesagt, sondern

für Einsteiger weniger geeignet

was komplexer impliziert.

dass es Perl ist habe ich nicht behauptet, da musst Du Dich verlesen haben.

Wie kommst Du dazu zu glauben, meine allgemeine Aussage hätte sich auf Dich bezogen 

das [gerätename:readingname] ist weder perl noch FHEM

ziehe ich zurück. Mal wieder was gelernt  Das probier ich direkt mal in userreadings anstatt ReadingsVal aus.
@Wuppi68
interessante Erklärung. wobei für mich eher b) normales Denken ist. Vielleicht haben mich die Jahre FHEM und notify aber auch verseucht 

Edit: Versuch ReadingsVal zu ersetzen ist fehlgeschlagen. Fazit: ReadingsVal kann man immer einsetzen, während [gerätename:readingname] nur bei set, setreading und DOIF funktioniert. Was sollte ein Anfänger wohl zuerst lernen ?

[Thorsten Pferdekaemper]

Klar, man lernt damit kein Perl.

Hier sind die DEFs von ein paar meiner notifys:

Code Auswählen Erweitern


dg_fl_Taster1b:press_long:.*|dg_fl_Taster1b:press_short:.*|og_fl_Klingelsensor:trigger_cnt.* set dg_fl_KlingelLed press; set dg_fl_KlingelSound press; set dg_fl_Mp3Klingel_Led led greenL 3; set dg_fl_Mp3Klingel_Mp3 playTone 25,25
dg_fl_Taster3a:press_long:.* set dg.*Lampe.* off
dg_sz_Remote2:LongRelease.* set dg.*Lampe.* off
dg_sz_Remote3:Short.* set dg_fl_Lampe12 toggle
tr_Treppenlicht.off IF ([dg_fl_Lampe09:state] ne 'off') (set dg_fl_Lampe09 off)

Ich glaube, dass man damit auch kein Perl lernt.
Gruß,
   Thorsten

[Damian]

Hier sind die DEFs von ein paar meiner notifys:

Code Auswählen Erweitern


dg_fl_Taster1b:press_long:.*|dg_fl_Taster1b:press_short:.*|og_fl_Klingelsensor:trigger_cnt.* set dg_fl_KlingelLed press; set dg_fl_KlingelSound press; set dg_fl_Mp3Klingel_Led led greenL 3; set dg_fl_Mp3Klingel_Mp3 playTone 25,25
dg_fl_Taster3a:press_long:.* set dg.*Lampe.* off
dg_sz_Remote2:LongRelease.* set dg.*Lampe.* off
dg_sz_Remote3:Short.* set dg_fl_Lampe12 toggle
tr_Treppenlicht.off IF ([dg_fl_Lampe09:state] ne 'off') (set dg_fl_Lampe09 off)

Ich glaube, dass man damit auch kein Perl lernt.
Gruß,
   Thorsten

Perl lernt man, wenn man selbst FHEM-Module programmiert.

Es wundert mich, dass du IF benutzt.

Warum ich DOIF programmiert habe? Ganz kurz:

Insgesamt sehe ich ein großes Potenzial in Open-Source-Software, wenngleich FHEM eigentlich nicht für den "Massenmarkt" konzipiert wurde. Es setzt Programmierkenntnisse in Perl voraus und war eben genau auf meine damaligen Befürnisse als Programmierer hin ausgerichtet. So ist gerade auch der Einstieg für viele Anfänger schwierig, wobei ich es derzeitig auch nicht forciere, dass FHEM großartig wächst.

Quelle: http://www.meintechblog.de/2015/07/rudolf-koenig-im-interview-der-erfinder-von-fhem-zum-thema-smart-home/

Die Rechnung scheint aufzugehen

Wir sollten in zwei Jahren die Diskussion hier fortführen.

Zum DOIF-Modul werde ich mich nicht äußern - das wäre unfair - dafür kenne ich mich damit zu gut aus

[Puschel74]

Die Frage würde eigentlich unter Off-Topic perfekt passen.
Hat nicht direkt was mit FHEM zu tun
Hat nicht direkt was it einem Code zu tun
Hat nicht direkt was mit einem Gerät zu tun
...
Wozu gibt es im Forum passende Unterbereiche 
Ach egal, posten eben alle wo es grad schön ist.