Warum will jeder DOIF verwenden?

[KölnSolar]

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 

[marvin78]

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

[Amenophis86]

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.

[Wernieman]

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

[CBSnake]

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

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.

[KölnSolar]

Tsssss. Hatten wir nicht früher nen roten Daumen runter  Und ich wundere mich, dass nicht wenigstens der gedrückt wird. Dachte schon an allgemeine Wahlmüdigkeit 
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)

[Icinger]

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

[dman]

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.

[Ellert]

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

[Thorsten Pferdekaemper]

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

[Damian]

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.


 

[Beta-User]

@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

[Thorsten Pferdekaemper]

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

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

[Wernieman]

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)

[Damian]

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.