[DaySchedule] Tagesablaufplanung und Tagesstatus

[Loredo]

Hallo,


wie zuvor im Astro Thread erwähnt, habe ich die von mir geplanten Funktionen nun in ein eigenes Modul namens DaySchedule ausgelagert.
Dabei sind nun auch weitere Funktionen hinzugekommen, die ursprünglich auch nicht für Astro vorgesehen waren. Das Modul ist nun auf einem Entwicklungsstand, bei dem ich gerne Rückmeldungen von Testern hätte. Man kann es derzeit nur über Github laden und muss es selbstständig installieren und aktualisieren. Es ist also derzeit nichts für Ungeübte, bis das Modul über das SVN offiziell verteilt wird.
Freiwillige, die bei der Dokumentation helfen, sind ebenfalls gerne gesehen 




Also, was macht das Modul nun?


DaySchedule ermöglicht die vorausschauende Planung eines Tages sowie die Unterteilung eines Tages in Abschnitte, so dass man darauf basierende Automationen programmieren kann. Diese Tagesabschnitte basieren auf den Sonnenauf- bzw. Untergangszeiten von Astro und sind daher über das Jahr weg variabel. Das bedeutet, man kann seine Automationen damit auch losgelöst von festen Uhrzeiten anstoßen, sind aufgrund der relativen Tageszeit wie zum Beispiel Vormittag, Mittag, Nachmittag ... In der Standardeinstellung wird der Tag in 2x zwölf gleiche Teile eingeteilt, eben ausgehend vom Sonnenauf- und Untergang. Das haben schon die alten Römer mit ihren Sonnenuhren so gemacht und nannten es "Temporale Stunden", ich habe das Rad also nicht neu erfunden. Die Römer haben ihren Tag an der Sonne ausgerichtet, was liegt also näher als dass man bestimmte Hausautomationen auch wieder auf dieses Prinzip zurückführt und nur dort feste Uhrzeiten hernimmt, wo es für den gesellschaftlich getakteten Tag notwendig ist? Jeder der 12 temporalen Stunden am Tag und in der Nacht sind Namen zugeordnet, so dass man auch eine hübsche Anzeige bekommt. Natürlich werden mehrere Sprachen unterstützt: EN, DE, FR, ES, IT, PL, NL.


Weiterhin stellt DaySchedule eine dritte Jahreszeit bereit, die Phänologische Jahreszeit. Zum einen gibt es hier eine feinere Einteilung in 10 statt nur 4 Jahreszeiten, weshalb man eine genauere Steuerung darüber machen kann. Zum anderen sind die Übergänge von Winter>Frühling und Sommer>Herbst dynamisch aufgrund der Geo-Position des Hauses berechnet (funktioniert nur innerhalb von Zentraleuropa). Es ist also keine wahrhaftige Phänologische Jahreszeit, denn dabei würde man ja normal ständig schauen, welche Pflanzen blühen etc - darauf hat aber sicher niemand Lust, der sich um die Hausautomation bemüht 
Also folgt die Berechnung der Annahme, dass der Frühling bzw. der Herbst an jeweils einem bestimmten äußeren Punkt in Europa (Portugal und Finnland) startet und der Frühling bzw. Herbst sich dann mit etwa konstanter Geschwindigkeit von 40 km pro Tag auf den eigenen Standort bewegt. Erst wenn Frühling bzw. Herbst den eigenen Standort erreicht haben, ist dann tatsächlich Vollfrühling bzw. Vollherbst. Die nachgelagerten Abschnitte "Spätfrühling" und "Spätherbst" folgen dann nach einer Weile und schließlich ist dann Sommer oder Winter zu dem Zeitpunkt, an dem der Frühling/Herbst am Zielpunkt Portugal/Finnland angekommen ist.
Derzeit gibt es wohl noch einen Bug bei den Übergängen, da muss ich wohl nochmal ran. Ich wollte aber die Theorie hier trotzdem mal erklären.
Dabei auch der Aufruf: Ich bin kein Mathematiker und wäre dankbar für jede Hilfe, die mir jemand bei der Berechnung zukommen lassen könnte. Bestimmt kann man das ganze besser machen als eine simple lineare Berechnung mit ausgetüftelten Fixwerten. Wer sich dafür berufen fühlt ist herzlich eingeladen zu helfen 


