Frage: Tagesablaufmodul

Begonnen von bugster_de, 22 Mai 2018, 10:05:50

Vorheriges Thema - Nächstes Thema

bugster_de

Hi,

ich brauche mal gedankliche Unterstützung wegen Knoten im Hirn.

ich habe in letzter Zeit meine FHEM Installation entrümpelt und einiges, was ich mir in den Anfangstagen von FHEM selbst in Perl Routinen umgesetzt habe nun auf die mittlerweile vorhandenen Standard FHEM Devices umgesetzt. ROOMMATE,GUEST,RESIDENTS etc. haben meine ganzen selbst gebauten Sachen ersetzt. Geht gut.
Allerdings bin ich auf der Suche nach, ich sage jetzt mal Tagesablauf-Steuerungen die abhängig vom Hausstatus sind nicht so ganz fündig geworden. HOMEMODE, YAAHM etc. sind nicht das was ich suche. Ich habe einen Schwung verschiedenster "Regler" im Einsatz, die quesi Tagesabläufe darstellen. Der komplexeste ist dabei die Rolladensteuerung, mit einem Perl Modul was mittlerweile fast 10.000 Zeilen hat. Die Steuerung funktioniert echt gut aber: sobald ich etwas ändern will, muß ich in den Perl Code. Das hat mich schon immer gestört und nun habe ich mal versucht, mir Gedanken zu einer Art Tagesablaufsteuerung als Modul zu machen. Inspiriert wurde ich durch die coole SVG Grafik des YAAHM Moduls (https://wiki.fhem.de/w/images/1/1b/YAAHM_widget_1.png).

Wenn ich meine Rolladensteuerung so durchschaue, dann habe ich im Prinzip folgende Arten von zeitgesteuerten Routinen (mal abstrakt betrachtet)

  • immer zu einem festen Zeitpunkt: also z.B. immer um 6:30h
  • immer zu einem festen Zeitpunkt, aber nur an bestimmten Tagen. Z.B. Werktags immer um 6:30h, Samstag um 9:00h, Sonntag um 10:00h. Feiertag wird als Sonntag behandelt, Brückentag wird als Samstag behandelt, wobei Feiertag und Brückentag aus meinem Owncloud Kalender kommen
  • zu einem variablen Zeitpunkt (also z.B. Schliessen bei sunset) aber frühestens um 17:00h und spätestens um 19:00h. Sprich wenn sunset zwischn 17:00h und 19:00h liegt, dann sunset. Wenn sunset nach 19:00h liegt dann 19:00h wenn sunset vor 17:00h liegt dann 17:00h.
    Der Zeitpunkt sunset ist je nach Jahreszeit unterschiedlich: im Sommer nehme ich sunset, im Winter ss_indoor
  • Routinen mit Zufallszeitpunkt: wenn wir im Urlaub sind öffnen und schliessen die Rolläden zu einem zufälligen Zeitpunkt, der in einem Zeitfenster liegt. Also Zufallszeit im Zeitraum zwischen 8:00h und 10:00h
  • sich wiederholende Routinen: diese werden in regelmässigen Abständen wiederholt (z.B. alle 30 Minuten) aber nur innerhalb eines Zeitfensters.
    Bsp: die Sonnenschutzautomatik wird zwischen 10:00h und 17:00h alle 30 Minuten ausgeführt. Falls die Bedingungen für die Sonnenschutzautomatik erfüllt sind (es scheint die Sonne und die Temperatur >
    25 Grad), dann Sonnenschutzautomatik aktiv und Routine wieder in 30 Minuten starten, falls es noch vor 17:00h ist

Die genannten Fälle der möglichen Routinenaufrufe sind meines Erachtens so auch für andere Regler wie z.B. Lichtsteuerung anwendbar. Ich kann mir zwar vorstellen, wie ein generalisiertes Modul (also kein 99_xx.pm, sondern ein Modul was man mit define anlegt) aussieht, mit dem man so was machen kann, frage mich aber, ob ich der erste bin, der so was braucht.

Ht schon mal jemand in der Richtung was gemacht?
Denke ich zu kompliziert und ich hätte in einem Bruchteil der Zeit, die ich für so ein Modul brauche, das Zeug nicht lieber per 99_xx.pm umgesetzt?
Oder wäre an Stelle so eines Tagesablaufmodul nicht ggf. ein Modul für einen Zustandsautomaten sinnvoller?







marvin78

Solche "Homemode" Module gibt es mittlerweile wie Sand am mehr.

Homemode, YAAHM, MSwitch und sicher noch mehr.

bugster_de

Tja, warum schreibe ich dann oben, dass diese Module meinen Anwendungsfall nicht abdecken? Ich habe die alle mal durch probiert, aber keines davon bringt mich dem Ziel näher, den ganzen Zoo aus automatisch generierten at und dummy zu entsorgen.

Ich sehe das genauso: es gibt eine ganze Menge dieser Module und eigentlich unterscheiden die sich die meisten nur in Nuancen. Mag für jedes Einzelne bestimmt gute Gründe geben und ich habe wenig Lust, dem nochmal ein Modul beizusteuern.
Vielleicht stelle ich deshalb meine Frage mal weniger abstrakt: eigentlich hat doch fast jeder FHEM User den Anwendungsfall, dass er Rolläden oder Licht automatisch entlang eines Tagesablaufs sowie entlang dem Hausstatus (Anwesend, Gäste, Party, Wetter, etc.) steuern will. Der in Perl nicht so versierte User hat dann jede Menge statischer at Definitionen gewürzt mit DOIFs oder sonstigem. Der in Perl versierte User hat dann mehr oder weniger komplexen Code. Aber ich befürchte mal, dass alle an der einfachen Frage scheitern, auf einen Blick zu sehen, wann denn die Rolläden morgen früh aufmachen oder wieder zu machen. Die bei YAAHM genierte Grafik ist schon cool!

marvin78

Man kann viel miteinander kombinieren. Ich denke tatsächlich, du denkst zu kompliziert.

Ich denke, wenn jemand EIN Modul benötigt, dass tatsächlich all SEINE Bedürfnisse abdeckt, muss er es selbst bauen. Ich verwende für alles mögliche eigene Module, teilweise auch mit eigenem Frontend. Bspw. kann unsere Steuerung für unsere Schildkröten, sicher niemand anderes in der Form gebrauchen, ist aber genau das, was wir benötigen (inklusive Planungs- und View-Frontend).

Meine Meinung: Wenn eine Rolladensteuerung Perl Code mit 10000 Zeilen benötigt, ist es zu kompliziert. In 10000 Zeilen passen aus meiner Sicht Steuerung UND Frontend und dann hat man noch mindestens 5000 Zeilen übrig...Warum daraus nicht ein Modul machen, dass man zumindest mit Attributen konfigurieren kann? Ein Frontend ist als weblink auch schnell eingebaut.

LR66

Vielleicht ein oder mehrere zentrale DOIF die bedarfsweise einfachere notify's aktivieren/disablen (oder auch at's alegen/modifizieren)???
So hab ich mir einiges zusammengestellt (z.B. einfache Alarmanlagenfunktionen), da mir einige der Module oversized oder für mich nicht passend waren. Allerdings ist DOIF ziemlich komplex geworden und ich brauch immer ganz schön Zeit um rauszukriegen, welches Atrribut für was geeignet und wie Events abgearbeitet werden bzw. warum was nicht so geht, wie gedacht...
Aber im Prinzip kann man es strukturiert darstellen und aufteilen...
Lutz

