Betatester für neues Modul AutoShuttersControl gesucht!

[kjmEjfu]

Urlaube sollte man anders abfangen, zumal da der Ort ein anderer sein kann und daher eine automatisierte Erkennung durch irgendeinen Code erklärungsbedürftig für den Ersteller der Kalendereinträge wäre.

deshalb ist halt die Frage, wie man das generell abfängt.

Letztlich gibt es ja verschiedene Gründe, weshalb jemand zuhause bleibt:
- Ferien (betrifft schulpflichtige Kinder und tlw. Lehrer)
- Urlaubstage
- bewegliche Ferientage
- Krankheitstage
- Schichtdienst
- Feiertag
- ...

Vermutlich hat jeder da seine ganz eigene Logik, was an solchen Tagen passieren soll.
Von daher macht es aus meiner Sicht Sinn, wenn jeder - mit welchem Mittel auch immer - selber dafür verantwortlich ist, dass im jeweiligen Rollo ein entsprechendes Reading auf 0 oder 1 steht.

Idee: Wenn die normale Neuberechnung läuft, dann wird Reading am Device (oder wenn nicht gesetzt am ASC-Device) ausgewertet (0 oder 1) und entsprechend früh oder spät gefahren. Zusätzlich prüft das Modul über sich das Reading ändert (Event) und führt in dem Fall eine nachträgliche Anpassung durch.

[kjmEjfu]

An sich war ich aber mal der Ansicht, dass dafür die states der Residents da sind (insbes. asleep), was jeweils zum Ausführungszeitpunkt berücksichtigt werden sollte.

stimmt, aber letztlich könntest der Resident auch nur deshalb "asleep" sein, weil er verpennt hat. Da würde das hochfahrende Rollo eventuell als Notwecker helfen 

[Beta-User]

Vermutlich hat jeder da seine ganz eigene Logik, was an solchen Tagen passieren soll.

Grundsätzlich sehe ich das auch so. Aber wer $we nutzt und darüber bzw. über holiday2we zentrale Vorgaben macht, sollte erwarten dürfen, dass das schlicht und einfach so, wie es überall Auswirkungen hat auch hier beachtet wird; das ist eine zentrale FHEM-Funktionalität. Aus diesem Grund bin ich etwas vergrätzt, wenn das irgendwie in Frage gestellt wird, sondern adressiere die klare Erwartung, dass es hier nicht erforderlich wird, dafür nochmal einen Würgaround zu kreieren.
Die betreffende Info sollte dementsprechend auch zentral für alle Rolläden beachtet werden.

Alles andere kann man diskutieren, was die Bewertung sonstiger Sachverhalte angeht, völlig korrekt. Nur, wenn jemand aus einem Ferien- oder Urlaubstag oder einer Spätschicht ein $we macht, ist das eben eine Wahl, die vor allem anderen beachtlich ist. 

Was also Urlaube (stellvertretend für alle anderen ggf. auftretenden voraussehbaren Abweichungen) angeht:
Wer einen Urlaubstag wie einen $we-Tag behandelt wissen will, ohne dafür eine (auch für alle anderen Mitbewohner gültige!) holiday-file zu editieren, sollte nach meiner Ansicht die Option haben, den morgigen Status zur Berücksichtigung _global oder individuell am einzelnen Rolladen_ irgendwo hin zu schreiben. Das Befüllen mag dann jeder so machen, wie er das für richtig hält.

Und ob und inwieweit "asleep" zwangsweise unterbrochen werden sollte, ist m.E. auch woanders festzulegen. Von ASC wünsche ich mir jedenfalls keine Zwangsbeglückung in diese Richtung, und sei sie noch so angebracht .

Just my2ct.

[CoolTux]

Ich habe es nun so gebaut das we berechnet und we2holiday beachtet wird. Ausserdem ist es möglich ein Device an zu geben welches 0 oder 1 für Urlaub oder Ferien bereit hält.

[Beta-User]

Ich habe es nun so gebaut das we berechnet und we2holiday beachtet wird. Ausserdem ist es möglich ein Device an zu geben welches 0 oder 1 für Urlaub oder Ferien bereit hält.

Danke!

Device-STATE oder Reading am Device? (Device:Reading wäre m.E. optimal).

Das ist dann eine zentrale Vorgabe für die Installation, oder?

[CoolTux]

Danke!

Device-STATE oder Reading am Device? (Device:Reading wäre m.E. optimal).

Das ist dann eine zentrale Vorgabe für die Installation, oder?

Reading state

Wie meinst das mit zentrale Stelle?

[Beta-User]

Reading state

Was spricht gegen Device:Reading? Das zusätzliche split?
Ich fände das auf Reading-Basis besser, ich mag einfach die vielen Dummys (und Event-Handler) nicht, die man sonst benötigt, nur um irgendwas von irgendwo nach nirgendwo umzupacken. Sollte man den Leuten beibringen, dass das mit etwas Intelligenz vermieden werden kann .
(Darf ich nochmal an das Temperatur-Dinges erinnern; auch da wäre es kein Hexenwerk, die zwei Attribute zu einem zusammenzuführen... Sollte halt einheitlich sein).

Wie meinst das mit zentrale Stelle?

Wenn das hier gemeint ist:

Das ist dann eine zentrale Vorgabe für die Installation, oder?

Will nur heißen: Diese Geräteangabe ist am ASC-Device zu setzen und betrifft (wie $we) alle Rollläden, die Angabe ist nicht in jedem einzelnen Rollladen zu machen bzw. möglich (wer stattdessen das will, soll seinen Resident schlafen legen ).