Als nächstes gibt es Unterstützung für verschiedene Saisons oder auch "Annual FestivitiesEvents" bzw "Social Seasons". Der Begriff einer "Saison" ist im Deutschen sicherlich geläufig, in den anderen Sprachen fällt es mir schwer bessere Begriffe zu finden. Gemeint ist aber, dass es ja noch sowas wie die "5. Jahreszeit" gibt, also Karneval/Fasching oder die Starkbierzeit mit ihrem Starkbierfest. Aber auch Oktoberfest, Osterzeit, Jahreswechsel etc. All diese Saisons mögen bei dem ein oder anderen eine bestimmte Rolle spielen und neben der puren Anzeige kann man natürlich auch Automationen darauf basieren lassen. Lichtstimmungen beispielsweise könnten in der Adventszeit anders aussehen als zu Weihnachten oder während des Jahreswechsels. Oder man möchte während der Karnevalszeit gerne bestimmte Bilder auf einem Bilderrahmen anzeigen oder auf der LaMetric - sowas alles eben. Ich habe auch versucht dabei verschiedene Ausprägungen zu berücksichtigen, so sie denn für eine breitere Masse sinnvoll sein könnten. Ein gutes Beispiel ist, dass manche schon vor dem 1. Advent in Adventsstimmung sind, andere erst genau ab dem 1. Adventssonntag.


Zu guter Letzt gibt es noch Unterstützung für die Kategorisierung des Tages in die Kategorien Arbeitstag, Wochenende, Feiertag und Urlaubstag. Das globale FHEM Attribut "holiday2we" zusammen mit IsWe()/$we wird dabei unterstützt, ebenso die neusten Änderungen im Bezug auf Wochenenddienst. Allerdings hat DaySchedule auch eine eigene, alternative Logik eingebaut, bei der man nicht mit bestimmten Codewörtern arbeiten muss, sondern ein dediziertes holiday-Device oder sogar auch ein Calendar-Device für die Hinterlegung des Schichtplans nutzen kann. Wenn man das macht, dann können an Arbeitstagen auch Samstag/Sonntag als Arbeitstage markiert werden. Freie Tage unter der Woche werden dann als "Wochenende" behandelt. In der Darstellung bzw. dem Namen werden sie allerdings von regulären Samstag/Sonntag Wochenenden dadurch unterschieden, dass der Tagestyp dann als "Freizeit" bezeichnet wird. Hat man an einem Samstag/Sonntag frei, dann heißen diese Tage natürlich trotzdem Wochenende und nicht "Freizeit". Wer Schichtarbeit macht wird wahrscheinlich wissen, was ich meine 
DaySchedule hat außerdem alle Feiertage in Deutschland direkt hinterlegt (in allen Sprachen, im Gegensatz zu den .holiday-Dateien, die das 95_holiday Modul verwendet). Diese werden auch als Beschreibung für den jeweiligen Tag angezeigt, haben aber erstmal grundsätzlich keinen Einfluss auf den Tagestyp (sprich, der Tagestyp wird dadurch nicht automatisch zu "Feiertag"). Man kann allerdings nun explizit eines oder mehrere Holiday Devices hinterlegen, bei denen die selben Tage hinterlegt sind (also so, wie man das bei holiday2we heute auch schon macht). Erst dann wird der Tagesstatus auch ein "Feiertag". Wenn der Beschreibungstext übereinstimmt, wird er auch nicht doppelt angezeigt. Damit kann man immer wissen, welcher Feiertag heute ggf. auch woanders ist für den Fall, dass man dort mit Leuten zusammenarbeitet. Über ein Attribut lässt sich steuern, ob welche Feiertage man angezeigt bekommen möchte. Man kann auch "none" angeben und dann ist alles abgeschaltet und man verlässt sich nur auf holiday- oder Calendar Devices, wenn man das möchte.


Eine weitere Spezialität ist, dass man den Wechsel Normalzeit<>Sommerzeit angezeigt bekommt (inkl. Richtung  ). Außerdem kann man bereits am Vortag auswerten, ob am folgenden Tag eine Umstellung sein wird. Neben einer einfachen Erinnerungsfunktion lassen sich also auch Automationen an diesen beiden Tagen vor und nach der Umstellung explizit triggern.






There is one more thing...


Die vorausschauende Planung hatte ich oben ja schon erwähnt. Gemeint ist, dass man zu jedem beliebigen Datum oder Uhrzeit springen und schauen kann, welcher Status für diesen Zeitpunkt berechnet werden wird und welche Events über den Tag verteilt wann eintreten werden (zum Beispiel wann die Mittagszeit anfängt). Mir war dabei die Darstellung im Browser wichtig. Über ein weblink Device kann man diese auch auf jeder FHEM Raumseite einblenden, ein entsprechend vorkonfiguriertes weblink Device für den aktuellen Tag kann automatisch angelegt werden.
Wie das ganze aussieht, zeigen die angehängten Screenshots.




Soweit dann erstmal... happy testing!




Viele Grüße
Julian

[Kummer]

Hallo,

