FHEM Forum

Hallo,
ich weiß, dass das keine Anfängerfrage ist, aber vielleicht können gerade Anfänger das beantworten: Warum ist DOIF so beliebt? Man liest ständig, dass Leute mit DOIF rumprobieren. Was ist mit dem guten alten notify oder at?
Ich meine diese Frage ernst. Steht vielleicht in irgendeiner Anleitung, dass DOIF besser ist als notify?
Gruß,
   Thorsten

Frage ich mich auch, ich habe vieles mit Notify gelöst.

Zumindest die einfachen Dinge sind mit notify schneller eingerichtet als DOIF.

DOIF ist sehr viel Mächtiger als notify oder at, das ist ein großer Vorteil. Aber wie gesagt für kleine Dinge die nicht so komplex sind reicht doch auch ein notify?

Ich nutze DOIF dann, wenn ich mehr als eine Bedingung habe.

DOIF ist ja schon so eine Art kleine State-Machine, da es im Standardfall immer eine aktive Bedingung gibt.
Dadurch lässt sich einiges einfacher realisieren.

Auch gibt es viele Special-Features wie z.B. einfach Werte von Readings in einen Befehl einzubauen usw.

Ich verwende auch mehr Notifies als DOIFs, da sie bei simplen Aufgaben sicher etwas weniger Overhead haben.
Aber dort wo ich DOIF verwende bin ich normal sehr froh darüber...

Die Ausmaße der Commandred von DOIF zeigen einem ja schon, dass das Ding eine Art Schweizer Taschenmesser für die kleineren Automatisierungsaufgaben ist. ;)

Meine Vermutung: der Name ist leicht verständlich: "Mache, wenn...". Darauf bin ich auch erst mal "reingefallen".

An sich finde ich aber zwischenzeitlich oft ein notify (uU. mit alternativen Bedingungen und iVm. einem IF) viel übersichtlicher, Zeitabhängigkeiten kann man dann mit "defmod"-Definitionen und disable-Zeiten lösen.

M.E. wäre es sinnvoll, Anfängern erst mal diese Grundlagen zu erklären, bevor man sie auf DOIF mit seinen vielen (...) Optionen losläßt. Dann würde der eine oder andere vielleicht auch eher programmiertechnisches Verständnis entwickeln.

was mich an DOIF & Co. am meisten stört, ist die Tatsache, dass die Syntax der Klammernverwendung einfach komplett allem widerspricht, was zu FHEM und perl gehört.
Für mich gehören in perl eckige Klammern zu einem Array, geschweifte Klammern zu einem Hash.
Und in FHEM gibts maximal geschweifte Klammern, um perl Code zu kennzeichnen. Basta.

Zitat von: Beta-User am 10 Februar 2017, 15:01:46
M.E. wäre es sinnvoll, Anfängern erst mal diese Grundlagen zu erklären, bevor man sie auf DOIF mit seinen vielen (...) Optionen losläßt.

*unterschreib*

DOIF verhindert gerade bei Anfängern, das Verständnis für die grundlegenden Funktionsprinzipien von FHEM zu erlernen und anzuwenden. Und wenn man dieses Grundverständnis einmal hat, braucht man DOIF ohnehin nicht mehr.

So sehe ich das auch. Der Support fällt zudem auch nicht leicht, wenn die Leute auf Teufel komm raus DOIF verwenden möchten obwohl manche Ding sicher anders einfacher zu lösen wären. Ich bin zwar der Meinung, dass ich DOIF verstanden habe, trotzdem kommt mir tatsächlich bei keiner Problemstellung der Gedanke "das würde ich mit einem DOIF lösen".

@marvin78
Geht sogar mir schon so...

Noch was fällt mir dazu ein:

Im Einsteigerdokument werden relativ wenige Module erklärt, darunter aber eben auch DOIF! Das wirkt so, als müsse man das kennen und verwenden.

So gesehen sollte man überlegen, ob der Teil nicht raus sollte (ich würde dann auch noch FLOORPLAN vorschlagen, ob das Fritten-Modul drin ist, wäre ggf. zu klären). Das war im Nachhinein jeweils völlig nutzloser Aufwand... (Persönliche Meinung, und v.a. keine Generalkritik an diesem ansonsten wirklich hilfreichen Dokument!)

Zitat von: igami am 10 Februar 2017, 14:50:34
Ich nutze DOIF dann, wenn ich mehr als eine Bedingung habe.

Genau so handhabe ich es auch.

Ist das Vorhaben mit einem DOIF Einzeiler abgefrühstückt oder möchte ich nur auf einen bestimmten Wert eines Readings reagieren, nehme ich DOIF:
Ist die Sonne Untergegangen und ich bin daheim? => Mach das Licht an, ansonsten schließe die Rollos!
Ist die CPU Temperatur > 90°C => Ruf die Feuerwehr!

Brauche ich vielleicht mehrere Abfragen/if-elseifs-else/etc. oder weitere extra definierte Variablen, oder wird das Define allgemein etwas größer, dann verwende ich strukturierte at oder notifies.

Klar gingen die obigen zwei Beispiele auch per notify - aber nicht so kurz und knapp, wie mit einem DOIF.

Gerade das Beispiel in der Commandref mit dem Zufallsverzögerten An- und Abschalten einer Lampe nach Sonnenuntergang und einer definierten Uhrzeit zeigt in meinen Augen, wie mächtig und kompakt DOIF sein kann.

Hi,

also mal ohne auf die einzelnen Postings einzugehen: DOIF eignet sich für einen bestimmten Komplexitätsgrad, aber eigentlich nicht wirklich für Anfänger. Wenn man aber mal notify und at verstanden hat, dann kann man bestimmte Dinge ggf. schöner mit DOIF erledigen.
Ich wäre auch dafür, DOIF aus allen Anfänger-Dokus rauszunehmen. Ich wundere mich, dass es überhaupt drinsteht.

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

Gruß,
   Thorsten 

Hallo Thorsten,

wenn man schon mal ein Basic Programm gesehen hat oder ein Regel basiertes IFTTT - versteht man dann zwangsläufig notify? Mir war das am Anfang ziemlich suspekt. Und irgendwas muss man doch machen am Anfang - FHEM ist leer nach der Installation! at kann zwar einfach mal eine Lampe anmachen, aber eine Zusatzbedingung - uih wie geht das denn?
Da ist DOIF schon relativ einfach zu verstehen.
Und Perl Programme in die 99_myUtils schreiben will am Anfang auch keiner.  ::)

Mittlerweile ist für mich notify einfacher und man weiß wenigsten was passiert. Und ich bin völlig bei betateilchen, die unterschiedliche Verwendung von Klammern Semikolons Kommas usw. geht mir irgendwann auf den Geist.

Ich weiß, Du akzeptierst mich wahrscheinlich auch nicht als Anfänger  8)

Gruß Otto

Naja, ich denke ich bin noch ein Anfänger ::)

Ich benutze sowohl at, notify als auch DOIF.
DOIF fande ich am Anfang schon recht Schwer! Aber nach einigen Beispielen und Versuchen war es dann verständlich und die Syntax mir bekannt.

Das Problem mit den Klammern und Anführungszeichen im Modul habe ich nicht, da ich leider keine perl Kenntnisse habe;D Ich denke das stört Anfänger recht wenig ;)

Prinzipiell sollte man Anfängern erstmal das notify und at für den einfachen Gebrauch ans Herz legen, und anschließend bei Komplexeren Dingen mit mehreren Bedingungen und co. DOIF nutzen.

Also ich bezeichne mich selber schon noch als Anfänger und ich benutze alle drei (DOIF, notiy, at) in folgender Reihenfolge:
1. ein Device zu einer bestimmten Zeit schalten: at
2. auf ein Event reagieren und ein Device schalten: notify
3. mehrere Events und Bedingungen, auf die verschieden reagiert werden soll: DOIF

Ich finde grundsätzlich den DOIF um einiges leichter als notify, wenn es um mehrfach Bedingungen/Events geht.
Auch kennt man (bzw. ich), das ganze aus Apps wie IFTTT.
Auch ist mir die Logik noch aus den guten alten Basic Zeiten DO IF und ELSE bekannt.

Ich muss zugeben, ich bin ein Fan von DOIF und mir persönlich hat es schon einiges ziemlich erleichtert.
Die Klammern machen mir keine Probleme. Ich weiß ja, wann ich welche und wie nutzen muss  ;)

DOIF ist schon wirklich mächtig, aber alleine das der Status nach einem Neustart erhalten bleibt, ist ein ungeheurer Vorteil gegen notify & Co.
Ich finde, jeder sollte das nutzen, was ihm am meisten liegt.

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

ZitatMan liest ständig, dass Leute mit DOIF rumprobieren.

Kann ich nicht bestätigen, es gibt täglich nur wenige neue Fragen, die im Unterforum gestellt werden.

ZitatWarum ist DOIF so beliebt?

DOIF besitzt at und notify Funktionalität. Es stehen mit Stand 10.02.2017 17030 genutzte notify-Module und 9416 at-Module nur 2517 genutzte DOIF-Module gegenüber.
Der DOIF-Anteil beträgt gerade mal 8,7% der betrachteten Module.

Die Betrachtung der Definitionen zeigt ein ähnliches Bild. 224405 notify-Definitionen und 101710 at-Definitionen und nur 36300 DOIF-Definitionen.

Hier liegt der DOIF-Anteil bei 10%.

DOIF ist offensichtlich doch nicht so beliebt, wie die Fragestellung suggeriert.

Zitat von: Ellert am 10 Februar 2017, 18:58:37
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

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

Zitat von: Thorsten Pferdekaemper am 10 Februar 2017, 19:05:17
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.

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.

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:

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:

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

Naja, ich verstehe Thorsten.
das

Zitat[gerätename:readingname]

ist weder perl noch FHEM. Das

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

schon.
und auch das

