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