das klingt sehr interessant. Ich bin zwar die nächste Woche im Urlaub, aber danach werde ich es direkt testen.

Gruß

[CQuadrat]

Hallo Julian,

sehr schön: da ist sowohl einiges drin, was ich schon durch diverse dummys, DOIFSs, etc. gelöst habe, als auch das ein oder andere, was in meiner Ideen-Pipeline ist. Ich werde es mir im jeden Fall ansehen.

Beim ersten Durchlesen ist mir auch schon gleich ein Feature-Wunsch gekommen :
Bei der Kategorisierung des Tages in die Kategorien Arbeitstag, Wochenende, Feiertag und Urlaubstag fehlt mir so etwas wie die Kategorie "Home Office": bei einem "normalen" Arbeitstag bin ich außer Haus; bei Home Office aber zuhause, so dass dann z.B. das Büro (im Winter) geheizt werden muss.

Weiteres Feedback folgt, wenn ich das Modul installiert habe...


Viele Grüße

Christoph

[Loredo]

Ich antworte hier mal auf einen Beitrag aus einem anderen Thread:

Ohne mich jetzt im Detail mit den Optionen von diesem neuen Modul DaySchedule befaßt zu haben und dem, was mit "Wert von IsWe() an einem bestimmten Tag navigieren" gemeint ist:

Nach meinem Eindruck (!, muß also nicht richtig sein), sollte man den Code von IsWe() nicht noch weiter aufbohren.
Da Calendar ein sehr flexibles Tool ist, aber state seit langem nicht "none" liefert, ist es insbesondere kaum möglich, ein Calendar-Device im Rahmen von h2we sinnvoll zu verwenden (für gestern und morgen ggf. schon, wenn man - über welche Logik auch immer - passende Readings erzeugt). Was aber - wenn man die richtigen Parameter wählt - recht einfach ist, ist eine holiday-Datei zu erzeugen (jetzt mit yyyy-mm-dd vielleicht sogar noch einfacher), und die "ganz normal" einzubinden.
Hast du vor, da eine Art automatischen Export einzubauen? Oder soll das Modul einen passenden "state" haben und "klassisch" wie ein "normales" holiday-Device abfragbar sein?

Der Code von IsWe() ist auch nicht weiter aufgebohrt, es ist eben in ein eigenes Modul verlagert bzw. erweitert.
Mit Navigieren meine ich erstmal nichts anderes als eine Alternative zum Eingeben von {IsWe('YYYY-MM-DD')} in der FHEM Kommandozeile. Wenn man in DaySchedule nichts besonderes einstellt, dann wird mit IsWe() gearbeitet und man kann etwas komfortabler sehen, was meine globalen holiday2we Einstellungen über das Jahr bewirken werden.


Wie du richtig sagst, in holiday2we kann man eben kein Calendar Device hinterlegen, in den DaySchedule Attributen HolidayDevices, InformativeDevices, VacationDevices, WorkdayDevices, WeekendDevices aber schon.


DaySchedule hat keinen Export, sondern generiert daraus das Reading "DayType". Ggf. baue ich noch eine Funktion analog zu IsWe() in DaySchedule ein, damit man es in der selben Art und Weise als Alternative verwenden kann.

[Loredo]

Beim ersten Durchlesen ist mir auch schon gleich ein Feature-Wunsch gekommen :
Bei der Kategorisierung des Tages in die Kategorien Arbeitstag, Wochenende, Feiertag und Urlaubstag fehlt mir so etwas wie die Kategorie "Home Office": bei einem "normalen" Arbeitstag bin ich außer Haus; bei Home Office aber zuhause, so dass dann z.B. das Büro (im Winter) geheizt werden muss.

Das als Tagestyp anzusehen macht in meinen Augen keinen Sinn, da es um die Reine Anwesenheit geht. Ob du an einem Arbeitstag zuhause bist oder nicht sollte deine Heizung steuern, und nicht welchen Tagestyp du hast

[Frank_Huber]

Das als Tagestyp anzusehen macht in meinen Augen keinen Sinn, da es um die Reine Anwesenheit geht. Ob du an einem Arbeitstag zuhause bist oder nicht sollte deine Heizung steuern, und nicht welchen Tagestyp du hast

Macht eventuell doch Sinn:
- andere Wckzeiten da der Weg wegfällt
- andere Zimmer heizen.
- evtl PC hochfahren etc

[Loredo]

Ich muss da mal drüber nachdenken.
Noch ist nicht klar wie die Verbindung zu ROOMMATE (RESIDENTS) und ROOMSTATE (HOMESTATE) aussehen wird, sprich ob es sich bei einem DaySchedule Device eher um ein persönliches Device im Sinne von "jeder Bewohner hat sein eigenes Device" handelt oder ob es sich um ein räumlich bezogenes Device handelt. Man vergisst immer schnell, dass es nicht nur Single Haushalte gibt, bei denen immer alles so einfach erscheint