Zitat[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 ?

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

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.

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

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

ZitatKlar, 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  :(

Zitat von: KölnSolar am 10 Februar 2017, 20:38:31
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:

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

aus der Commandref:

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

Zitat[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:

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

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

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

ZitatWarum ist etwas weniger geeignet,

hab ich auch nicht gesagt, sondern

Zitatfür Einsteiger weniger geeignet

was komplexer impliziert.

Zitatdass 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  :o

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

ziehe ich zurück. Mal wieder was gelernt  :D 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  ;D

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 ?

Zitat von: Mitch am 10 Februar 2017, 21:19:24Klar, man lernt damit kein Perl.

Hier sind die DEFs von ein paar meiner notifys:

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

Zitat von: Thorsten Pferdekaemper am 10 Februar 2017, 23:05:48
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:

ZitatInsgesamt 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 ;)

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  :o
Ach egal, posten eben alle wo es grad schön ist.

Jetzt traue ich mich fast nicht mehr dranhängen...

...aber ich tu's trotzdem mal.

Also ich mache auch viel (fast ausschließlich) mit notify (und ein wenig at).

Ich rufe fast ausschließlich subs in myUtils auf wo ich dann alles mögliche prüfe tue abfrage etc.

Ein paar von den einfacheren Dingen wären sicher gut für ein DOIF...
...aber ich finde die Variante mit notify und sub übersichtlicher...
...gut das ist "privat"...

Jetzt aber ein Frage die mich schon länger interessiert:

was ist nun "performanter" bzw. weniger systembelastend?

Ein notify und sub (gut da ist dann wohl hauptsächlich das was in der sub gemacht wird) ODER ein DOIF was im Prinzip nat. dasselbe macht (machen soll, also wohl vgl.bar mit dem was in der Sub getan wird/werden muss, beispielsweise ReadingsVals etc.)???

DANKE, Joachim

Nun gebe ich auch noch kurz und knapp meinen Senf dazu:
Als ich mit FHEM angefangen habe, hatte ich keine Ahnung von Perl und habe mich mit at und notify und dummies und watchdogs rumgeschlagen... Mittlerweile kann ich (einigermaßen) Perl und verwende DOIF.

Warum? Weil ich persönlich es übersichtlicher und flexibler finde ein "DOIF" zu definieren, das mir um 17:00 Uhr ein Licht einschaltet als ein "at". Wenn ich mir irgendwann überlege, dass das Licht nur eingeschaltet werden soll, wenn ich zu Hause bin und 10 Minuten später die Musik angemacht werden soll und wenn die Sonne scheint die Markise heruntergelassen werden soll (aber nicht wenn es länger als 5 Minuten regnet) dann stoße ich beim "at" ziemlich schnell an Grenzen und baue notifies und watchdogs... oder ich erweitere mein DOIF.

Ich würde weder den einen noch den anderen Weg als richtig bezeichnen, Ich habe für mich aber entschieden, nur noch DOIF zu verwenden. Ob das jetzt Perl ist oder nicht, ist mir egal. Ich springe ohnehin die ganze Zeit zwischen Perl, PHP, Java, Javascript, SQL, ABAP,.... da macht eine weitere "Programmiersprache" auch nix mehr...

Zitat von: Damian am 10 Februar 2017, 23:30:09Es wundert mich, dass du IF benutzt.

Warum wundert Dich das? Ich selbst würde vielleicht auch DOIF verwenden. Ich bin nur momentan zu faul, das auch noch zu lernen.

ZitatWarum ich DOIF programmiert habe? Ganz kurz:

Das ist mir schon alles klar, aber darum ging es mir gar nicht.

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

Wie kommt das denn?  ;)

Zitat von: Puschel74 am 10 Februar 2017, 23:39:29
Die Frage würde eigentlich unter Off-Topic perfekt passen.

Ich habe das deswegen hier gepostet, weil ich die Hoffnung hatte, dass sich auch mal ein paar echte Anfänger dazu melden. Ich hatte auf eine Antwort gehofft wie "ich habe es mit DOIF versucht, weil es im YouTube-Video xyz/ der Doku ABC/ etc." erklärt wird. Dann hätte man darauf vielleicht besser eingehen können.
Ich wollte eigentlich gar keine Diskussion über Sinn und Unsinn des DOIF führen, schon gar nicht für die etwas erfahreneren.

Gruß,
   Thorsten

Es geht doch bei diesen vielen kleinen Helfern gar nicht darum, Perl zu lernen. Es geht darum, dass man seine Ideen in Sachen Hausautomation umgesetzt bekommt. Auch wenn DOIF sich immer weiter entwickelt ist ein erfahrener Anwender mit ein paar ats und notifys und dann etwas Perl in einer myUtils sicher deutlich flexibler. Leider schließen sich tatsächlich beide Welten, aus den Gründen, die betateilchen erwähnt, etwas aus. Das macht aber nichts. Wenn man es ganz auf die Spitze treiben möchte, kommt man in FHEM sogar ohne notify und at aus und bekommt trotzdem alles umgesetzt. Ich bin der Meinung FHEM braucht DOIF nicht unbedingt. Aber es schadet auch nicht, wenn es da ist und viele es verwenden (zumindest nicht direkt - langfristig wird man sehen, was passiert, denn Support ist wichtig für FHEM und da sehe ich schon kleinere Probleme).

Perl lernen ist sicher wichtig, um mit FHEM sehr weit zu kommen und es ist sehr ratsam, dass man sich darum ein wenig bemüht. Aber ob man nun DOIF oder anderes einsetzt ist egal.

Ich habe für mich entscheiden, dass ich niemanden mit einem DOIF weiter helfe. Das ist vermutlich auch ok so. Wenn ich mal irgendwann bei einer Problemstellung denken sollte: Ah, dafür ist ein DOIF perfekt, werde ich es sicher auch selbst einsetzen. Aktuell ist das nicht der Fall.

Ach und was die Doku von DOIF angeht: Das habe ich schon an mehreren Stellen gesagt: Ich finde sie nicht herausragend, wenn man sie mit der Doku anderer Module vergleicht. Ein komplexes Modul benötigt eine lange Doku. Das heißt aber nicht, dass die Doku zu notiy, at oder anderen Helfern schlechter wäre. Die Doku zu den Standard-Modulen ist mindestens genau so gut und vollständig, wie die DOIF Doku.

Hallo zusammen,

ich habe vor dem Einsatz von FHEM ein paar CGI-Skripte in Perl geschrieben, davon abgesehen ist meine Historie die eines Software-Entwicklers.

Ich habe für FHEM den Grundsatz, dass ich möglichst wenig Perl schreiben möchte, daher versuche ich die Steuerungslogik möglichst mit den vorhandenen Typen zu lösen.

Ich habe da mit "at" angefangen, mit "notify" weitergemacht. "watchdog" war schon vom Namen genau passend für die Überwachung von z.B. geöffnete Fenstern.

"DOIF" hat mich tatsächlich abgeschreckt, weil es für mich irgendwie nicht eingängig ist. Ich habe noch einmal nachgeguckt: Ich benutze "DOIF" da wo es sich tatsächlich auf die dem Namen entsprechende Funktion beschränkt, z.B. für die Fußbodenheizung:

define GWc.DOIF.Heiz DOIF ([Heizungssteuerung] eq "on" and [GWc.WandTherm.Weather:temperature] < [GWc.WandTherm.Climate:desired-temp]) \
(set GWc.HeizVentil2 on)\
DOELSE\
(set GWc.HeizVentil2 off)


Außerdem noch für einfache Zeitsteuerungen (von bis), wobei ich wegen der Diskussion gerade noch einmal nachgelesen und entdeckt habe, das "watchdog" mit . für regexp1 wohl das gleiche leistet.

Es ist für mich irgendwie abschreckend, das ich für ein Konstrukt, dass "DOIF" heißt soviele den Ablauf beeinflussende Einstellungen machen kann bzw. für bestimmte Abläufe machen muss. Mein Bild ist, dass sich da dann etwas versteckt, dass man bei dem auch aufwendigen Zusammenbau mit notify, watchdog und dummy deutlicher sehen kann. Ein Beispiel ist für mich die Diskussion zu endlichen Automaten mit DOIF. Ich finden einen endlichen Automaten mit einem "dummy" für die Zustände und Zusandsübergängen über "notify" viel eingängiger. Für das Verständnis eines Steuerungssystem ist die möglichst klare Trennung zwischen Ereignis, Ereigniserkennung und Aktion meines Erachtens nach hilfreich. Wenn man in der Aktion verzweigen will, kann man ja auch "IF" nehmen.

Insgesamt entdecke ich nach einem Jahr noch immer neues, letzte Woche gerade "structure", um aus einem Doppelrelay eine Ansteuerung für ein Dachfenster zu bauen.

Es gibt viel Dokumentation, allerdings muss man sowohl im Wiki (manchmal ausführlich, manchmal ruidimentär) als auch in der commandref nachlesen. In der commandref manchmal zwichen DE und EN umschalten. Ich ergänze im Wiki gelegentlich, wenn ich den Eindruck habe, dass man dadurch die zusätzliche Suche im Forum sparen kann.

Am anstrengendsten finde ich die syntaktischen Feinheiten, die nicht präzise genug beschrieben sind:
Zeilenumbrüche, mehrzeilige DEFs, Trennungen zwischen zwei Befehlen mit Komma oder Semikolon oder auch mal zwei davon, ...

Bevor sich das zu negativ anhört: Ich habe großen Respekt vor allen, die für das System Module entwickeln und diese für die Allgemeinheit zur Verfügung stellen. FHEM ist mächtig. Ich kann wahlweise Homematic und ZWAVE benutzen und kombinieren. Die Anpassungsmöglichkeiten sind sehr gut, zu guter Letzt kann man eben Perl schreiben.

Herzliche Grüße
Lars

Zitatda sehe ich schon kleinere Probleme

@marvin78
Werde doch mal konkret und benenne die Probleme.

Es kann und will nicht jeder DOIF supporten (verständlicherweise - alles geht auch anders). Es ist nicht immer leicht, sich in komplexe DOIFs reinzudenken und jeden kleinen Klammerfehler zu finden (da sehe ich das größte Potential für Fehler). Bis man mal ein komplettes list bekommt, vergehen oft 5 Beiträge (gut, das Problem gibt es hier eigentlich immer). Die gleichen Probleme hast du auch bei Support von z.B. Perl Code. Hier sehe ich bloß mehr Potential bei der Anzahl der möglichen Helfer.

Nimm es nicht als Kritik an deinem geliebten DOIF (ich sehe hier schon, dass du da sehr auf Krawall gebürstet bist). Ich sehe an der Stelle nur Potential für Probleme, die dann auch FHEM als ganzes betreffen könnten. Ob es wirklich so ist, sei dahin gestellt. Im Grunde ist es mir ehrlich egal, wer was wie macht. Die Hauptsache ist, dass man sich selbst mit den Dingen beschäftigt und nicht andere die individuellen DOIFs oder sonstiges bauen lässt.

Ach und ich war shon an vielen Stellen zu dem Thema konkret. Man muss nicht alles immer und immer wieder wiederholen.

Zitat von: marvin78 am 11 Februar 2017, 12:07:21
... und jeden kleinen Klammerfehler zu finden (da sehe ich das größte Potential für Fehler)

Das sehe ich genau anders. Der größte Nachteil im FHEM-Teil ist die fehlende Klammerhierarchie. Nicht umsonst kann jede höhere Programmiersprache, die sich in der Softwareentwicklung durchgesetzt hat, mit Klammern umgehen. Und auch in der Grundschule haben wir im Mathematikunterricht Klammern benutzt - warum wohl.

Einfaches Beispiel: ich möchte im notify ein at definieren, welches zwei Befehle ausführt.

Ich bin mir sicher, dass die meisten nicht wissen mit wie viel Semikolons sie in der Kommandozeile die beiden Befehle trennen müssen, wenn sie es nicht durch probieren herausgefunden haben.

Und dieses Beispiel ist keines Falls so kompliziert, dass man es in Perl auslagern müsste.

Zitat von: marvin78 am 11 Februar 2017, 12:07:21
Es kann und will nicht jeder DOIF supporten (verständlicherweise - alles geht auch anders). Es ist nicht immer leicht, sich in komplexe DOIFs reinzudenken und jeden kleinen Klammerfehler zu finden (da sehe ich das größte Potential für Fehler). Bis man mal ein komplettes list bekommt, vergehen oft 5 Beiträge (gut, das Problem gibt es hier eigentlich immer). Die gleichen Probleme hast du auch bei Support von z.B. Perl Code. Hier sehe ich bloß mehr Potential bei der Anzahl der möglichen Helfer.

Nimm es nicht als Kritik an deinem geliebten DOIF (ich sehe hier schon, dass du da sehr auf Krawall gebürstet bist). Ich sehe an der Stelle nur Potential für Probleme, die dann auch FHEM als ganzes betreffen könnten. Ob es wirklich so ist, sei dahin gestellt. Im Grunde ist es mir ehrlich egal, wer was wie macht. Die Hauptsache ist, dass man sich selbst mit den Dingen beschäftigt und nicht andere die individuellen DOIFs oder sonstiges bauen lässt.

Ach und ich war shon an vielen Stellen zu dem Thema konkret. Man muss nicht alles immer und immer wieder wiederholen.

Danke für die Präzisierung, der von Dir gesehenen Probleme. Mir hätte natürlich auch ein Link auf eine der wiederholten Aussagen gereicht.

Die Zahl der möglichen Helfer, wird sicherlich mit der Zahl der Nutzer steigen, wenn wirklich "jeder DOIF verwendet" und nicht nur 10%.

Ich denke, wenn man eine funktionierende (auch individuelle Lösung) vorlegt, wird eine gute Grundlage gelegt, da der interressierte Nutzer sich Fragen stellen wird. Warum funktioniert es so? Was habe ich in der Befehlsreferenz übersehen? Was muss ich ändern, um ähnliche Probleme damit lösen?

Ich weiß überhaupt nicht was diese Diskussion hier soll. Gerade die eigentlich gute Stimmung und die Hilfsbereitschft mag ich an diesem Forum. Dieser ganze Thread ist doch nur da, um Krawall zu stiften. Es macht doch keinen Sinn, irgendwelche Module zu vergleichen. Geschmäcker sind unterschiedlich und der Erfahrungsschatz auch.
Ellert ist sicherlich nicht auf Krawall gebürstet. Er kämpft hier quasi gegen Windmühlen.
Ich mag DOIF und will es nicht mehr missen. Aber deswegen finde ich doch alles andere nicht doof. Jeder so wie er will.

Ich finde das total unfair aufs DOIF und damit quasi auf Damians Idee rumzuprügeln oder ihm die kalte Schulter zu zeigen. Falls ich kann, so supporte ich überall. Egal ob ich das Modul mag oder nicht.

Total überflüssige Diskussion.

Ich habe als Anfänger ohne Perl-Kenntnisse und ohne Reg-Ex Kenntnisse mit FHEM angefangen. Mit at und notify habe ich experimentiert, aber schnell DOIF gefunden. Die Syntax von DOIF war für mich einfach und logisch. Ich konnte mit DOIF die Automatisierung schneller und erfolgreicher umsetzen als bei meinen Versuchen mit at und notify. Dabei haben mir die gute DOIF-Doku und die vielen Threads im Unterforum sehr geholfen.

In die DOIF Syntax musste ich mich einarbeiten, aber das hätte ich bei Perl, at und notify ebenso machen müssen. Inzwischen habe ich alle meine Automatisierungs-Aufgaben ohne Perl-Code, ohne notify und ohne at fast ausschließlich mit DOIF umgesetzt. So muss ich nur ein Modul kennen und mich nur in eine Syntax einarbeiten. Ob die DOIF Syntax zu Perl passt oder nicht ist mir dabei egal (weil ich Perl nicht nutze). Da das DOIF Modul stetig weiterentwickelt wird, kann ich inzwischen auch komplexe Aufgaben von DOIF erledigen lassen (komplett ohne Perl). Wer das lieber anders löst, kann es natürlich auch gerne anders machen, aber ich weiß nicht warum man deshalb DOIF schlecht darstellen muss.

Daher kann ich DOIF jedem Anfänger, der noch keine Perl und RegEx Kenntnisse hat und auch wenig Ambitionen hat, sich diese anzueignen, wärmstens empfehlen. Gut, für komplexe Aufgaben kann ein wenig RegEx bei DOIF auch nicht schaden (Stichwort DOIF Generalisierung), aber anfangs geht es auch ohne RegEx. Deshalb sollte DOIF in keine Anfänger-HowTo fehlen.

Danke an Damian für dieses tolle Modul :-)

Ich würde grundsätzlich empfehlen bei Fragen auf das DOIF-Unterforum zu verweisen. Dort werden Fragen fachmännisch beantwortet bzw. Problemlösungen aufgezeigt. Vielleicht wird man dort zukünftig ein Anfängerforum einrichten müssen (zumindest zeigt das die überdurchschnittlich steigende Zahl an Anwender), bisher ist das aber nicht nötig.

Ich würde nicht empfehlen gut gemeinte Vorschläge zum Modul zu machen, wenn man es selbst nicht einsetzt. Oft steckt der Teufel im Detail, denn das Modul besitzt etwas mehr programmierte Logik als ein at bzw. notify - aber das dürfte inzwischen keinem entgangen zu sein.

Hallo


Ich binn sicher noch Anfänger.
Ich benutze DOIF weil es für mich Sehr gut erklärt ist.
Und es gibt viele Beispiele zum Testen und Lernen.

Ich benutze seit ungefähr einem Jahr FHEM und ich habe eben mal Statistiken gezogen:
16 definierte notifys, 38 definierte DOIFs und genau 0 ats (bei 3445 Zeilen fhem.cfg, 511 defines, 132 Zeilen 99_myUtils mit 5 Subroutinen).

notifys benutze ich vor allem dann, wenn ich sehr einfache Sachen realisieren möchte; DOIF in jedem anderen Fall.

