Warum will jeder DOIF verwenden?

[MadMax-FHEM]

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

[KernSani]

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

[Thorsten Pferdekaemper]

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

Warum ich DOIF programmiert habe? Ganz kurz:

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

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? 

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

[marvin78]

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.

[l.with]

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:

Code Auswählen Erweitern

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

[Ellert]

da sehe ich schon kleinere Probleme

@marvin78
Werde doch mal konkret und benenne die Probleme.

[marvin78]

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.

[Damian]

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

[Ellert]

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?

[FunkOdyssey]

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.

[All-Ex]

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

[Damian]

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.

[Damu]

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.

[Christoph Morrison]

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.

[Thorsten Pferdekaemper]

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

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.

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