doif: 1)Fehler im LOG 2)FHEM nach Ausführung Probleme zu haben 3)sleep.

[matzke]

bei entsprechender Definition löscht sich ein at sowieso selbst.

Ich finde, Du hast die völlig falschen Denkansätze FHEM ist keine Codewurm oder Wegwerfsystem...

Ich habe nicht verstanden was an "Damit ich nicht für 2-3 Ladegeräte, ein TV, ein PC usw. " diesen Schwurbel rechtfertigen soll?
Warum muss man z.B. eine Überwachungsschaltung für ein Ladegerät nach einmaligem Gebrauch wegwerfen? Weil es kein Pfandsystem gibt?

Na, ich habe halt die Vorstellung:
- Geräte (Hardware) anlegen und nur eine doif zu ordnen.
- Die doif hat jeweils den gleichen Aufbau und ruft eine Haupt-Sub() auf mit Übergabe von $Evend $Device $Self usw. (Also die doifs brauchen praktisch keine Pflege)
- Die Haupt-Sub ruft je auslösendem Gerät und Event im optimalen Fall standartisiert Untersubs auf, falls notwendig spezielle Untersubs oder führt Minitasks gleich selbst aus.

Ergebnis für mich als Laie:
- schmales, übersichtliches FHEM, aber eher umfangreiches Perl,
- keine weiteren Dinge in FHEM pflegen müssen,
- empfunden schnellers Umbauen mit Perl, da ich im Moment ständig ein Gerät wegnehme oder hinzufüge, umfunktioniere oder Funktionen anpasse.
- irgendwann muss FHEM einfach mal laufen. Und da glaube ich, wenn ich nach dann nach einem halb Jahr wieder mal was ändern muss, ist Perl übersichtlicher.

Tja, ob dem wirklich mit allem so ist oder alles "schwurbel" ist, weiß ich nicht, da ich erst kurze Zeit mit FHEM befasse. Ich dachte aber ernsthaft, dass ihr Profis das so macht.

[Otto123]

FHEM ist ein Perl Server für die Haustechnik. Mit FHEM können verschiedene Aufgaben wie z.B. das Schalten von Lampen, die Steuerung von Jalousien oder Heizkörpern und vieles mehr im Haushalt automatisiert werden.

DOIF (ausgeprochen: du if, übersetzt: tue wenn) ist ein universelles Modul mit Web-Interface, welches ereignis- und zeitgesteuert in Abhängigkeit definierter Bedingungen Anweisungen ausführt.
Mit diesem Modul ist es möglich, einfache wie auch komplexere Automatisierungsvorgänge zu definieren oder in Perl zu programmieren.

Geräte (Hardware) anlegen und nur eine doif zu ordnen.

Meine Gedanken dazu:
FHEM ist der Automatisierungsserver
DOIF ist eine Art eigener Automatisierungsserver innerhalb FHEM
Du willst jetzt den Automatisierungsserver im Automatisierungsserver im Automatisierungsserver schreiben? Der Gedanke ist mir zu abwegig. Ich wünsche Dir Erfolg.
Aber eigentlich würde ich mir wünschen Du würdest versuchen zu verstehen wie FHEM verwendet werden kann. Wenn dann noch eine Aufgabe nicht gelöst werden kann, könntest Du Dir eine PerlSub schreiben

[Damian]

Ich würde mich für eine Welt entscheiden. Entweder du arbeitest mit notify, at, sleep und Perl oder du nimmst DOIF und Perl. Beide Welten kann man natürlich mischen, aber da muss man sich auf die Dauer in beide Welten tief einarbeiten, zumal man dann mit kleinen aber feinen Unterschieden der beiden Welten immer wieder zu kämpfen haben wird.

[matzke]

oder du nimmst DOIF und Perl.

Ja genau das habe ich ja gemacht. Mich für DOIF und Perl nach einigen Tagen überlegen entschieden. DOIF erschien mir mächtiger als notify, also "zukunftsicherer" mit dem ich später auf Feinheiten mal reagieren kann und Perl dazu, wie man im Forum liest "die Ordungsmacht", was ich auch jetzt schon bestätigen würde.

Das klappt im Zusammsmspiel DOIF + Perl auch soweit ganz gut. Schalten auf Ereignisse kein Problem.

Es gab dann gleich zwei, drei Herausforderungen:
1) Wie aus Perl heraus zu einem spätere Zeitpunkt eine Aktion ausführen und nicht sofort starten? Antwort: Mit Perl in FHEM ein at anlegen.
2) Wie aus Perl heraus auf ein späteres zu erwartendes Ereignis reagieren? Antwort: Mit Perl ein Sleep mit Ereignisüberwachung anlegen.
3) Wie aus Perl heraus auf ein später zu erwartendes Ereignis mit Bedingungen reagieren? Antwort: Keine Lösung.

Zu 3) will ich erstmal lösen mit einem at und if, welches dann halt alle t prüft und nach Eintritt sich selbst löscht. ist nur suboptimal, aber ok.


D.h. obwohl ich mich für DOIF und Perl klar entschieden hatte, kam ich gleich doch in die Verlegenheit auch at und Sleep dennoch nutzen müssen. Da at und Sleep sich wieder löschen, fand ich das auch ok. Fhem bleibt damit schlank und schön überschaubar.

[Damian]

Es gab dann gleich zwei, drei Herausforderungen:
1) Wie aus Perl heraus zu einem spätere Zeitpunkt eine Aktion ausführen und nicht sofort starten? Antwort: Mit Perl in FHEM ein at anlegen.
2) Wie aus Perl heraus auf ein späteres zu erwartendes Ereignis reagieren? Antwort: Mit Perl ein Sleep mit Ereignisüberwachung anlegen.
3) Wie aus Perl heraus auf ein später zu erwartendes Ereignis mit Bedingungen reagieren? Antwort: Keine Lösung.

Zu 1) set_Exec verwenden
Zu 2) set_Exec verwenden
Zu 3) set_Exec verwenden

Alles andere führt zum Spagetti-Code, ähnlich goto, der schwer pflegbar ist: Modul 1 ruft Modul 2 auf, Modul 2 ruft Modul 1 auf ....

Zu Generalisierung, sprich ein Modul mit einer Steuerung für mehrere Szenarien (Sensoren, Aktoren), habe ich dir bereits einen Link aufgezeigt.

[Per]

Man kann auch mit einer "sinnvollen" Namensgebung und $DEVICE arbeiten. Dann reicht ein DOIF.
Und/oder Schaltschwellen und Namen der Aktoren in Readings der zu überwachenden Devises hinterlegen. Klappt bei mir prima.