Edit: Da der Tagestyp ja über ein holiday und/oder Calendar Device gesteuert wird, sind es eigentlich diese Eingangsgrößen, die du in deiner Anwesenheitssteuerung mit der Heizung, dem Wecker, etc. berücksichtigen solltest. Der Tagestyp ist und bleibt davon unberührt, denn DaySchedule soll sich eigentlich mehr auf kalendarische Zusammenhänge fokussieren, nichts was mit Anwesenheit zu tun hat.

[CQuadrat]

Da ist genau das Problem: wie grenzt man das zu ROOMMATE, etc. ab.

Auch ein Urlaubstag am Meer ist etwas anderes als ein Urlaubstag zuhause.

[Loredo]

Da ist genau das Problem: wie grenzt man das zu ROOMMATE, etc. ab.

Auch ein Urlaubstag am Meer ist etwas anderes als ein Urlaubstag zuhause.

Siehe editierter Beitrag oben. ROOMMATE/-STATE sollte auf das selbe Calendar und/oder Holiday Device zugreifen und seine eigenen Rückschlüsse dann für das Thema Anwesenheit und "Raumstatus" ableiten. So wird ein Schuh draus.


Also, damit wird auch klar, dass DaySchedule eher einen räumlichen Bezug haben wird. So war das auch von mir gedacht, dass jeder Raum sein eigenes DaySchedule Device haben kann, wenn man die Wohnung oder das Haus nicht als ganzes behandeln möchte.

[Frank_Huber]

fair comments.
dem ist nichts mehr hinzuzufügen.

[rischbiter123]

Moin,

ich wollte das Modul gerade installieren, bekomme aber nach einem reload Modul folgende Meldung:

Code Auswählen Erweitern

"timelocal_modern" is not exported by the Time::Local module
"timegm_modern" is not exported by the Time::Local module
Can't continue after import errors at ./FHEM/95_DaySchedule.pm line 33.
BEGIN failed--compilation aborted at ./FHEM/95_DaySchedule.pm line 33.

Es fehlt mir wohl ein Perl-Modul, leider erkenne ich nicht, welches. Im log erscheint auch bei verbose 5 nichts dazu.

LG

Andreas

[andies]

Kurze Frage: Ich hatte für vergleichbare Ziele bisher auch YAAHM im Kopf. Wo sind da Unterschiede und Erweiterungen?

[Loredo]

Kurze Frage: Ich hatte für vergleichbare Ziele bisher auch YAAHM im Kopf. Wo sind da Unterschiede und Erweiterungen?

YAAHM kennt keine Temporalen Stunden, hat keine phänologische Jahreszeit und ist generell nicht auf kalendarische Inhalte fokussiert. Auch gibt es keine Unterstützung für die saisonalen Sitten und Gebräuche. Außerdem liegt es administrativ bei pah und Zusammenarbeit bei größeren Vorhaben gestaltet sich schwierig (siehe Änderungshistorie bei Astro).


DaySchedule ist spezialisierter und wird keine Unterstützung bei Automationen wie YAAHM liefern, das wird es in HOMESTATE und Co geben, welche dann darauf spezialisiert sind Räume, Zonen und das Haus bzw. die Wohnung zu definieren. Das Konzept gibt es seit 20162017 bereits vor der Entstehung von YAAHM und ist modularer angelegt als YAAHM. Es spricht aber technisch nichts dagegen, dass YAAHM mit einem DaySchedule Device zusammenarbeiten könnte.

ich wollte das Modul gerade installieren, bekomme aber nach einem reload Modul folgende Meldung:

Code Auswählen Erweitern

"timelocal_modern" is not exported by the Time::Local module
"timegm_modern" is not exported by the Time::Local module
Can't continue after import errors at ./FHEM/95_DaySchedule.pm line 33.
BEGIN failed--compilation aborted at ./FHEM/95_DaySchedule.pm line 33.

Es fehlt mir wohl ein Perl-Modul, leider erkenne ich nicht, welches. Im log erscheint auch bei verbose 5 nichts dazu.

Offenbar sind diese Funktionen nur in neueren Perlversionen verfügbar, ich hatte nicht erwartet, dass sie _so_ neu sein muss
Ich passe das bei Gelegenheit für ältere Perl Versionen an.

[rischbiter123]

Moin,

Nur als Info. Bei mir läuft (noch) Stretch mit Perl-Version 5.24.1.

LG

Andreas

[Loredo]

Ich habe eine aktualisierte Version eingecheckt, die mit älteren Perl Installationen kompatibel sein sollte.