Ich möchte meine Definitionen gerne möglichst an einer Stelle pflegen, deshalb greife ich lieber auf die fhem.cfg mit DOIF zurück, als eigene Subroutinen in die 99_myUtils zu schreiben, die dich dann über notify/at/* aufrufe. Alle fünf Subroutinen formatieren State-Angaben.

Für den Hintergrund: Ich verdiene seit über 20 Jahren mein Geld mit Softwareentwicklung u.a. in Perl; habe also keine Hemmungen, Perl-Code zu schreiben.

Zitat von: FunkOdyssey am 11 Februar 2017, 13:15:37Dieser ganze Thread ist doch nur da, um Krawall zu stiften.

Nein, das war wirklich nicht meine Intention. Sorry, wenn das jetzt zum Glaubenskrieg ausarten sollte. Ich wollte wirklich ganz ehrlich wissen, warum Anfänger (gefühlt für mich) oft auf DOIF zurückgreifen. Mir war das wirklich nicht klar. Das soll auch gar keine Bewertung sein. Ganz, ganz ehrlich nicht.

Zitat von: Damian am 11 Februar 2017, 13:24:57
Ich würde grundsätzlich empfehlen bei Fragen auf das DOIF-Unterforum zu verweisen.

Ich denke, dass ich das hier im Anfängerforum in Zukunft tatsächlich etwas schneller tun werde, außer mir drängt sich sowieso eine notify/at-Antwort auf.
Ich glaube aber nicht, dass man deswegen im DOIF-Bereich einen eigenen Anfängerbereich einrichten muss. Mit steigender Anwenderzahl dürfte auch die Anzahl derer steigen, die Anfängerfragen dazu beantworten können.

Zitat
Ich würde nicht empfehlen gut gemeinte Vorschläge zum Modul zu machen, wenn man es selbst nicht einsetzt.

Deswegen halte ich mich da auch stark zurück.

Vielen Dank, Damian, für Deine differenzierten Antworten. Ich hoffe sehr, Du fühlst Dich durch mich nicht angegriffen. Falls doch, dann tut mir das leid und wir sollten das irgendwie aus dem Weg räumen.

Gruß,
   Thorsten

Zitat von: Thorsten Pferdekaemper am 11 Februar 2017, 14:32:07
Vielen Dank, Damian, für Deine differenzierten Antworten. Ich hoffe sehr, Du fühlst Dich durch mich nicht angegriffen. Falls doch, dann tut mir das leid und wir sollten das irgendwie aus dem Weg räumen.

Ehrlich gesagt, habe ich nichts anderes erwartet. Es ist ja nicht die erste Diskussion zu diesem Thema. Ich bin schon länger im Forum unterwegs und kenne inzwischen die meisten  "Power"-User und deren Sichtweisen, daher überraschen mich deren Antworten nicht.

Genauso wie ich mir im aller ersten Post zum Modul https://forum.fhem.de/index.php/topic,23833.msg170608.html#msg170608 sicher über eine rege Diskussion war, bin ich mir jetzt sicher, dass wir uns noch öfters über dieses Modul "austauschen" werden, denn das Modul entwickelt sich weiter und nachdem ats und notifys mit dem Modul überflüssig wurden, werden mit den neuen Möglichkeiten der Websteuerung im DOIF auch zahlreiche Dummys wegfallen.

Naja, vielleicht brauchen wir tatsächlich bald eine Anfänger-Doku zu diesem Modul, denn die Grundidee des Moduls wird durch die vielen Features und die immer länger werdende Dokumentation immer mehr verschleiert.

Auch wenn die User einen komplexen endlichen Automaten mit dem Modul bauen wollen - ich werde sie daran nicht hindern - die ursprüngliche Intention war am Anfang zumindest eine andere.

Ich nutze diesen Thread um DOIF-Fans und die es werden wollen über die gerade eingecheckte neue DOIF-Version zu informieren.

Auszug aus der neuen Commandref:

Anwendungsbeispiel: Schaltbare Lampe über Fernbedienung und Webinterface

define di_lamp DOIF ([FB:"on"]) (set lamp on) DOELSEIF ([FB:"off"]) (set lamp off)
attr di_lamp cmdState on|off
attr di_lamp devStateIcon on:on:cmd_2 initialized|off:off:cmd_1

Mit der Definition des Standart-FHEM-Attributs devStateIcon führt das Anklicken des on/off-Lampen-Icons zum Ausführen des set-Kommandos cmd_1 bzw. cmd_2 und damit zum Schalten der Lampe.

Selbstverständlich lässt sich der einfacher Anwendungsfall lediglich über ein notify, eine Perl-if-Abfrage und einen Dummy realisieren. Zusätzlich würde ich die Perl-if-Abfrage in myUtils auslagern, weil man dort direkt auf Syntaxfehler hingewiesen wird und nicht vergessen die set-Kommandos zum Schalten der Lampe in den Funktionsaufruf fhem("...") zu verpacken, naja so lernt man wenigsten Nebenbei bisschen Perl

oder man benutzt DOIF, allerdings weiß man dann nicht genau, was intern passiert, tja damit muss man dann wohl leben ;)

In diesem Sinne, viel Spaß beim Ausprobieren der neuen Version, ab morgen per Update verfügbar :)

Gruß

Damian

 8)

Zitat von: vbs am 11 Februar 2017, 19:13:40
8)

Das dachte ich eben beim Lesen auch..  ;D

Zitat von: vbs am 11 Februar 2017, 19:13:40
8)

Einen habe ich noch:

Leider wird sich die Anzahl der blöden Klammern durch die Verwendung des Perl-if-Befehls nicht verringern, sondern erhöhen, denn die ReadingVal-Abfrage, der if-Befehl und der fhem-Befehl brauchen ja auch welche - Mist. Ok beim fhem-Befehl könnte man sie ja weglassen, aber wir wollen den Anfängern keinen schlechten Programmierstil beibringen. Immerhin sieht man die Klammern in der fhem.cfg nicht, weil sie dann ja ausgelagert sind. Puh, noch mal alles gut gegangen ;)

Doif ist einfacher als if,else. Die ganzen geschweiften Klammern machen einen wuggi. Und nichts ist einfacher als tu wenn zu denken

Gesendet von meinem ONEPLUS A3003

Hallo,

hätte es DOIF zu meine FHEM anfangszeit nicht gegeben wäre ich jetzt nicht mehr dabei.

War leicht und schnell zu lernen, dazu eine super Doku mit viele Beispiele.Es gibt nichts was ich, für mich ,nicht mit DOIF bauen kann und das reicht mir.
Im DOIF-Unterforum wird auch schnell geholfen und nicht immer auf die SuFu hingewiesen.

Ich verstehe die Diskussion hier auch nicht,mir scheint als währen hier einige neidisch auf das was Damian geschafft hat.

Danke an Damian für dieses tolle Modul.

Claudiu

Zitatmir scheint als währen hier einige neidisch auf das was Damian geschafft hat.

Nicht immer :) Ich muss wg. DOIF mehr Support leisten, weil DOIF seine eigene Syntax schafft, und Leute bei den ueberall verfuegbaren Perl evals mit DOIF Syntax auf die Nase fallen. Statt lange Doku zu lesen experimentiert man halt mit copy&paste herum, und wenn es nicht tut, dann fragt man im Forum, und wenn es einen meiner Module trifft, dann bin ich halt dran. Eigentlich duerfte man IF und DOIF erst dann verwenden, wenn man verstanden hat, dass das jeweils Module mit eigener Syntax sind, und nicht perl.

(da wir jetzt komplett Off-Topic geworden sind, sorry Thorsten)
Irgendwie muesste man Damian dazu bringen, dass er fuer DOIF ein grafisches Frontend baut, wo man DOIF per Drag & Drop konfiguriert, und den eigentlichen DOIF Syntax nicht sieht. Damit waere dem Anfaenger / Ungeduldigen / Lernunwilligen :) geholfen, und die, die eine Programmiersprache verwenden wollen, wuerden nicht mit komischen Fragen genervt.

Habe Aufklappmenues auf einfache DOIFs umgestellt.
Zuvor war ein dummy plus ein notify erforderlich.

Andere Meinungen zu etwas zu haben, heißt nicht, dass man jemanden angreift oder gar die Arbeit von bspw. Damian nicht zu schätzen weiß bzw. sich bewusst ist, dass da viele gute Arbeit drin steckt. Wenn man aber über Dinge, wie DOIF diskutiert, kann es nicht immer nur heißen: "alles toll, es sollte nur noch DOIF geben". Man muss auch einfach mal andere Meinungen akzeptieren ohne dahinter gleich einen persönlichen Angriff zu vermuten (@Damian, damit bist du nicht persönlich gemeint). FHEM lebt genau davon, dass viele Wege nach Rom führen.

Ich vergleiche das ganze mal (auch wenn der Vergleich leicht hinkt) mit Einführung der Ribbons bei MS Office: Leute, die vorher sehr lange Office eingesetzt haben, fanden sich plötzlich nicht mehr zurecht und mussten alles lange suchen. Leute, die erst mit der neuen Office Version eingestiegen sind, taten sich oft leichter, als diejenigen, die vor Jahren mit der alten Menüform eingestiegen sind.

Solche unterschiedliche Meinungen können aus persönlichen Vorlieben, Gewöhnung und auch Erfahrungen entstehen. Solchen Meinungen darf man auch Ausdruck verleihen, ohne dass gleich irgendein seltsamer Hintergrund oder gar Neid vermutet wird.

Ich glaube kaum, dass Damian hinten rum gehoben werden muss, um weiter an DOIF dran zu bleiben.

Zitat von: rudolfkoenig am 11 Februar 2017, 20:37:24
Nicht immer :) Ich muss wg. DOIF mehr Support leisten, weil DOIF seine eigene Syntax schafft, und Leute bei den ueberall verfuegbaren Perl evals mit DOIF Syntax auf die Nase fallen. Statt lange Doku zu lesen experimentiert man halt mit copy&paste herum, und wenn es nicht tut, dann fragt man im Forum, und wenn es einen meiner Module trifft, dann bin ich halt dran. Eigentlich duerfte man IF und DOIF erst dann verwenden, wenn man verstanden hat, dass das jeweils Module mit eigener Syntax sind, und nicht perl.

ja, das Problem wirst du oder wir alle immer stärker haben. Denn in fünf Jahren wirst du noch viel mehr Module haben und jedes Modul wird seine eigene Syntax verwenden, da es keine Syntaxvorgaben gibt. Damit werden User noch mehr durcheinander werfen.

Mehr als:

Zitat aus der Commandref zu DOIF:

ZitatAn dieser Stelle setzt das Modul DOIF an. Es stellt eine eigene Benutzer-Schnittstelle zur Verfügung ohne Programmierkenntnisse in Perl unmittelbar vorauszusetzen.

kann ich auch nicht schreiben.

Zitat
(da wir jetzt komplett Off-Topic geworden sind, sorry Thorsten)
Irgendwie muesste man Damian dazu bringen, dass er fuer DOIF ein grafisches Frontend baut, wo man DOIF per Drag & Drop konfiguriert, und den eigentlichen DOIF Syntax nicht sieht. Damit waere dem Anfaenger / Ungeduldigen / Lernunwilligen :) geholfen, und die, die eine Programmiersprache verwenden wollen, wuerden nicht mit komischen Fragen genervt.

ja, allerdings zweifle ich an der Umsetzung, denn es kommt der Anforderung nahe, baue eine Drap & Drop Oberfläche um Perl zu programmieren. Denn die Bedingungen beim DOIF ist erweitertes Perl. Das dürfte schon an der Umsetzung der Klammern-Hierarchie scheitern. Eine Klammer auf oder zu irgendwo hinzuschieben macht wohl wenig Sinn. Tabellarische Konzepte wie bei Access für SQL-Abfragen zwingen User logische Abfragen durch Umformung in eine bestimmte Struktur zu pressen - gefällt mir auch nicht.

Jeder, der programmieren kann, kann allerdings einen Oberflächenaufsatz für DOIF bauen, um vielleicht 90 % der Standardfälle abzudecken. Das so etwas möglich ist, zeigt eindrucksvoll das DOIFtool-Modul von Ellert, dafür ist FHEM offen genug  (oder nicht ausreichend abgeschottet) um auf alle Definitionen zuzugreifen. Das hätte auch den Vorteil, dass das Modul nicht noch weiter aufgebläht würde - es muss ja schließlich jedesmal erst in den Speicher geladen werden.

Hallo,

da ja nach der Anfängersicht gefragt, gebe ich auch mal meinen Senf dazu, auch wenn ich schon 2 bis 3 Jahre mit FHEM zugange bin, bin ich mir noch sicher überhaupt den Anfängerstatus schon erreicht zu haben.
Schlicht und ergreifend kommt einem das DOIF bekannt vor,und  wenn man aus der Zeit des KC87, C64, Archimedes RISC-PC  und mit nie wider gefundenen intuitiven Software wie SBase stammt.
Bin nach wie vor der Meinung eine Programmiersprache lernen ist ähnlich einer Fremdsprache lernen und da ist Perl für mich nicht so  intuitiv und DOIF eher das Schweizer Taschenmesser.
Dazu habe ich das "Gefühl" Probleme mit ein zwei DOIF gelöst zu bekommen anstatt 10 notify die Programmierer mögen mir dies nachsehen und bin froh über über die vielen Beispiele die zentral an einer Stelle liegen zum Modul DOIF, wogegen ich bei andern Modulen schon ganz schön kreuz und quer in der Weltgeschichte suchen muss.
Aber um Himmels Willen jetzt keinen Glaubenskrieg und möchte auch keinen auf den Schlips treten, ist doch schön wenn man viele Möglichkeiten zur Problemlösung hat
Wenn man Programmierung Informatik von der Picke auf gelernt hat bzw. Zeit zum Selbststudium hatte sieht die Welt vielleicht anders aus aber dies war wohl nicht die Frage ?

Gruß
Hans-Jürgen

Zitat von: Deckoffizier am 12 Februar 2017, 17:31:48
Dazu habe ich das "Gefühl" Probleme mit ein zwei DOIF gelöst zu bekommen anstatt 10 notify die Programmierer mögen mir dies nachsehen und bin froh über über die vielen Beispiele die zentral an einer Stelle liegen zum Modul DOIF, wogegen ich bei andern Modulen schon ganz schön kreuz und quer in der Weltgeschichte suchen muss.

Genau das ist die Intention, die hinter diesem Modul steckt, nicht mehr und nicht weniger.

Zitat
Wenn man Programmierung Informatik von der Picke auf gelernt hat bzw. Zeit zum Selbststudium hatte sieht die Welt vielleicht anders aus aber dies war wohl nicht die Frage ?

Ich habe Informatik studiert und kann mittlerweile auch Perl programmieren und benutze es trotzdem ;)

Zitat von: Mitch am 10 Februar 2017, 17:20:17
[...]
ich benutze alle drei (DOIF, notiy, at) in folgender Reihenfolge:
1. ein Device zu einer bestimmten Zeit schalten: at
2. auf ein Event reagieren und ein Device schalten: notify
3. mehrere Events und Bedingungen, auf die verschieden reagiert werden soll: DOIF
[...]

Das kann ich so unterschreiben. Natürlich lassen sich mehrere Events und Bedingungen auch über eine Kombi von notify und at lösen, aber dann habe ich ggf. mehrere Orte, an denen ich Stellschrauben drehen müsste. Im DOIF nur einen.

Viele Wege führen zur Lösung (allgemeingültig für die Informatik, gerade in FHEM besonders gültig) und Eleganz oder Effizienz liegen manchmal halt im Auge des Betrachters.

Ob DOIF jetzt besonders Einsteigerfreundlich oder -feindlich ist, kann ich nicht beurteilen (als ich anfing, gab es noch kein DOIF soweit ich mich erinnere), aber ich bin immer ein Freund in der Lernphase möglichst viel "zu Fuß" zu erledigen, als über Hilfsmodule. Die machen einem später das Leben leichter, sofern man die Konzepte verinnerlicht hat. Sonst führen sie eher zu wilden Fragestunden.

cheers,
kroemmel

Zitat von: kroemmel am 12 Februar 2017, 18:51:47
Das kann ich so unterschreiben. Natürlich lassen sich mehrere Events und Bedingungen auch über eine Kombi von notify und at lösen, aber dann habe ich ggf. mehrere Orte, an denen ich Stellschrauben drehen müsste. Im DOIF nur einen.

Viele Wege führen zur Lösung (allgemeingültig für die Informatik, gerade in FHEM besonders gültig) und Eleganz oder Effizienz liegen manchmal halt im Auge des Betrachters.

Ob DOIF jetzt besonders Einsteigerfreundlich oder -feindlich ist, kann ich nicht beurteilen (als ich anfing, gab es noch kein DOIF soweit ich mich erinnere), aber ich bin immer ein Freund in der Lernphase möglichst viel "zu Fuß" zu erledigen, als über Hilfsmodule. Die machen einem später das Leben leichter, sofern man die Konzepte verinnerlicht hat. Sonst führen sie eher zu wilden Fragestunden.

cheers,
kroemmel

Wenn man zuerst at und notify kennengelernt hat, dann ist diese Vorgehensweise sicherlich ok.

Auf der anderen Seite könnte man sagen, wenn ich im Falle 3. DOIF verwende und mir seine Syntax angeeignet habe, warum sollte ich dann drei verschiedene Module mit jeweils unterschiedlicher Syntax lernen bzw. benutzen. Die Performanceunterschiede zwischen den Modulen werden nicht messbar sein, weil DOIF die gleichen Routinen benutzt wie at oder notify. Und wenn ich eine Lampe einschalte, dann will ich sie meistens auch wieder ausschalten, warum sollte man das nicht in einem Modul tun. Den Fall, dass man eine Lampe einschaltet und nicht wieder ausschaltet wird es wohl kaum geben.

Dann möchte ich auch mal meinen Senf dazugeben...

ich bin ein "Anfänger"...

Heimautomatisierung ist für mich ein Hobby direkt neben "zig" anderen Dingen neben meinen Beruf als Systemadministrator.
Programmieren ist für mich persönlich nur ein... wie soll ich sagen... mittel zum Zweck und ich versuche es möglichst zu vermeiden.

FHEM mache ich nicht, weil ich PERL toll finde, sondern weil ich die Community mag.
Aber am Anfang war... (Fhem mach ich jetzt seit gut 2 Jahren) für mich nur at notify dummy und co machbar. Die Lust an Fhem sank stetig und ich experimentierte mit ioBroker, Openhab und Co rum...
Nichts davon war wirklich etwas für mich... bei dem einem war es die Community, bei dem anderen Java... und und und...

durch Zufall stolperte ich dann über DOIF...

und ich Danke Damian sehr dafür... denn ich kann mal eben schnell ein paar Bedingungen basteln die auch funktionierten... und die ich auch nachvollziehen kann...

Damit kam auch endlich wieder der Spass an FHEM zurück und auch wenn es komisch klingt... mittlerweile interessiere ich mich sogar für PERL.
Also genau der umgekehrte Fall...

Um es mal kurz zu machen :
DOIF ist für mich als Programmierhasser und FHEM-Neuling genau das richtige... Die Doku ist klasse und ich konnte damit fast 90% meiner Fälle abdecken... der Rest kommt wie immer aus diesem wirklich erstklassigem Forum...

Und wieder einmal ziehe ich meinen Hut vor all den Entwicklern und Hilfsbereiten Usern hier.

Gruß
Carsten

ZitatUnd wenn ich eine Lampe einschalte, dann will ich sie meistens auch wieder ausschalten, warum sollte man das nicht in einem Modul tun. Den Fall, dass man eine Lampe einschaltet und nicht wieder ausschaltet wird es wohl kaum geben.

stimmt vermutlich für die meisten Fälle. Das kann man dann aber auch mit at,notify und den set extensions lösen  ;)

ZitatViele Wege führen zur Lösung (allgemeingültig für die Informatik, gerade in FHEM besonders gültig) und Eleganz oder Effizienz liegen manchmal halt im Auge des Betrachters.

Ist aber eigentlich auch an der  ursprüngliche Fragestellung vorbei. Ich habe das mal versucht aus den unterschiedlichen konstruktiven Beiträgen so zusammenzufassen:

Eine automatisierte Aktion, ausgelöst durch ein Ereignis oder einen Zeitpunkt, ist durch ein notify bzw. at für Anfänger einfach umzusetzen/verstehen. Kann/Will man in Perl programmieren, dann können auch komplexere Aufgabenstellungen problemlos gelöst werden. Für Anwender, die die Programmierung scheuen, ist DOIF trotz dessen Komplexität besser/einfacher(der einzige Weg ?), weil intuitiver einsetzbar bei komplexen Aufgabenstellungen.

Ich hoffe auf konstruktive und nicht ideologische Kritik.....und schließe mich dem Schlusssatz von Carsten uneingeschränkt an.
Schönen Abend Markus

Zitat von: KölnSolar am 12 Februar 2017, 20:46:24
stimmt vermutlich für die meisten Fälle. Das kann man dann aber auch mit at,notify und den set extensions lösen  ;)

Ein einfaches Beispiel: Lampe einschalten um 8:00 und ausschalten um 10:00, wie machst du das mit set extensions?

Zitat
Eine automatisierte Aktion, ausgelöst durch ein Ereignis oder einen Zeitpunkt, ist durch ein notify bzw. at für Anfänger einfach umzusetzen/verstehen.

notify device:.on.* set bla on   gegenüber  DOIF ([device:"on"]) (set bla on)

wenn du die Anzahl der Klammern meinst, dann gebe ich dir Recht. Allerdings stolpern gerade Anfänger bereits am Punkt vor on beim notify. Jetzt wird bereits Zeit sich mit Regex zu beschäftigen.

at *08:00 set bla on   gegenüber DOIF ([08:00]) (set bla on)

hier muss ich gegenüber einem notify eine neue Syntax beim at lernen. Zusätzlich gibt es hier eine Stolperfalle: Stern, den die Anfänger gerne weglassen, zumindest sollte man in der Commandref nachlesen wozu dieser überhaupt gut ist.

DOIF Syntax haben sie inzwischen beim ersten Beispiel gelernt, jetzt müssen sie nur noch lernen, dass man Ereignisse durch Zeiten tauschen kann.

Ich habe schon viele komplexe Sachen gesehen, hier kann ich aber keine erkennen. Nur weil etwas mächtig ist, muss es nicht kompliziert sein, das wird hier oft in einen Topf geworfen.

Welche Syntax nun intuitiver ist, sollen an der Stelle Anfänger beurteilen. Und dass man mit DOIF genauso gut ausgelagerte Funktionen in myUtils aufrufen kann, brauche ich wohl nicht zu erwähnen.

Hallöchen,

ich versuche mal auf die Eingangsfrage zu antworten.

Vorweg:
Ich hatte einige dummy, at und notify Definitionen. If  Anweisungen in Perl waren mir zu umständlich.

Dummys hatte ich am Anfang recht schnell verstanden, aber als jemand der programmieren kann war mir ein notify immer sehr suspekt. Gut, irgendwann kam ich dann dahinter, dass es in Fhem Events gibt, auf die man ein notify auslöst.
at verstand ich als Anwender recht schnell, einfach eine Uhrzeit eingeben und los geht es.


Gesucht hatte ich Eingangs eigentlich nur eine Option eine IF Abfrage in FHEM einzubauen, aber keine einfache gefunden.  :(
Mittlerweile habe ich meine notify, at und dummy Definitionen in DOIF Definitionen überführt. Die liefen zwar auch nicht immer auf Anhieb, da die Syntax und das Thema mit den Attributen durchaus etwas verzwickt ist. Komplexer als mehrere dummys und notifys zu erzeugen ist das in meinen Augen auch nicht.


Für mich ist DOIF halt am ehesten verständlich, was passiert. Alle Bedingungen sind in der Definition enthalten. Die Readings finden sich gute Hinweise, welche Werte vorliegen und welche Bedingung wahr ist. Neue Anwender wollen vermutlich so vorgehen, wenn Temperatur hoch und Rolladen unten, dann Rolladen runter fahren.
Oder, wenn die Sonne aufgeht, dann fahre mal die Rolläden nacheinander hoch. 

Grüße Sidey

ZitatEin einfaches Beispiel: Lampe einschalten um 8:00 und ausschalten um 10:00, wie machst du das mit set extensions?

at 08:00:00 set Lampe on-for-timer 7200

ZitatAllerdings stolpern gerade Anfänger bereits am Punkt vor on beim notify. Jetzt wird bereits Zeit sich mit Regex zu beschäftigen.

Da geb ich Dir Recht. Aber muss ich mich damit nicht wohl oder übel sowieso wegen FileLog etc. auseinandersetzen ?

Zitathier muss ich gegenüber einem notify eine neue Syntax beim at lernen.

Jetzt übertreibst Du. hh:mm ist doch auch beim DOIF "neu" :-\ und der * ist für Wiederholungen. Das sind im DOIF die eckigen Klammern ? Dann auch neu.

ZitatIch habe schon viele komplexe Sachen gesehen, hier kann ich aber keine erkennen. Nur weil etwas mächtig ist, muss es nicht kompliziert sein, das wird hier oft in einen Topf geworfen.

Bin mir nicht sicher, ob ich Dich richtig verstanden hab. Du meinst Deine Beispiele ? Die sind natürlich nicht komplex. Aber der Anfänger wird erst einmal von der mächtigen Doku/Funktionsumfang  des DOIF "erschlagen". Und darin sehen ich und andere eben den Nachteil für den Anfänger.

ZitatWelche Syntax nun intuitiver ist, sollen an der Stelle Anfänger beurteilen.

Eben nicht. Genau darum ging es Thorsten doch. Wir haben quasi 2 (gute) Wege im Funktionsumfang. Und nun kommen die Anfänger mit einer Aufgabenstellung. Dem 1. antworte ich mit einem simplen at. Du dem 2. mit einem simplen DOIF. Und dann liest der 3. die beiden Lösungen und stellt uns die Frage, was er nun machen soll und was Lösung 1. u. 2. jeweils für Vor- u. Nachteile haben. Da wär es ja schöner, wenn wir zu DER einheitlichen Vorgehensweise, was die Hilfestellung anbelangt, kämen. Ist aber vielleicht zu idealistisch gedacht :-\

ZitatUnd dass man mit DOIF genauso gut ausgelagerte Funktionen in myUtils aufrufen kann, brauche ich wohl nicht zu erwähnen.

Da Du es aber machst, interpretier ich das mal als Reaktion auf mein "programmieren können/wollen". Das sollte aber nur die Meinungsäußerungen der DOIF-Befürworter wiederspiegeln, die ich so verstanden hatte. Nicht, dass das mit DOIF nicht ginge.

ZitatEin einfaches Beispiel: Lampe einschalten um 8:00 und ausschalten um 10:00, wie machst du das mit set extensions?

at 08:00 set Lampe on-till 10:00
So kryptisch finde ich das auch nicht. Und man hat 6 mal Klammer gespart.

@Rudolf: Sorry für meine nur zweitklassige Lösung  ;)

@ Sydey: Mir ging es in den Anfängen ähnlich.  ;D Hab dann auch kurz DOIF für mich entdeckt. Mittlerweile hatte ich mich aber so in Perl mit { ; " ' . * :D eingearbeitet, dass ich komplexere Aufgabenstellungen schnell umsetzen konnte und der Aufwand mich in DOIF einzulesen höher schien.

Du erwähnst, dass Dir events bzw. notify suspekt erschienen. Aus der betriebswirtschaftlichen IT kannte ich das auch nicht und tat mich entsprechend schwer. Nur, wie ich oben schon zu Regexp schrieb: Unser geliebtes FHEM baut auf Perl, RegExp, events... auf. Und das betrifft ja nicht nur den kleinen Teil der Automatisierung. Empfehlen wir Anfängern die Basis(zumindest Regexp,events) zu lernen oder die Basis mit Tools wie DOIF zu umgehen, weil intuitiver, einfacher, was auch immer. Früher oder später fällt uns das doch wieder auf die Füße  :'( Oder kommt man ohne dieses Wissen/Verständnis aus und ich hab da nur ne Denkblockade  :-[

Leider kommt man ohne regexp nicht aus. Anwenderfreundlich ist das aber leider nicht. Für mich ist es einfacher nur DOIF zu erlernen und nicht noch sequence, dummy, notify usw.

Letztendlich sollten wir den Anfängern nicht vorschreiben, was sie verwenden müssen.
Es gibt vermutlich Menschen, denen ist die grobe Funktionsweise eines DOIF verständlicher und anderen halt notify, sequency, dummy, at usw.

Dass es überhaupt so viele Wege und unterschiedliche Syntaxe in FHEM gibt, liegt ja daran, dass uns Entwicklern die Syntax nicht streng vorgegeben wird, was natürlich auch Freiheiten zulässt.

Zitat von: rudolfkoenig am 12 Februar 2017, 23:10:41

Code Auswählen Erweitern

at 08:00 set Lampe on-till 10:00
So kryptisch finde ich das auch nicht. Und man hat 6 mal Klammer gespart.

natürlich nicht. Unterstützt denn jedes Device on-till ?

Alle die SetExtensions verwenden, und ueber ein on und ein off verfuegen.
Meine Module tun das. Auch dummy :)

auch TRX_LIGHT und IT

Zitat von: rudolfkoenig am 12 Februar 2017, 23:35:02
Alle die SetExtensions verwenden, und ueber ein on und ein off verfuegen.
Meine Module tun das. Auch dummy :)

immerhin, zwei verschiedene Funktionsaufrufe wären dann aber schon problematischer oder irre ich mich?

Meinst Du zu einer anderen Uhrzeit schalten ? Das wäre dann ein neues at. Aus Sicht der Zeit betrachtet ja auch etwas anderes, also z.B. morgens und abends.
Oder meinst Du zur selben Zeit verschiedene Aktionen ? Die müssen ja nur durch ; getrennt aufgelistet werden.

Oder Du meinst etwas komplexeres. Dafür nimmt man dann Perl.  ;D Und da komme ich zurück zum Thema: Welche komplexen Szenarien haben Anfänger, die über zuvor Beschriebenes hinausgehen ? Ich war Stolz wie Oskar als mein CUL meine Rolläden zu unterschiedlichen Zeiten in Abhängigkeit von Sonnenauf und -untergang steuerte, meine Fritte mir bei Anruf den Tv stumm schaltete und den Anrufer auf dem TV anzeigte..... Alles einfache notifys und ats.

Ich glaube man will mich nicht verstehen.

Gut, dass ich nicht eine Lampe hell und dunkel schalten wollte, gut dass ich nicht mehr als zwei Zeitschaltpunkte schalten wollte ...

aber ich weiß: man kann immer ein komplexes Problem auslagern oder in mehrere Definitionen aufteilen.

Zitat von: KölnSolar am 12 Februar 2017, 23:26:56Du erwähnst, dass Dir events bzw. notify suspekt erschienen. Aus der betriebswirtschaftlichen IT kannte ich das auch nicht und tat mich entsprechend schwer.

Was ist mit Workflow? ...auch BTEs, BAdIs und andere Enhancement-Techniken kann man als Event betrachten. Im Workflow gibt's das sogar als Begriff.
Gruß,
   Thorsten

Überleben die setExtensions timer einen Restart?

Auch wenn die Diskussion mittlerweile in eine andere Richtung gehen, wollte ich auch meinen "Senf" schreiben:

- Ich mag Module die nach dem Prinzip arbeiten: Mach eine Sache, die aber Richtig
Mir persönlich ist DOIF eigentlich viel zu komplex. Einfach ist (sorry) anders
- FHEM ist (sollte) ereignisorientiert sein. Man kann schon bei der Definition des Notwendigen Ereignisses fiel erledigen. In Meinen Augen aber verschleiert DOIF gerade das ....

Und was mich gerade am Anfang ziemlich gestört hatte:
In eigentlich jedem Thread, wo jemand nach einer Lösung für sein Problem fragte, auch wenn er direkt nach notify fragte, wurde als "Lösung" DOIF angeboten. Grunstäzlich. War nach meinem Geschmack einfach zu viel "Werbung" .....

DER Hauptgrund für DOIF ist für mich auch die Möglichkeit Zeiten, Wiederholungen, Ereignisse zu einem Ablauf an einem Ort definieren zu können.
Das ist abseits der ganzen Convenience-Sugars  der mittlerweile im DOIF existiert der echte Mehrwert den man anders in FHEM nicht hinbekommt.

Als ich zu FHEM kam war die Zersplittung eines einzelnen Problems in mehrere Threshold/At/Notifiy/Watchdog Instanzen für mich sehr merkwürdig und ist IMO der Übersichtlichkeit nicht dienlich.

Ich wechsle in meinen DOIFs oft recht schnell auf die Perl Ebene und rufe Funktionen aus meinen myUtils Modulen auf.
Den Großteil dessen was DOIF Im Ausführungsteil kann hab ich längst wieder vergessen, obwohl ich die Commandref mittlerweile einige mal durch habe.
Einfach weil ich vieles davon nicht einsetzen will, da ich mir eh schon den FHEM/PERL Weg merken muss.

Aber das Grundgerüst für die Bedingungen (Zeit- und auch Eventbasiert), sowie die Attribute wie z.B. repeatcmd ist einfach top.
An sich würde mir daher wahrscheinlich ein weit einfacheres Modul welches diese Grundfunktionalität von DOIF bietet ebenso reichen.

Evtl. würde solch ein Modul auch weniger für Aufregung sorgen. ;)
Aber es zwingt einen ja keiner alle Features von DOIF zu nutzen (oder das Modul überhaupt zu verwenden).

Ich bin jedenfalls sehr froh, dass es DOIF gibt.

Ich wüsste jetzt gerne ob das mit einem at möglich ist:

Zitat von: maci am 13 Februar 2017, 08:50:59
Hallo an alle,

Ich schalte eine Pumpenfreigabe über einen at Befehl bei Sonnenaufgang.
Ich habe nun versucht den Befehl so ändern, dass er immer 2 Stunden nach Sonnenaufgang schalten soll.
Doch das funktioniert nicht.
Hier meine Definition:

Code Auswählen Erweitern


define SolarpumpeON at *{sunrise("REAL")} + ([02:00]) set Freigabe_Solarpumpe on
attr SolarpumpeON room Solaranlage

Im Log wird folgendes ausgegeben:

Code Auswählen Erweitern


2017.02.13 07:20:00 3: SolarpumpeON: Unknown command +, try help.

Wie kann ich das ändern, dass es funktioniert?
Ich hätte schon hier gesucht, aber nichts gefunden.

Genau das ist, was aktuell hier viele falsch verstehen. Es "regt" sich überhaupt niemand "auf" über DOIF. In einer Diskussion kommen Argumente und Gegenargumente auf den Tisch. Ich glaube, das ist ein aktuelles gesellschaftliches Phänomen, dass andere Meinungen, die ggf. auch mal sehr direkt ausgedrückt werden, als "aufregen" oder "dissen" oder "neidisch sein" interpretiert wird. Das ist natürlich eine ganz andere Diskussion und es gehört hier nicht hin.

Ich finde, dass Damian es nicht nötig hat, sein DOIF hier auf biegen und brechen zu verteidigen. Es hat eigentlich niemand gesagt, dass DOIF insgesamt unbrauchbar, Fehl am Platz oder gar überflüssig für die Allgemeinheit wäre. Die Eignung scheint stark von der Nutzergruppe und von eigenen persönlichen Vorlieben abhängig zu sein. Und das ist nichts schlechtes.

Ich bspw. schreibe mir inzwischen für komplexe Problemstellungen eigene Module, die die Aufgaben dann möglichwerweise auch generisch bwz universell erledigen können (das macht natürlich nur Sinn, wenn das Problem die Komplexität rechtfertigt, das Problem viele Devices auf unterschiedliche Art betrifft oder es eben gerade Spaß macht ;) ).

Das Thema mit dem Support ist natürlich eines (siehe Rudi). Das kann man nicht weg diskutieren. Allerdings muss man auch sagen, dass durch steigende Nutzerzahl (insbesondere der "Convinient"-Nutzer, der Supportaufwand ohnehin ansteigt. Welcher Anteil sich da auf DOIF verteilt, ist kaum zu ermitteln.

Zitat von: igami am 13 Februar 2017, 09:16:42
Ich wüsste jetzt gerne ob das mit einem at möglich ist:

Wieso denn nicht?
define SolarpumpeON at *{sunrise("REAL",+7200)} set Freigabe_Solarpumpe on
attr SolarpumpeON room Solaranlage
(Ungetestet, nach Wiki zu sunrise und commandref zu at)

Zitat von: igami am 13 Februar 2017, 09:16:42
Ich wüsste jetzt gerne ob das mit einem at möglich ist:

Ja. Ist es.

*{sunrise_abs("REAL",7200)} set Freigabe_Solarpumpe on

Zitat von: Beta-User am 13 Februar 2017, 09:22:19
Wieso denn nicht?

Code Auswählen Erweitern

define SolarpumpeON at *{sunrise("REAL",+7200)} set Freigabe_Solarpumpe on
attr SolarpumpeON room Solaranlage
(Ungetestet, nach Wiki zu sunrise und commandref zu at)

shame on me. hab das 'The first specifies an offset (in seconds), which will be added to the event.' überlesen

Zitatimmerhin, zwei verschiedene Funktionsaufrufe wären dann aber schon problematischer oder irre ich mich?

Ich verstehe die Frage nicht.
Damian, ich will nicht gegen DOIF schiessen, will aber, dass in der "DOIF-Werbung" nicht Unwahrheiten ueber den at/notify verbreitet werden. Wenn ihr Beispiele sucht, was mit DOIF einfacher geht, dann bitte gruendlicher Recherchieren.

ZitatÜberleben die setExtensions timer einen Restart?

on-till, on-till-overnight und interval ja, da sie jeweils ein at anlegen. on-for-timer haengt davon ab: mit FS20 ja, da das Modul on-for-timer direkt unterstuetzt, und damit der Timer im geschalteten Geraet laeuft, anderswo nicht. Auch blink ueberlebt es nicht.

Zitat von: igami am 13 Februar 2017, 09:24:54
shame on me. hab das 'The first specifies an offset (in seconds), which will be added to the event.' überlesen

Es ist aber nur der erste Parameter, wenn man bei 0 zu zählen anfängt.

Wenn wir gerade bei "Werbung" sind:
M.E. sind viele Möglichkeiten, die man mit den Grundbausteinen at und notify machen kann, nur sehr spärlich erklärt (aber -wie in anderen Fällen auch - vorhanden, wenn man die Doku mit "wissenden" Augen liest).
Das ist schade, da es bei der Automatisierung ja eigentlich nur darum geht, entweder zeitgesteuert oder in Abhängigkeit von Ereignissen Aktionen auszulösen (oder zu prüfen, ob eine Aktion erforderlich ist, z.B. wenn man zwei mögliche Eingangsbedingungen hat).

Anfänger sollte man nach meiner persönlichen Meinung deutlicher auf diese einfachen Grundlagen (zeit- oder eventbasierte Reaktion) hinweisen und auch einige mehr Beispiele für defmod haben. Ich habe zu Beginn einiges gelesen, aber irgendwie scheint mir diese Kleinigkeit entgangen zu sein, defmod habe ich erst vor wenigen Wochen entdeckt, die Option "temporary" noch später. Für meinen persönlichen Geschmack bin ich zu schnell bei DOIF angelangt und hatte dann irgendwann den Eindruck, dass vieles nicht mehr so funktioniert hat wie ganz zu Beginn. Keine Ahnung warum, aber meine Vermutung ist die, dass eine oder mehrere der vielen Optionen gesetzt hätten sein müssen, die in den letzten 24 Monaten dazugekommen sind.
Das wäre mir mit at/notify erspart geblieben...

Das soll - um das klar zu sagen - kein Vorwurf an irgendeinen Modulentwickler sein! Vermutlich habe ich schlicht und einfach einige typische Anfängerfehler gemacht. Mir geht es nur darum, auf den Umstand hinzuweisen, dass KEIN Modul dieser Welt demjenigen das Denken (und klare Beschreiben seiner Ein- und Ausgangsbedingungen) abnehmen kann, der in die wirkliche Welt eingreifen will.

Ich habe mit FHEM angefangen, als es noch kein DOIF gab. Habe mich dann in notify, at, etc eingelesen und damit natürlich alles nötige bauen können. Irgendwann habe ich dann gesehen, dass Damian DOIF erstellt hat. Zu Beginn hat mir das Modul so sehr zugesagt, dass ich selbst meine vorhandenen notifys, at, etc in DOIF umgebaut habe. Dies hatte verschiedene Gründe:

- "einheitliche" Syntax für mich, weil fast alles mit DOIF geschaltet wurde
- Am Anfang recht übersichtlich und verständlich
- Kaum Perl Kenntnisse nötig

Inzwischen muss ich sagen, dass es mich auch leicht überfordert und ich noch nicht durch alle neuen Funktionen durchgestiegen bin. Allerdings liegt das eher an meiner Zeit für FHEM. Die Doku zum Modul ist top und sehr aussagekräftig. Daran liegt es definitiv nicht. Da ich mich nicht weiter eingearbeitet hatte, hatte dies zur Folge, dass ich zB teilweise weiterhin mit Dummys arbeite und nicht mit dem eigenen Status von DOIF. Somit würde ich für mich behaupten, dass DOIF eine Zeitlang der Weg des geringsten Widerstandes war, die für mich "komplexen Dinge" jedoch aktuell noch nach "altem" Verfahren bearbeitet werden.

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 (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

Ich gebe auch mal meinen Senf dazu:

Wer Perl kann, für den ist es sicherlich einfach komplexere Aufgaben in ein notify, at, die 99_myUtils.pm oder sonst wo hin zu packen.
Ich kann Perl nicht, was nicht heißen soll, dass ich nicht bemüht bin es zu lernen und durchaus großes Interesse in dieser Richtung vorhanden ist - ich hab zwar manchmal das Gefühl dass ich mit FHEM mehr Zeit verbringe als mit meiner Frau, aber es ist und bleibt ein Hobby... allerdings eines das riesen Spass macht.

Ich nutzte so gut wie keine notify oder at mehr, ich habe fast alles auf DOIF umgestellt - darunter auch viele (für mein Verständnis) komplexe Aufgaben. Ich stelle gar nicht in Frage, dass man das alles auch mit notify und at und myUtils hin bekommt, vielleiecht sogar performater oder was auch immer. Aber in Punkto Übersichtlichkeit, geht mMn nichts über DOIF!
Und noch was, wer Perl kann, der braucht DOIF sicher nicht - aber die meissten von ihnen würden sich bestimmt wundern, wie einfach man mit DOIF auch sehr komplexe Aufgaben lösen kann.

Bei DOIF ist es sicherlich schwer bis unmöglich alle Funktionen zu überblicken. Allerdings ist das nicht nur ein DOIF Problem, ganz FHEM unterliegt diesem Problem - es gibt täglich so viele Neuerungen und Änderungen, es ist unmöglich alles mit zu bekommen. Daher ist man gezwungen sich mit gewissen Dingen intensiver zu beschäftigen und wieder andere links liegen zu lassen. Und diese Entscheidung muss wohl jeder selber treffen.

Deswegen nutze ich DOIF und ich habe es bisher nicht bereut...

Hi,

ich nutze DOIF aus ähnlichen Gründen wie @automatisierer. Erst durch FHEM kam ich mit perl in Berührung, vorher hat sich programmieren auf HTML und SPS beschränkt.
Die ersten Schritte waren dann auch mit at, notify und meist zusammenkopiert ;-) Als ich dann über DOIF gestolpert bin fühlte ich mich "heimischer" als bei z.B. notify. Beim notify muss man halt im Eventmonitor schauen was genau ankommt wo ich . und wo ich * setzen muss usw usw. Und die Verknüpfung zweier Bedingungen ist für einen perl Neuling schon recht schwer.
Beim DOIF kann man halt im Device selber schauen, wie heißt das Reading? Ah ok das heißt: on oder off und auf dieses eine simple "wort" kann ich mein DOIF ausrichten, ich muss nicht schauen ob es evtl set_on oder setON oder oder heißt ;-)
Klar braucht man diese Unterscheidung auch mal im DOIF im Besonderen wenn man irgendwann mit Teilausdrücken arbeitet. Aber dann kennt man das Modul schon etwas und kommt mit Ausprobieren und den vielen Beispielen in der Commandref schnell zum Ziel.
Selbst einfach dinge, für DOIF eigentlich zu "klein, simple" z.B. ([irgendwas:on])(set wasanderes on) gehen mir mit DOIF einfach von der Hand, beim notify müsste ich z.B. nachschlagen, ausprobieren.
Ich hab durch das DOIF die anderen Module einfach vernachlässigt ;-)
Grüße
Achim

Ich hab mir jetzt noch mal das Einsteiger.pdf angesehen. Von DOIF keine Spur. Sollte es also nicht Ziel der Befürworter des DOIF sein, dass das Modul dort erwähnt wird ? Wäre es nicht schön, wenn ein newbie eine Frage zur Automatisierung stellt und wir könnten einfach antworten, ob er sich schon mal Seite xy im Einsteiger.pdf angesehen und für welche technischen Hilfsmittel er sich entschieden hat ? Wir ihm im Einsteiger.pdf eine Unterstützung für seine Entscheidung an die Hand geben würden ?
Müssten wir, und das hat für mich Beta-User treffend hervorgehoben, im Einsteiger.pdf nicht besser erklären, was Automatisieren eigentlich bedeutet, also Zeit-, Ereignis-, Gruppensteuerung.... Also die Theorie des SmartHomes stärker vermitteln und erst danach die technischen Hilfsmittel, die FHEM einem dazu bietet aufzeigen ? At,notify,structure..... vs. DOIF quasi nebeneinander ?

Hat Automatisierer gerade nicht genau die Dinge beschrieben, wie sich DOIF abgrenzt und ich formuliere es leicht um:
wie einfach man mit DOIF auch sehr komplexe Aufgaben lösen kann, ohne Perl können zu müssen
aber auch
Bei DOIF ist es sicherlich schwer (bis unmöglich) alle Funktionen zu überblicken.

Und jetzt können doch alle einfach mal per Daumen abstimmen, ob das Ziele sind, die weiterverfolgt werden sollten(hoch) oder ob wir einfach alles lassen wie es ist(runter): Wir haben supertolle Automatisierungshilfen und jeder empfiehlt nach seiner Facon  ;)

Zitat von: rudolfkoenig am 13 Februar 2017, 09:31:01
Damian, ich will nicht gegen DOIF schiessen, will aber, dass in der "DOIF-Werbung" nicht Unwahrheiten ueber den at/notify verbreitet werden. Wenn ihr Beispiele sucht, was mit DOIF einfacher geht, dann bitte gruendlicher Recherchieren.

Genau das stört mich auch etwas. notify, at und Co. sind weder weniger brauchbar als DOIF noch schlechter dokumentiert (wenn man weiß, was eine Doku ist).

Zitat von: marvin78 am 13 Februar 2017, 13:01:15
wenn man weiß, was eine Doku ist

Hier spielt natürlich auch immer die Subjektive Anforderung mit. Die DOIF Doku ist nicht schlechter, oder besser als andere. Ich würde sie teilweise ausführlicher nennen, was Anfängern vielleicht eher entgegen kommt. Wobei ich wiederum auch nicht sage, dass die von notify, at, etc. anders sein müsste. Daher der Aspekt des Subjektiven.

In den letzten Beiträgen wird eigentlich immer gesagt:_
Wer DOIF verwendet, braucht kein Perl, wer notify/at etc. verwendet dagegen schon ...

Habe bei mir läuft FHEM ohne weitere perl-Konstrukte  .. und keine Probleme. Obiges ist also ein Mythos ....

BTW:
Meiner Meinung nach währe für mich DOIF auch nicht übersichtlicher, da es, wie schon erwähnt, das Ereignisorientierter versteckt. Da ich es lieber direkt mag, liebe ich notify ....

Zitat von: Amenophis86 am 13 Februar 2017, 13:28:23
Hier spielt natürlich auch immer die Subjektive Anforderung mit. Die DOIF Doku ist nicht schlechter, oder besser als andere. Ich würde sie teilweise ausführlicher nennen, was Anfängern vielleicht eher entgegen kommt. Wobei ich wiederum auch nicht sage, dass die von notify, at, etc. anders sein müsste. Daher der Aspekt des Subjektiven.

Naja gerade für Anfänger finde ich die Doku, ob nun EN oder DE zu notify doch zu knapp, beim at hat man doch ein paar Beispiele, beim doif eigentlich schon zuviel zum lesen aber durch die Gliederung kann man sich den Teile raus suchen der aktuell benötigt wird. Als Anfänger lebt man nunmal von Beispielen und copy & paste, der eine Teil kommt nie darüber hinaus und fragt auch nach 100 Posts noch nach Codeschnippseln, der andere Teil lernt mit jedem kopierten und angepassten Code dazu :-)
Vermutlich auch ein Grunde warum ich mich nach kurzer Zeit nie näher mit dem notify beschäftigt habe ;-)

Zitat von: Wernieman
Ich denke man kommt bei beiden Modulen erstmal ohne perl aus. Die Frage ist ja auch ab wann man diversen Code nun als perl definiert bzw wo man die grenze zieht. Für mich persönlich beim DOIF sobald ich {} nutze. Ich wüsste jetzt z.B. ohne nachzuschauen nicht wie ich beim Notify 2 Sachen logisch verknüpfe. Ob das nun Zeit, Events oder eine Kombination aus beidem ist. Hier erfolgt der Wechsel zu perl dann eher als beim doif. Kann aber auch daran liegen, dass ich mich sehr früh dem doif zugewandt habe und die einfache logische Verknüpfung beim notify nicht kenne (eq, ne, <> usw)
Ich müsste mich als beim notify früher in die Ebene begeben, welche ich als perl definiere, gut möglich, dass es anderen ähnlich geht und daher die aussage "Wer DOIF verwendet, braucht kein Perl, wer notify/at etc. verwendet dagegen schon ..." auftaucht.

Tsssss. Hatten wir nicht früher nen roten Daumen runter  :o Und ich wundere mich, dass nicht wenigstens der gedrückt wird. Dachte schon an allgemeine Wahlmüdigkeit  ;D
also nochmal(sorry):
Und jetzt können doch alle einfach mal per Beitragsbewertung abstimmen, ob das Ziele sind, die weiterverfolgt werden sollten(grüner Daumen hoch)
oder
ob wir einfach alles lassen wie es ist(grüner Haken): Wir haben supertolle Automatisierungshilfen und jeder empfiehlt nach seiner Facon  ;)

(Und ich hoffe, dass das jetzt nicht für irgendwen problematisch ist, weil es meine Beitragsbewertungen verfälscht)

So, dann mal auch meine 2 cents:

Bei meinen Anfängen gab es auch noch kein DOIF.
Damals habe ich wie viele andere auch, alles mittels notify/at etc. gemacht.

Zwischenzeitlich nutze ich beides, je nach Einsatzzweck.
Da, wo mehrere at's/notify's zusammenspielen würden, habe ich auch DOIF gesetzt, einfach weil es übersichtlicher ist und alles an einer Stelle.
Dort, wo wirklich nur auf ein Event od. Zeit reagiert wird, kommen weiterhin notify und at zum Einsatz.

Finde jetzt nicht unbedingt, dass es so ein großes Problem mit den verschiedenen Syntaxes ist.
Das zieht sich doch eh überall durch.

Bei dem einen Sensor heißt ein Reading so, und bei einer anderen Sensor-Familie halt anders. Ähnliches gilt auch hier.

Und ich denke, die Variante [Sensor:reading] ist für Einsteiger einfacher zu handhaben als die RegExes :)

lg, Stefan

Ich pflichte Icinger bei und verstehe die eingangs gestellte Frage eigentlich nicht so recht, die ja dann zu dieser Diskussion geführt hat. DOIF ist ja völlig optional....

Ich persönlich nutze je nach Anwendungsfall alles, also at, notify, DOIF....

at und notify bevorzuge ich für die einfachen Fälle. DOIF nehme ich für Sachen mittlerer Komplexität und wenn ich die zusätzlichen Features brauchen kann. Dann finde ich es recht effizient und übersichtlich.

Dass DOIF dann hier und da eine eigene Syntax verwendet, muss einem natürlich klar sein. Generell führt der mächtigere Funktionsumfang dazu, dass ich da immer wieder mal nachlesen muss, aber die Doku ist ja sehr gut.

Mit den DOIFs, die ich am Laufen habe, bin ich sehr zufrieden.

Zitat von: Beta-User am 10 Februar 2017, 15:19:48
@marvin78
Geht sogar mir schon so...

Noch was fällt mir dazu ein:

Im Einsteigerdokument werden relativ wenige Module erklärt, darunter aber eben auch DOIF! Das wirkt so, als müsse man das kennen und verwenden.

So gesehen sollte man überlegen, ob der Teil nicht raus sollte (ich würde dann auch noch FLOORPLAN vorschlagen, ob das Fritten-Modul drin ist, wäre ggf. zu klären). Das war im Nachhinein jeweils völlig nutzloser Aufwand... (Persönliche Meinung, und v.a. keine Generalkritik an diesem ansonsten wirklich hilfreichen Dokument!)

Mich würde mal interessieren von welchem Einsteigerdokument die Rede ist. Mir ist keins bekannt, das DOIF erwähnt.

Zitat von: d-man am 13 Februar 2017, 15:34:43
Ich pflichte Icinger bei und verstehe die eingangs gestellte Frage eigentlich nicht so recht, die ja dann zu dieser Diskussion geführt hat. DOIF ist ja völlig optional....

Ich dachte, dass ich das schon ein paarmal erklärt habe: Ich wollte eigentlich nur wissen, warum DOIF im Anfängerbereich (für mich gefühlt) so oft auftaucht. Ich hatte mich darüber einfach nur gewundert, weil sich mir das DOIF nie "aufgedrängt" hat, aber es anscheinend für viele Einsteiger sehr "sichtbar" ist.
Das ist alles. Ich hatte nicht einmal wirklich eine Diskussion über die Vor- und Nachteile der verschiedenen Ansätze beabsichtigt.
Gruß,
   Thorsten

Zitat von: KölnSolar am 13 Februar 2017, 12:11:43
Ich hab mir jetzt noch mal das Einsteiger.pdf angesehen. Von DOIF keine Spur. Sollte es also nicht Ziel der Befürworter des DOIF sein, dass das Modul dort erwähnt wird ? Wäre es nicht schön, wenn ein newbie eine Frage zur Automatisierung stellt und wir könnten einfach antworten, ob er sich schon mal Seite xy im Einsteiger.pdf angesehen und für welche technischen Hilfsmittel er sich entschieden hat ? Wir ihm im Einsteiger.pdf eine Unterstützung für seine Entscheidung an die Hand geben würden ?
Müssten wir, und das hat für mich Beta-User treffend hervorgehoben, im Einsteiger.pdf nicht besser erklären, was Automatisieren eigentlich bedeutet, also Zeit-, Ereignis-, Gruppensteuerung.... Also die Theorie des SmartHomes stärker vermitteln und erst danach die technischen Hilfsmittel, die FHEM einem dazu bietet aufzeigen ? At,notify,structure..... vs. DOIF quasi nebeneinander ?

Dem würde ich durchaus zustimmen, am besten mit einem Link zu Commandref zu DOIF, denn die ist nicht nur, aber auch für Anfänger konzipiert, vielleicht werden damit "Anfänger-Helfer" weniger mit DOIF-Fragen "belästigt".

Was allerdings in der ganzen Diskussion auffällt, ist der ständige Vergleich zwischen notify, at und DOIF, dabei macht der Funktionsumfang eines notifys oder ats vielleicht ein Prozent im DOIF-Sourcecode aus. Die Philosophie der Zustandsverwaltung im DOIF haben die meisten DOIF-Nicht-Nutzer offenbar gar nicht zur Kenntnis genommen.


 

@Ellert und KölnSolar:
Gut aufgepaßt! Es steht tatsächlich nichts im Einsteigerdokument von DOIF und ich kann auch nicht mehr nachvollziehen, warum sich bei mir diese Überzeugung so hartnäckig festgesetzt hat.

Kann auch sein, dass beim Stöbern im Forum der Eindruck entstanden ist, es sei common sense, dass es damit am einfachsten ginge, die Rolladenautomatik zu machen, vielleicht gab es auch einen entsprechenden WIKI-Artikel. Fakt ist, dass es damals einfach aussah und ich erst in jüngerer Vergangenheit dahinter gestiegen bin, dass es bei weitem nicht so einfach ist, derartige Automatiken oder Zustandsmaschinen oder was auch immer zu bauen. Zumal die Doku jedenfalls damals deutlich überschaubarer war als heute.

Dass die Doku jetzt auf dem Stand ist, ist übrigens auch gut! Denn so kann jeder auf den ersten Blick sehen, dass es einiges an Nachdenken erfordert, um ein ordentliches Ergebnis zu erreichen. Vermutlich bin ich auch erst durch die Lektüre des einen oder anderen Teils davon schlauer geworden, ob ich jetzt ein Ereignis, ein reading oder was auch immer auswerten soll/kann/muß.

Sofern ich mit dieser unzutreffenden Aussage zum Einsteigerdokument irgendjemand zu nahe getreten sein sollte, bitte ich ausdrücklich um Entschuldigung. Denn eines ist klar: jeder hier will die Sache positiv voranbringen, allen voran die Modulentwickler einschließlich der DOIF-Beteiligten. Dass die jeweils auch ohne so ein Modul ihre Anliegen ans Laufen bringen würden, ist eine Selbstverständlichkeit.

Und die Lektüre mancher Beiträge hier zeigt einmal mehr: Es gibt viele Wege nach Rom, auch beim lernen. Wenn der eine oder andere hier gerade wegen DOIF bei der Stange geblieben ist, soll mir das auch recht sein.
In dem Zusammenhang sollte ich vielleicht erwähnen, dass mit am Anfang die Vorstellung, eigene myUtils zu nutzten, sehr suspekt vorkam. Dafür war ich definitiv noch nicht reif, DOIF aber hat funktioniert (leider nicht immer lange mit den Ergebnissen, die ich erwartet habe, aber das will ich mangels show-me hier nicht vertiefen).

Ich stimme also denen zu, die dafür sind, jeden seinen Weg finden zu lassen, plädiere aber nach wie vor dafür, auch notify und at nicht in Vergessenheit geraten zu lassen und v.a. denen, die keine Ahnung haben möglichst auch die Erarbeitung der Grundlagen nahezulegen. Man kommt früher oder später eh' nicht drum rum.

Aber: Dass ein notify mit anschließender Prüfung mehrerer Zustände genauso viele ressourcen benötigen soll wie ein DOIF, das ständig alle relevanten Zustände überwacht, leuchtet mir immer noch nicht ein...

Nix für ungut,
Beta-User

Zitat von: Beta-User am 13 Februar 2017, 20:40:45Aber: Dass ein notify mit anschließender Prüfung mehrerer Zustände genauso viele ressourcen benötigen soll wie ein DOIF, das ständig alle relevanten Zustände überwacht, leuchtet mir immer noch nicht ein...

Naja, ich habe mir zwar das Modul nicht angesehen, würde aber Damian durchaus zutrauen, dass das Modul die Bedingungen analysiert und sozusagen daraus interne notifies macht. (Also mal so für nicht-Modulentwickler erklärt.) Dann wird das Ding nur dann getriggert, wenn sich auch tatsächlich am Zustand irgendwo was ändert.
Gruß,
   Thorsten

Was übrigens interessant ist und ich bisher nicht in der DOIF Doku gelesen habe:
DOIF ist Zustandsoptimiert? Also eine Zusandsmaschine?

Das ist dann wirklich ein "anderer" Ansatz

(Disclaimer: Ist keine Kritik sondern öffnet mir, wertfrei, etwas die Augen über die Intension von DOIF)

Zitat von: Wernieman am 13 Februar 2017, 21:03:36
Was übrigens interessant ist und ich bisher nicht in der DOIF Doku gelesen habe:
DOIF ist Zustandsoptimiert? Also eine Zusandsmaschine?

Das ist dann wirklich ein "anderer" Ansatz

(Disclaimer: Ist keine Kritik sondern öffnet mir, wertfrei, etwas die Augen über die Intension von DOIF)

Das habe ich bereits vorhin geschrieben. Daher werden hier Äpfel mit Birnen verglichen. Und diejenigen, die das Modul nicht benutzen und das Konzept des Moduls nicht verinnerlicht haben, stellen Annahmen auf, die sie nicht aufstellen würden, wenn sie das Modul benutzen würden.

Ist ja schon ein richtiger Glaubenskrieg hier. ::)

Dann oute ich mich mal als DOIF-Skeptiker.

Auf meinem System steht es 43:1 für NOTIFY (ohne Residenten-Makros).
Die meisten sind einfache NOTIFY mit Regexp wizard schnell zusammengeklickt.

Bei komplexeren Sachen kommen auch einige Perl-Zeilen vor, damit ging bisher alles was ich wollte. 
Myutils verwende ich nicht.

Der Grund, warum ich mit mit DOIF bisher nie richtig anfreunden konnte, ist das zwanghafte DOELSE,
was die Logik m.M. nur verkompliziert. Mir sind da 2-3 einfache NOTIFY lieber, als ein komplexes DOIF,
das ich nach einer Woche nicht mehr verstehe.

Pro DOIF spricht aber m.M. die ausführliche einsteigerfreundliche Doku mit vielen Beispielen.

Gruß Ralf

Nachtrag:

Zitat
Was allerdings in der ganzen Diskussion auffällt, ist der ständige Vergleich zwischen notify, at und DOIF, dabei macht der Funktionsumfang eines notifys oder ats vielleicht ein Prozent im DOIF-Sourcecode aus. Die Philosophie der Zustandsverwaltung im DOIF haben die meisten DOIF-Nicht-Nutzer offenbar gar nicht zur Kenntnis genommen.

Das war mir auch nicht bewusst.

Zitat von: Damian am 13 Februar 2017, 21:28:25
Das habe ich bereits vorhin geschrieben. Daher werden hier Äpfel mit Birnen verglichen. Und diejenigen, die das Modul nicht benutzen und das Konzept des Moduls nicht verinnerlicht haben, stellen Annahmen auf, die sie nicht aufstellen würden, wenn sie das Modul benutzen würden.

Ich wollte es in meinem letzten Post nicht schreiben, aber genau den Eindruck habe ich auch. Es wird von Einigen gegen DOIF gewettert, obwohl sie offensichtlich keine Ahnung haben, wie man es einsetzt und welche Möglichkeiten man mit DOIF hat - wenn man es bedienen kann!

Alle in diesem Thread angeführten Gründe, warum DOIF für diese oder jene Anwendung nicht geeignet ist, konnte ich nicht nachvollziehen und führe das darauf zurück, dass diese User sich einfach nicht mit DOIF beschäftigt haben. !ABER! Es verlangt ja keiner das sie sich damit beschäftigen - die Benutzung des Moduls ist freiwillig - allerdings sollte man sich dann mMn auch mit "Vorurteilen" zurück halten.

Zitat von: automatisierer am 13 Februar 2017, 22:07:47
Es wird von Einigen gegen DOIF gewettert, obwohl sie offensichtlich keine Ahnung haben, wie man es einsetzt und welche Möglichkeiten man mit DOIF hat

Das umgekehrte scheint aber doch genau so der Fall zu sein ;)

Es ging doch hier ursprünglich gar nicht darum, ob eines von beiden besser ist, als das andere und ich weiß auch nicht, warum hier manche unbedingt meinen, ihren Weg als den einzig wahren zu verteidigen. Das erinnert mich an die uralte "Diskussion" Mein Win-Dings ist Besser als Lin-Dingx.

Ich kenne DOIF nicht wirklich und verwende es (bisher) nirgends aber nicht aus persönlicher Abneigung, sondern einfach, weil ich bisher keinen Grund hatte etwas anderes als at, notify, watchdog, ... zu verwenden. Ich konnte mit diesen "simplen" Bausteinen bisher jede Problemstellung lösen. Ok, als ich bei FHEM angefangen habe, gab es noch kein DOIF, deshalb habe ich mich an die Zuvorgenannten gewöhnt und fühle mich damit wohl. Hätte es DOIF bereits gegeben, wäre ich eventuell zuerst darauf gestoßen und würde heute damit arbeiten. Allerdings sagt mir auch die grundsätzliche Einfachheit von at, notify und Konsorten mehr zu. Gertreu dem Motto eine (einfache) Funktionalität je Baustein und die aber richtig. DOIF macht für mich den Eindruck einer eierlegenden Wollmilchsau und von denen bin ich, aufgrund meiner Erfahrungen aus anderen Bereichen (auch in der IT) kein so großer Freund.

Warum es anscheinend für Anfänger einfacher (oder nur beliebter?) ist lässt sich wahrscheinlich auch gar nicht beantworten, auch nicht von den Anfängern. Vielleicht ist es das ja auch gar nicht? Wenn dazu mehr Fragen im Anfängerforum auftauchen als zu den anderen, alternativen Modulen weist das ja vielleicht sogar eher auf das Gegenteil hin?  :o

Ansonsten interpretiere ich es hier frei nach dem Perl-Motto "There's more than one way to do it": Jedem Tierchen sein Plaisierchen :)  ... und das ist gut so!

So das waren meine 2Ct dazu.

ZitatDas umgekehrte scheint aber doch genau so der Fall zu sein ;)

Allerdings mit einem kleinen, aber feinen Unterschied.

Die meisten Befürworter von DOIF benutzen es auch und benutzen oder benutzten auch at, notify und co.

Sie können also auf Erfahrung für eine Beurteilung beider Welten zurückgreifen.

Die meisten der anderen Fraktion benutzen nur at, notify und co. und benutzen nicht bzw. haben nie DOIF benutzt.

Sie können also nicht auf Erfahrung für eine Beurteilung beider Welten zurückgreifen.

Sorry, aber so wie es "automatisierer" geschrieben hat, hat er etwas anderes gemeint:

Zitatwelche Möglichkeiten man mit DOIF hat - wenn man es bedienen kann!

Wobei ich übriogens auch einen Zustandsautomaten ohne DOIF in FHEM bauen kann. Mir sind lieber 5 kleine Zeilen (notify o.Ä.) lieber als ein großes, was ich eben auch nicht nach 5 Tagen mehr verstehe ... Kleine Schritte dagegen sind viel einfacher zu debuggen (meiner Meinung nach).

Oh, Kinners. So langsam is doch escht genug, odda?
Gruß vunn dä Kurpfalz,
   Thorsten

Zitat von: Thorsten Pferdekaemper am 14 Februar 2017, 10:40:38
Oh, Kinners. So langsam is doch escht genug, odda?
Gruß vunn dä Kurpfalz,
   Thorsten

Dann mach mal hier einfach zu. So langsam wiederholen wir uns hier alle. Jeder hat hier seinen Standpunkt dargestellt. Und wenn jemand genauer für sich ausmachen will, wo die eigentlichen Vor- bzw. Nachteile des Moduls liegen, der sollte es einfach mal selbst ausprobieren, so kann er dann für sich entscheiden, ob er es nutzen möchte oder nicht. Ansonsten philosophieren wir hier noch einen ganzen Monat.

Zitat von: Thorsten Pferdekaemper am 14 Februar 2017, 10:40:38
Oh, Kinners. So langsam is doch escht genug, odda?
Gruß vunn dä Kurpfalz,
   Thorsten

Geh ich recht in der Annahme, dass Deine Fragestellung aus dem OP nunmehr für Dich zufriedenstellend beantwortet ist? ;-)

P.S. Hab mir gerade den Spaß gemacht den Thread querzulesen. Sehr unterhaltsam. Fast wie Apple-Jünger gegen Android-Fanboys. Oder Klopapierfalter gegen -knüller. Oder, oder, oder. Danke Thorsten. Ich hab jetz fast Lust bekommen mir ein DOIF zu basteln, nur um damit ein at zu definieren und ein notify auszulösen...

Zitat von: Thorsten Pferdekaemper am 10 Februar 2017, 16:01:45
Hi,

also mal ohne auf die einzelnen Postings einzugehen: DOIF eignet sich für einen bestimmten Komplexitätsgrad, aber eigentlich nicht wirklich für Anfänger. Wenn man aber mal notify und at verstanden hat, dann kann man bestimmte Dinge ggf. schöner mit DOIF erledigen.
Ich wäre auch dafür, DOIF aus allen Anfänger-Dokus rauszunehmen. Ich wundere mich, dass es überhaupt drinsteht.

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

Gruß,
   Thorsten

Ok, hier kommt der Anfänger..

Ok, mittlerweile ist meine FHEM.cfg schon ziemlich umfangreich und ich habe einige Devices drin, da ich aber erst letztes Jahr damit angefangen habe, betrachte ich mich immer noch als Anfänger. Und ehrlich gesagt, vieles wenn nicht fast alles löse ich mit copy/Paste und dann modifizieren. Ein richtig tiefes Verständnis von Perl etc, habe ich nicht.
Ok, warum benutze ich im Wesentlichen doif und kaum (mehr) at oder notify?
Ich finde den Aufbau von doif logisch und auch ohne tiefe Perl etc Kenntnisse nachvollziehbar. Wenn überhaupt, habe ich rudimentäre Programmierkenntnisse noch aus Basic-Zeiten (ja, so alt bin ich)
Und if - then gab es damals schon.
Meine doif sind vielleicht auch nicht die elegantesten der Welt, sondern so gebaut, dass ich sie möglichst auch ohne große zusätzliche Doku noch später verstehe.
Es gibt in der commandref eine recht gute Anleitung, mit vielen Beispielen, das erleichtert copy/Paste.
Ich habe viele Steuerungen (Rolläden/Heizung) bei denen ich halt viele unterschiedliche Szenarien abfrühstücken möchte, das kann ich mit doif-doifelse-doelse am einfachsten strukturieren.

Mag sein, dass es mit notify und at auch geht, ich nutze das auch vereinzelt noch für einfache Dinge. Aber sie ich komplexe Abhänigkeiten / Situationen damit löse, da fehlt es mir an Beispielen.

So, das sind im Wesentlichen meine Gründe für doif-Nutzung

Ich habe mal ein komplexes Szenario unter Off Topic https://forum.fhem.de/index.php/topic,67106.0.html eingestellt

Selber umgesetzt habe ich dieses nur in Teilen 8-) Ich denke hier können sich die Befürworter einer Technologie entsprechend austoben :-) Die mir gefälligste Lösung werde ich dann entsprechend umsetzen und ggfls auch fürs Wiki/Forum aufarbeiten

Zitat von: tomster am 14 Februar 2017, 11:39:28

P.S. Hab mir gerade den Spaß gemacht den Thread querzulesen. Sehr unterhaltsam. Fast wie Apple-Jünger gegen Android-Fanboys. Oder Klopapierfalter gegen -knüller. Oder, oder, oder. Danke Thorsten. Ich hab jetz fast Lust bekommen mir ein DOIF zu basteln, nur um damit ein at zu definieren und ein notify auszulösen...

Die Diskussion hier hat wirklich nichts von denen, die du auflistest.

Hi,

Zitat von: Damian am 14 Februar 2017, 11:34:14
Dann mach mal hier einfach zu.

Davon halte ich nicht wirklich was, nur wenn es beleidigend wird oder so. Solange sich alle benehmen kann doch jeder seinen Senf dazugeben. Mein Spruch war eher Ausdruck meiner Verwunderung. 
Ich halte es da eher mit "DFTT": Wenn man keine Lust mehr auf einen Thread hat oder das ganze unnötig findet, dann beteiligt man sich halt nicht mehr.

Zitat von: tomster am 14 Februar 2017, 11:39:28
Geh ich recht in der Annahme, dass Deine Fragestellung aus dem OP nunmehr für Dich zufriedenstellend beantwortet ist? ;-)

Ja. Schon lange.

Gruß,
   Thorsten

Zitat von: Damian am 13 Februar 2017, 22:58:34
Allerdings mit einem kleinen, aber feinen Unterschied.

Die meisten Befürworter von DOIF benutzen es auch und benutzen oder benutzten auch at, notify und co.

Sie können also auf Erfahrung für eine Beurteilung beider Welten zurückgreifen.

Die meisten der anderen Fraktion benutzen nur at, notify und co. und benutzen nicht bzw. haben nie DOIF benutzt.

Sie können also nicht auf Erfahrung für eine Beurteilung beider Welten zurückgreifen.

Ich finde, man muss ein Modul nicht (produktiv) benutzen, um eine Meinung dazu zu haben. Die Erfahrung kann auch daraus bestehen, dass man versucht hat durch die Dokumentation zu einer Lösung einer Aufgabenstellung zu kommen und diese dann verworfen hat. Die Verstehen einer Funktionalität hängt von den Beschreibungen und Erläuterung und dem Verständnis des Lesenden ab. Wenn das nicht zusammenpasst, kann das an beiden Seiten liegen.

Die "kritischen" Stimmen hier zu DOIF benennen immer beides: einerseits die sehr ausführliche und mit vielen Beispielen angereicherte Dokumentation, andererseits die persönliche Sicht, dass es nicht so übersichtlich ist.

Herzliche Grüße
Lars

Zitat von: Wuppi68 am 14 Februar 2017, 12:12:53
Ich habe mal ein komplexes Szenario unter Off Topic https://forum.fhem.de/index.php/topic,67106.0.html eingestellt

Selber umgesetzt habe ich dieses nur in Teilen 8-) Ich denke hier können sich die Befürworter einer Technologie entsprechend austoben :-) Die mir gefälligste Lösung werde ich dann entsprechend umsetzen und ggfls auch fürs Wiki/Forum aufarbeiten

Hihi, und ich habe dort in meiner Antwort zuerst konkreten DOIF Code drin gehabt, um dann noch vereinfacht ohne Beispiel zu Antworten. (-:

Heisse Diskussion hier am Start.  8)

Gefällt mir.  ;D
Ich persönlich benutze alles !! Über at, notify, DOIF. Je nach dem was ich gerade bewerkstelligen will. Für die einfachen Sachen at und notify, und dann DOIF.

Ich persönlich komme mit DOIF recht gut klar, wenn nicht, dann wird gefragt und dann werden Sie geholfen !  ;)

Da ich aus der C16/64/128/plus4 Basic Zeit kommen, ist mir das mit IF THEN ELSE besten bekannt. Auch wenn manche jetzt die Hände über den kopf zusammen schlagen.

Ich selber, sehe mich immer noch als Anfänger. Viele hier haben definitiv tiefgreifende Progammierkenntnisse. Viele wiederum auch gar keine.
Ich denke, es ist abhängig, wieviel Aufand jeder in FHEM bzw Automatisierung reinstecken will, ohne dass das Privatleben (Familie, etc.) leidet bzw zu kurz kommt.

Ich denke, um den vollen Umafng von allem nutzen zu können, kommt man um PERL lernen nicht drum rum.
Aber wie gesagt, Zeit abhängig, Familie etc.....

Da ich von Haus aus Energieelektroniker mit nem Industriemeister bin, denke ich manchmal darüber nach, ob es vielleicht nicht schicker bzw einfacher wäre, es über eine grafische Oberfläche zu machen, so alla S7 eine UND Modul mit Eingängen und den Trigger drauf legen.

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

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.

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ß

Zitat von: Reinhart am 13 Februar 2017, 10:16:36
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 (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

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

Zitat von: sash.sc am 14 Februar 2017, 18:00:19


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.

Zitat von: Damian am 15 Februar 2017, 09:56:19
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

Zitat von: l.with am 17 Februar 2017, 13:47:30
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.

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

So eine ähnliche Frage habe ich unter https://forum.fhem.de/index.php/topic,69704.0.html (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.

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

Zitat von: Thorsten Pferdekaemper am 10 Februar 2017, 16:01:45
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.

Zitat von: leif am 20 November 2017, 04:01:11
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.

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

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:

ZitatEin 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

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.

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  8)).
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.

Hi!

Zitat von: Wernieman am 20 November 2017, 07:55:21
... Programmierstiel

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

Gruss Franz 

Zitat von: maci am 20 November 2017, 07:25:46
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.

Entschuldige, aber das kann ich unmöglich in einem Anfängerforum so stehen lassen denn es ist schlicht falsch.
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.
Es besteht die Möglichkeit Notifys durch Perlanweisungen komplexer zu machen. Dazu geht man innerhalb eines Notify von FHEM in die Perlebene. Danach kann man mittels Perlcode zum Beispiel einfache Abfragen machen.

define testNotifyLampe1 notify Lampe1.(on|off) { fhem("set Lampe2 " ($EVENT eq 'on' ? 'on' : 'off')) }

Und so weiter


Grüße

Habe meinen Beitrag überarbeitet!

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

Event Monitor, Event markieren, erst Create/Modify device, dann OK druecken. Man landet in der Detailansicht der gerade angelegten notify, hier unter "Change the executed command" Ziel und Befehl aussuchen, und modify klicken.

Zitat von: Wernieman am 20 November 2017, 07:55:21

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.

Das ist ganz richtig. Ich habe diesen Fehler am Anfang auch gemacht.

Zitat von: Wernieman am 20 November 2017, 07:55:21Wer weiß denn nach 1 Monat noch, was ein 10 Zeilen-Statement zu macht?

Antwort: Derjeniger, der genauso wie beim Perl Code sein Ding ein bisschen kommentiert/dokumentiert! ;)

ZitatFü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.

Da gibt es in der Installation ein schönes "fhem.cfg.demo". Wer zuerst damit fhem startet, kann schon rumspielen, und einige Sachen probieren / verstehen.

Zitat von: CoolTux am 20 November 2017, 08:52:55
Entschuldige, aber das kann ich unmöglich in einem Anfängerforum so stehen lassen denn es ist schlicht falsch.
Ein notify reagiert auf ein Ereignis (Event). Der Auslöser (Trigger) dafür wird als RegEx festgelegt. Es erfolgt also keinerlei Bedingungsabfrage.

Naja, was ist denn das Matchen auf eine Regex, wenn es keine Bedingungsabfrage ist? ;)

In Pesudo-Code würde man das ja wohl so schreiben:


if (EventString matches Regex) {
<execute code>
}


Events sind ja nichts anders als Device, Reading, Value Strings.
Und im Event Loop wird nun unter anderem für jedes Notify geprüft ob für eine Ausführung des Codes die Bedingung erfüllt ist, oder nicht (Regex matched, oder matched nicht).

Zitat von: Thyraz am 20 November 2017, 10:31:16
Events sind ja nichts anders als Device, Reading, Value Strings.
Und im Event Loop wird nun unter anderem für jedes Notify geprüft ob für eine Ausführung des Codes die Bedingung erfüllt ist, oder nicht (Regex matched, oder matched nicht).

Das hier nun aus zu diskutieren würde etwas weit gehen.
Ich kann Dir aber auch einen Event erzeugen der einfach nur "Im Himmel ist Jahrmarkt" in Deinem Eventmonitor zaubert.

Was nichts daran ändert, dass ein Notify welches darauf Triggern würde ebenfalls eine Bedingungsabfrage macht. ;)
Selbst Regex an sich ist ja eine Art if: If string starts with xyz oder if string contains only numbers usw.
Aber ja, diese Diskussion ist noch Unsinniger als das Thema an sich. :P

Ich konnte nur diesen "das kann ich unmöglich in einem Anfängerforum so stehen" Satz unmöglich in einem Anfängerforum stehen lassen. ;D

Jetzt hab ich aber genug getrollt und bin wieder raus.  :)

Du kannst es drehen und wenden, wie du möchtest aber ein notify ist nicht einfach eine Bedingung. Bitte beschäftige dich damit, was Event im Kontext von FHEM bedeutet.

Ich verstehe die Diskussion ohnehin nicht. Wer meint DOIF könnte notify auch nur Ansatzweise ersetzen, hat es schlicht nicht verstanden. Es hat beides auf gewisse Art seine Daseinsberechtigung. Ich brauche in meinem System kein einziges DOIF um viele Dinge auf sehr hohem Niveau zu automatisieren und behaupte, dass es auch noch wesentlich leichter zu debuggen ist und mit viel weniger Code auskommt. Wenn aber jemand bestimmte Dinge mit DOIF machen möchte, soll er. Es ist ja nun mal da. [/size][size=78%] [/size]

Zitat von: marvin78 am 20 November 2017, 11:24:29
Du kannst es drehen und wenden, wie du möchtest aber ein notify ist nicht einfach eine Bedingung. Bitte beschäftige dich damit, was Event im Kontext von FHEM bedeutet.

Ich verstehe die Diskussion ohnehin nicht. Wer meint DOIF könnte notify auch nur Ansatzweise ersetzen, hat es schlicht nicht verstanden. Es hat beides auf gewisse Art seine Daseinsberechtigung. Ich brauche in meinem System kein einziges DOIF um viele Dinge auf sehr hohem Niveau zu automatisieren und behaupte, dass es auch noch wesentlich leichter zu debuggen ist und mit viel weniger Code auskommt. Wenn aber jemand bestimmte Dinge mit DOIF machen möchte, soll er. Es ist ja nun mal da. [/size][size=78%] [/size]

muss ich sagen "stimmt", warum man überhaupt solche Diskussionen führt, Ich muss auch sagen, beides hilft und man kann mit beiden zum erfolg kommen. Ich nutze auch beides in meiner Installation,große abfragen mach ich lieber nicht mit DOIF, weil mir hier die Übersicht fehlt,
aber Windrichtung oder abfrage mit Eingabe oder Zeit mache ich schon in DOIF.

vielleicht sollte man die Energie für andere Sachen nutzen.

gruss

ZitatIch verstehe die Diskussion ohnehin nicht.

Das haben hier viele nicht. Es geht nicht darum, was besser ist, sondern wieso ploetzlich so viele Leute auf die Idee gekommen sind, DOIF zu verwenden, obwohl es fuer uns (die mit laenger mit FHEM arbeiten) nicht sichtbar, z.Bsp. im Einsteigerhandbuch, beworben wurde. Meine Theorie: die Leute suchen im Netz nach Rezepten, und man findet welche mit DOIF.

Ich meinte die zuletzt entstandene Diskussion, die sich darum drehte, ob notify überflüssig ist. Die Ausgangsfrage hat damit ja nichts zu tun. Die wurde selbst von mir verstanden.

Viele verwenden DOIF, weil im Anfängerbereich bei jeder Frage eine Lösung per DOIF präsentiert wird. Auch wenn es nicht immer sinnvoll ist (Keine Kritik an DOIF!)

Und zu dem Argument: "Dann ist alles in einem"
Genau das ist der Nachteil: Habe hier schon DOIF mit 10 ELSEIF gesehen, ob das jemand nach 1 Monat noch 100% versteht  ist fraglich. Debuggen dann praktisch unmöglich.

Leider wird solcher Code (nicht nur DOIF und fhem) gerne produziert. Habe es schon in jeder (mir bekannten) Programmiersprache gesehen.

Zitat von: Wernieman am 20 November 2017, 12:17:59
Genau das ist der Nachteil: Habe hier schon DOIF mit 10 ELSEIF gesehen, ob das jemand nach 1 Monat noch 100% versteht  ist fraglich. Debuggen dann

Du wiederholst Dich (heute früh erst). Hast Du mein Posting gelesen? Und amenomades Tipp bezüglich der Dokumentation? Genau so mache ich das nämlich, und seither habe ich überhaupt keine Probleme mehr zu verstehen, was ich vor einem Jahr warum und wie gelöst habe. Und ich habe sogar ein DOIF mit fast 20 DOELSEIF: nämlich jenes, welches die IR-Codes für meine Unterhaltungselektronik von "YamahaPowerOn" u.ä. ans Interface schickt. Alle Befehle auf einen Blick, mit direkter Vegleichsmöglichkeit, copy&paste für Erweiterungen usw. Was da an 16 notifys übersichtlicher sein soll ... ?

ZitatViele verwenden DOIF, weil im Anfängerbereich bei jeder Frage eine Lösung per DOIF präsentiert wird

Letzteres mag sein, aber dafür gibt es bestimmt Gründe, und das liegt vermutlich nicht daran, dass die Helfer DOIF bevorzugen, sondern vielleicht daran dass DOIF vom Fleck weg verständlicher wirkt auf Laien. Es ist nicht immer sinnvoll, das unterschreibe ich.

ZitatLetzteres mag sein, aber dafür gibt es bestimmt Gründe, und das liegt vermutlich nicht daran, dass die Helfer DOIF bevorzuge ...

Ketzerisch ausgedrückt: Es wird mehr beworben *duckundweg*

Zitat von: Pfriemler am 20 November 2017, 13:50:24
, und das liegt vermutlich nicht daran, dass die Helfer DOIF bevorzugen,

Ich nicht. Ich halte mich bei DOIF komplett raus.


Ich gehe auch mit der These, dass DOIF gut beworben wird. Es kann sogar sein, dass es für Einsteiger leichter ist, ob das aber sinnvoll ist, weil FHEM nicht für Leute gedacht ist, die es "einfach" haben wollen und auf Dauer auch dann nicht erfolgreich verwendet werden kann, wenn man sich nicht irgendwann tiefer rein denkt, ist eine andere Frage. Aber wie schon gesagt, beides hat Daseinsberechtigung. Oft wird FHEM ja auch nicht für eine komplette Hausautomation sondern nur für einzelne Themen eingesetzt.

Zitat von: rudolfkoenig am 20 November 2017, 09:17:27
Event Monitor, Event markieren, erst Create/Modify device, dann OK druecken. Man landet in der Detailansicht der gerade angelegten notify, hier unter "Change the executed command" Ziel und Befehl aussuchen, und modify klicken.

Danke, das ist in der Tat sehr hilfreich. 

Zitat von: Wernieman am 20 November 2017, 12:17:59
Und zu dem Argument: "Dann ist alles in einem"
Genau das ist der Nachteil: Habe hier schon DOIF mit 10 ELSEIF gesehen, ob das jemand nach 1 Monat noch 100% versteht  ist fraglich.

Zumindest als totaler Anfänger erscheint es mir am Anfang übersichtlicher vieles in einem zu haben (mit entsprechenden comments). Wenn ich für jedes Gerät mehrere Notifys hätte würde wahrscheinlich schon allein bei der Benennung ein ziemliches Chaos entstehen und ich würde den Überblick über die Zusammenhänge dieser verlieren. Wenn man erst langsam hinein wächst und entdeckt was man so alles benötigt fällt es nicht unbedingt leicht von Anfang an eine "sinnvolle" Struktur zu schaffen.

Viele Aussagen sind hier Thesen ohne Vermutungen, ohne sie jemals bestätigen oder widerlegen zu können.

Ich schreibe hier mal ein paar Punkte auf, die sich nachvollziehen lassen:

- alles was DOIF kann, kann auch notify + at + Perl und umgekehrt

- Die DOIF-Doku hat zu jedem Feature ein einfaches nachvollziehbares Anwendungsbeispiel

- Wenn man der aktuellen Jahres-Statistik glauben schenken darf, hat im gleichen Zeitraum DOIF ca. 100 User gewonnen, notify ca. 100 User verloren

Zitat von: Damian am 20 November 2017, 15:02:45
- alles was DOIF kann, kann auch notify + at + Perl und umgekehrt

Du hast watchdog vergessen...

Zitat von: Pfriemler am 20 November 2017, 16:49:36
Du hast watchdog vergessen...

wieso notify+at+perl reicht doch, wenn schon denn schon ;)

Zitat von: Pfriemler am 20 November 2017, 16:49:36
Du hast watchdog vergessen...

Das paßt m.E. schon noch eher in die Reihe notify+at (und einige andere "Hilfs-" Module).
Speziell watchdog hat zwar auch schon seine Tücken in der korrekten Konfiguration, es ist aber bei weitem nicht so unübersichtlich wie die Attribut-Orgien, die manchmal bei DOIF für eine korrekte Funktionsweise erforderlich sind. Ganz lustig ist es zuzusehen, wie sich die DOIF-Experten immer mal wieder darüber die Haare raufen, welche Attribute in welcher Kombination jetzt wie parametriert werden müssen.

watchdog hat eben genau einen Zweck und den erfüllt es zuverlässig und mit seit Ewigkeiten unveränderten Parametrierungsmöglichkeiten. Mehr muß für eine langfristige Landschaftspflege gar nicht sein ;) .

Aber wie immer: Ansichtssache :) .

naja, demnächst werden wir wohl diese Diskussion auf GUI ausweiten müssen ;)

https://forum.fhem.de/index.php/topic,77690.0.html