[CoolTux]

Ich Dummerschen. Kann mir das ganze ja sparen mit tomorrow. Ich setze das Device für Urlaub oder so (so wie Du gesagt hast) am Moduldevice und reagiere dann einfach auf den Event der Mitternacht kommt oder nicht.
Das Split Thema überlege ich mir noch. Hat ja noch Zeit.

[Beta-User]

Na ja, was holiday (2we) angeht, kann tomorrow schon heute berücksichtigt werden bei der Berechnung der neuen Timer. Ist also früher aktuell. Aber notifyDev auch auf das zusätzliche Device zu legen, kann jedenfalls bereits um Mitternacht zur Neuberechnung führen (aber Achtung, da sollte dann $we direkt berücksichtigt werden, nicht mehr holiday:tomorrow).

Die Änderung von $we wirft keine Events, jedenfalls, soweit mir bekannt. Das muß man also anders abfrühstücken.

[CoolTux]

Na ja, was holiday (2we) angeht, kann tomorrow schon heute berücksichtigt werden bei der Berechnung der neuen Timer. Ist also früher aktuell. Aber notifyDev auch auf das zusätzliche Device zu legen, kann jedenfalls bereits um Mitternacht zur Neuberechnung führen (aber Achtung, da sollte dann $we direkt berücksichtigt werden, nicht mehr holiday:tomorrow).

Die Änderung von $we wirft keine Events, jedenfalls, soweit mir bekannt. Das muß man also anders abfrühstücken.

Meine Aussage bezog sich nur auf das selbst angelegte Dummydevice welches über ein notify gefüttert wird welches wiederum einen ical Kalender auswertet.
Kannst du mir kurz einen Link geben für holiday und holiday: tomorrow? Aktuell lese ich lediglich das global Attribut aus. Mit den Events muss ich erst noch schauen.

[Beta-User]

Nur das globale Attribut auszulesen, dürfte nicht ganz genügen, aber ein Stück code sagt mehr als 1000 Worte, oder?

Aus fhem.pl:

Code Auswählen Erweitern

1091      my $we = (($wday==0 || $wday==6) ? 1 : 0);
1092      if(!$we) {
1093        foreach my $h2we (split(",", AttrVal("global", "holiday2we", ""))) {
1094          my ($a, $b) = ReplaceEventMap($h2we, [$h2we, Value($h2we)], 0);
1095          $we = 1 if($b && $b ne "none");
1096        }
1097      }
Ansonsten steht eigentlich das meiste zu holidy und holiday2we in der CR:
https://fhem.de/commandref.html#holiday2we
https://fhem.de/commandref.html#holiday

Zusammenfassung: Man kann als globales Attribut ein oder mehrere holiday-Devices angeben (Komma-getrennt); jedes der Devices hat einige Readings mit Namen state, tomorrow und yesterday. Wenn nix ist, ist der Wert "none", also sollte sich das auf Nicht-"None" abfragen lassen, wobei man eben eine loop braucht, die über alle holiday-Devices geht (bis eines einen Treffer bringt, ähnlich dem oben, nur deutlich kürzer).

Ansonsten habe ich am WE etwas gebastelt, um den ical in holiday umzuwandeln : https://forum.fhem.de/index.php/topic,85759.msg836582.html#msg836582.
Dann gab es am WE auch einen Thread, in dem es um eine Nachtschicht ging, bei der auch "auf die Zukunft" abgefragt wurde. Sowas könntest du auch in ein at packen, um dann den "tomorrow"-Stand des Dummy gleich richtig zu setzen (würde die setList und readingList dann für den (zusätzlichen) Dummy so gestalten wie das bei den holidays auch der Fall ist). Code war hier. Sowas fände ich als generelle Funktionalität (optional) nicht schlecht, könnte man in die Begleit-Doku packen.

[CoolTux]

Nur ganz kurz. Den Code hatte ich mir schon heute Nachmittag geborgt, bin nur nicht zum weiter auswerten gekommen 
Ich schaue es mir morgen in Ruhe an.

[Beta-User]

Code Auswählen Erweitern

my $wetomorrow = (($wday==5 || $wday==6) ? 1 : 0);
if(!$wetomorrow) {
   foreach my $h2we (split(",", AttrVal("global", "holiday2we", ""))) {
     my ($a, $b) = ReplaceEventMap($h2we, [$h2we, ReadingsVal($h2we,"tomorrow","none")], 0);
     $wetomorrow = 1 if($b && $b ne "none");
   }
}
Auf die Schnelle so?

[CoolTux]

Version 0.1.48 habe ich soeben ins Git geladen.
Unterstützt wird nun Wochenendsteuerung über das Rolladen Attribut AutoShuttersControl_Time_Up_WE_Holiday und im Moduldevice der set Befehl sunriseTimeWeHoliday.
Wenn sunriseTimeWeHoliday auf on steht und man das Attribut AutoShuttersControl_Time_Up_WE_Holiday am Rolladen ändert, wird automatisch der neue Timer gesetzt.
In der Wochenendsteuerung ist auch we2holiday mit enthalten. Extra Kalender folgen noch.

[MarkusHiba]

Hey,

Wiki aktualisiert.
Könnt ihr mir sagen was ich bei den Tabellen Datentyp/Wertebereich (z.B. HH:MM:SS) und Default-Wert (Werte die vom Modul vorgegeben sind) noch eintragen soll ?
Oder fehlt noch etwas.

Grüße

Markus