Hallo Zusammen,
ich bin gerade ein bisschen am "Aufräumen".
Ich habe mir schon öfter die Frage gestellt, ob es sinnvoll ist, einen "großen" DOIF mit mehrere DOELSEIF zu machen,
oder mehrere DOIF.
Was wäre denn die bessere Vorgehensweise und vor allem, was belastet das System am wenigsten?
Ein großes DOIF hat weniger "Overhead" als mehrere kleine.
Außerdem ist es leichter zu administrieren und zu überwachen.
Allerdings kann ein DOIF immer nur ein Status haben. Völlig unabhängige Geräte (Waschmaschine und Gartenlicht :D) würde ich nicht über ein DOIF schalten, nur um Resourcen zu sparen.
Ich spiele ständig mit meinen DOIFs. Man ist ja nie fertig. Und ich hätte es gerne "perfekt" und "elegant". Jedoch erwische ich mich immer wieder dabei, dass ich mich verrannt habe und meine Anforderung nicht unbedingt "perfekt" und "elegant" umgesetzt werden können.
So gibt es Tage, in denen ich alles in ein DOIF packen möchte.
Tage später trenne ich das wieder auf, da die Kontrolle und das Debugging von komplexen DOIFs einfach zu umständlich ist.
Ich hatte ein DOIF mit mehr als 20 Timern. Das kann kein Mensch mehr vernünftig lesen. Vor allem, wenn die zweistelligen Timer (timer_11_c1, etc.) halt alphabetisch und nicht numerisch sortiert werden. Diese stehen dann plötzlich am Anfang der Readings-Liste.
Komplexe DOIFs haben (bei mir) auch immer den Nachteil, dass ich fast für jede Bedingung auch das Gegenstück abfragen muss, da sonst kein Zustandswechsel erfolgt. Ich arbeite recht wenig mit DOELSE, da mir diese zu häufig einen Strich durch die Rechnung machen.
Habe ich also ein DOIF "Lampe an - wenn scharf geschaltet - und dunkel", dann muss ich alle gegensätzlichen Vergleiche auch berücksichtigen. Was ist, wenn "nicht scharf" oder "nicht dunkel". Gestern habe ich ein Tischleuchten-DOIF zusammengefasst, welches am Ende zwar alle ersetzt, aber unlesbar war. Und ich bin mir auch nicht sicher, ob ich jede Gegenbedingung erwischt habe.
---
Viele kleine DOIFs sind natürlich einfacher zu lesen. Die Readings und das Log. Aber man sucht sich auch dumm und dusselig. Außerdem könnten diese sich ja gegenseitig stören. Möchte ich meine Tischleuchten bspw. über verschiedene Modi steuern, dann könnte ich mehrere DOIFs anlegen und diese je nach Modus disablen.
Tischleuchten Ein- und Ausschaltung des Zufallsmodus:
- wenn scharf geschaltet
- wenn scharf geschaltet und dunkel
- wenn abwesend
- wenn abwesend und dunkel
- oder kein Zufall, sondern Ein- und Ausschaltung nur über Helligkeitswert
Sieht erst einmal ganz einfach aus. Das alles in einem DOIF wurde mir (s.o.) zu komplex. Also werde ich das wohl wieder aufteilen müssen. Und die nicht ausgewählten Modi (= eigene DOIFs) deaktivieren. Dafür wird dann wieder ein DOIF benötigt. :-)
Performance-Probleme hatte ich auf einem RasPi2 übrigens noch nie. Wobei ich viele viele Trigger in meinen DOIFs habe.
Bei mir haben die meisten DOIF´s zwei, selten mehr als drei Zustände. Gleiche Aktionen sollten auch nur einen Zustand darstellen. Ich orientiere mich am zu schaltenden Device (output) und definiere dazu die Bedingungen (input). Besonders kritisch sind Definitionen mit vielen Zuständen und einem DOELSE-Fall. Dieser trifft öfters zu als man denken. Ich habe mich bei der Entwicklung an dem if-elseif-else Konstrukt orientiert, allerdings sind, nach zwei Jahren Erfahrung, DOIF-Konstrukte schwieriger zu durchblicken, weil wir hier mit Ereignissteuerung zu tun haben und durch Trigger, Quereinstiege der Normalfall sind (es beginnt nicht immer beim ersten if) ebenfalls werden nicht alle IF-Zweige ausgewertet, sondern nur die zum zugehörigen Trigger.
Wenn ich mal wieder Zeit finde, würde ich einen Web-basierten Generator programmieren, der aus einer tabellarischen Definition mit Hilfe einer Übergangstabelle (siehe https://de.wikipedia.org/wiki/Endlicher_Automat) ein DOIF generiert. Die Basis dafür, das Abfragen des eigenen Zustands mit $cmd, habe ich bereits geschaffen.
Gruß
Damian
Zitat von: FunkOdyssey am 14 Juli 2016, 08:40:12dann könnte ich mehrere DOIFs anlegen und diese je nach Modus disablen.
Zu Testzwecken mache ich das auch (sogar gleiche Zustände über verschiedene DOELSIF-Zweige :o), wenn alles läuft, packe ich die aber wieder zusammen. Ab und an sogar als "Endlichen Automaten".
Mein Modem z.B. reagiert dadurch unterschiedlich auf ein Ausschalten, je nachdem, ob es manuell erfolge (bleibt aus) oder weil kein Ping ins Internet mehr ging (reboot). Und das alles ohne extra Dummies oder so. In der Testphase bestand das Teil auch aus mehreren DOIF, Dummies und anderen Hilfkonstrukten (allein zum Anzeigen der Zwischenwerte). Aber inzwischen ein DOIF, drei PRESENCE, ein Device für die Steckdose und (noch, weil DOIF noch kein set kann) ein Dummy für die Bedienung am Tablet. Dafür hat das DOIF aber auch fünf Zweige mit zusammen neun Befehlssequenzen.
Wenn wir das hier Disable-Condition für DOIFs? (https://forum.fhem.de/index.php/topic,53208.msg449538.html) irgendwann hätte, wäre das Aufteilen in zig einzelne DOIF und das selektive Disablen/Enablen von DOIFs direkt einfacher. :-)
Der Code wäre übersichtlicher, da eine Zwischenebene zwischen Dummy und ausführendes DOIF eingespart wird.
Zitat von: FunkOdyssey am 19 Juli 2016, 16:31:30
Wenn wir das hier Disable-Condition für DOIFs? (https://forum.fhem.de/index.php/topic,53208.msg449538.html) irgendwann hätte, wäre das Aufteilen in zig einzelne DOIF und das selektive Disablen/Enablen von DOIFs direkt einfacher. :-)
Der Code wäre übersichtlicher, da eine Zwischenebene zwischen Dummy und ausführendes DOIF eingespart wird.
siehe hier:
https://forum.fhem.de/index.php/topic,55785.0.html
Gruß
Damian