Warum will jeder DOIF verwenden?

[Ellert]

Überleben die setExtensions timer einen Restart?

[Wernieman]

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

[Thyraz]

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.

[igami]

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

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.

[marvin78]

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.

[Beta-User]

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

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)

[marvin78]

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

Ja. Ist es.

Code Auswählen Erweitern

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

[igami]

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

[rudolfkoenig]

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

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

[Ellert]

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.

[Beta-User]

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.

[Amenophis86]

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.

[Reinhart]

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

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

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

LG

[automatisierer]

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

[CBSnake]

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