Byte09

Zitat von: bugster_de am 22 Mai 2018, 10:05:50
Hi,

ich brauche mal gedankliche Unterstützung wegen Knoten im Hirn.

ich habe in letzter Zeit meine FHEM Installation entrümpelt und einiges, was ich mir in den Anfangstagen von FHEM selbst in Perl Routinen umgesetzt habe nun auf die mittlerweile vorhandenen Standard FHEM Devices umgesetzt. ROOMMATE,GUEST,RESIDENTS etc. haben meine ganzen selbst gebauten Sachen ersetzt. Geht gut.
Allerdings bin ich auf der Suche nach, ich sage jetzt mal Tagesablauf-Steuerungen die abhängig vom Hausstatus sind nicht so ganz fündig geworden. HOMEMODE, YAAHM etc. sind nicht das was ich suche. Ich habe einen Schwung verschiedenster "Regler" im Einsatz, die quesi Tagesabläufe darstellen. Der komplexeste ist dabei die Rolladensteuerung, mit einem Perl Modul was mittlerweile fast 10.000 Zeilen hat. Die Steuerung funktioniert echt gut aber: sobald ich etwas ändern will, muß ich in den Perl Code. Das hat mich schon immer gestört und nun habe ich mal versucht, mir Gedanken zu einer Art Tagesablaufsteuerung als Modul zu machen. Inspiriert wurde ich durch die coole SVG Grafik des YAAHM Moduls (https://wiki.fhem.de/w/images/1/1b/YAAHM_widget_1.png).

Wenn ich meine Rolladensteuerung so durchschaue, dann habe ich im Prinzip folgende Arten von zeitgesteuerten Routinen (mal abstrakt betrachtet)

  • immer zu einem festen Zeitpunkt: also z.B. immer um 6:30h
  • immer zu einem festen Zeitpunkt, aber nur an bestimmten Tagen. Z.B. Werktags immer um 6:30h, Samstag um 9:00h, Sonntag um 10:00h. Feiertag wird als Sonntag behandelt, Brückentag wird als Samstag behandelt, wobei Feiertag und Brückentag aus meinem Owncloud Kalender kommen
  • zu einem variablen Zeitpunkt (also z.B. Schliessen bei sunset) aber frühestens um 17:00h und spätestens um 19:00h. Sprich wenn sunset zwischn 17:00h und 19:00h liegt, dann sunset. Wenn sunset nach 19:00h liegt dann 19:00h wenn sunset vor 17:00h liegt dann 17:00h.
    Der Zeitpunkt sunset ist je nach Jahreszeit unterschiedlich: im Sommer nehme ich sunset, im Winter ss_indoor
  • Routinen mit Zufallszeitpunkt: wenn wir im Urlaub sind öffnen und schliessen die Rolläden zu einem zufälligen Zeitpunkt, der in einem Zeitfenster liegt. Also Zufallszeit im Zeitraum zwischen 8:00h und 10:00h
  • sich wiederholende Routinen: diese werden in regelmässigen Abständen wiederholt (z.B. alle 30 Minuten) aber nur innerhalb eines Zeitfensters.
    Bsp: die Sonnenschutzautomatik wird zwischen 10:00h und 17:00h alle 30 Minuten ausgeführt. Falls die Bedingungen für die Sonnenschutzautomatik erfüllt sind (es scheint die Sonne und die Temperatur >
    25 Grad), dann Sonnenschutzautomatik aktiv und Routine wieder in 30 Minuten starten, falls es noch vor 17:00h ist

Die genannten Fälle der möglichen Routinenaufrufe sind meines Erachtens so auch für andere Regler wie z.B. Lichtsteuerung anwendbar. Ich kann mir zwar vorstellen, wie ein generalisiertes Modul (also kein 99_xx.pm, sondern ein Modul was man mit define anlegt) aussieht, mit dem man so was machen kann, frage mich aber, ob ich der erste bin, der so was braucht.

Ht schon mal jemand in der Richtung was gemacht?
Denke ich zu kompliziert und ich hätte in einem Bruchteil der Zeit, die ich für so ein Modul brauche, das Zeug nicht lieber per 99_xx.pm umgesetzt?
Oder wäre an Stelle so eines Tagesablaufmodul nicht ggf. ein Modul für einen Zustandsautomaten sinnvoller?

ich kenne die anderen module jetzt nicht wirkjlich , kann aber mit sicherheit sagen , dass ich die komplette Steuerung mit deinen Vorgaben in einem MSwitch - Device unterbringe ( augenommen das: Also Zufallszeit im Zeitraum zwischen 8:00h und 10:00h -wäre aber unproblematisch zu implementieren )

gruss Byte09

bugster_de

Hi,

Danke ür euer Feedback. Vermutlich ist eine Generalisierung tatsächlich überspoilert. Ich habe mir das mswitch heute abend nochmal genauer angesehen und das geht tasächlich in meine Richtung.

Da ich meine Rollosteuerung eh umbauen muß mache ich mal zwei Sachen
mswitch auf dem Test FHEM durchnudeln
ein neues Modul für mich anfangen, welches dann acuh eine vernünftige Anbindung an Alexa ermöglicht.