Betatester für neues Modul AutoShuttersControl gesucht!

[CoolTux]

ok.
Steht im Moduldevice für die beiden Rolläden ein $NAME_lastDelayPosValue drin? Mit der Uhrzeit wo sie heute morgen hätten fahren sollen?

[Beta-User]

Nein, es stehen dort (in den Rolladen-Devices) jeweils nur 2 ASC-Readings für die Morgens- und Abends-Zeiten. Auch im ASC-Modul-Device ist nichts spezielles zu erkennen, auch jeweils nur 2 Readings (lastPosValue und nextAstroTimeEvent).

[CoolTux]

Ok dann muß ich das mal simulieren. Bin gerade etwas ratlos.

[CoolTux]

Ich hänge etwas beim Urlaubskalender. Wenn ich beim letzten erstellen der Timer vor dem nächsten Sonnenaufgang (also Abends) abfrage ob Urlaub ist oder nicht, passt es für den ersten Urlaubstag nicht denn Abends ist noch nicht Urlaub, erst Mitternacht.
Alternative, ich setzte Abends den normalen Timer und morgens bei der Ausführung prüfe ich ob Urlaubstag ist und stelle den Timer dann zur Not neu. Aber bis dahin wird einem eine andere Zeit angezeigt.

Weitere Überlegungen?

[Beta-User]

An sich würde mich eine Prüfung zum Ausführungszeitpunkt nicht stören, aber gleich direkt die richtige Zeit anzuzeigen, ist natürlich schicker .

holiday-Devices kennen den morgigen Status (Reading "tomorrow"). Könnte man bequem verwenden, hat aber den Nachteil dass man das für mehrere Devices zulassen sollte (ich nutze neuerdings 2, die in global über holiday2we eingebunden sind; könnte man auch darüber (Umweg über Abfrage des Attributs an global) abfackeln).
Vielleicht sollte/kann man es an Urlaubs-Devices auch berücksichtigen, wenn es ein "tomorrow"-Reading gibt?

Sehe das aber eher als Ergänzung an, denn $we+Urlaubs-Gerät sollte m.E. in jedem Fall auch zum Ausführungszeitpunkt geprüft werden, sonst sind m.E. Irritationen von Leuten vorprogrammiert, die die Zusammenhänge nicht kennen. Und an einen Dummy ein tomorrow-Reading zu bekommen, ist zwar nicht schwer, aber auch nicht "Standard".

[Cluni]

Das und die Zeitumstellung war bei mir der Grund, warum ich die Berechnung um 3:05Uhr gemacht habe. Ist doch nicht schlimm, wenn die Zeiten für morgens erst in der Nacht gemacht werden!?

Andererseits: Ich habe nicht mehr im Kopf, wie die Prüfung auf Urlaubstag aussieht - könnte man da nicht ggf. die Anfrage für den nächsten Tag stellen?

[kjmEjfu]

Es könnte aber sein, dass jemand an Urlaubstagen früher aufsteht als an normalen Tagen. Denkbar z.B. bei Leuten im Schicht- oder Spätdienst. Wenn der Timer dann erst zum Ausführungszeitpunkt geprüft würde, so wäre dies vermutlich zu spät.

[Cluni]

Oh, das macht dann aber die Prüfung etwas schwieriger. Darf dann natürlich nur auf morgen abgefragt werden, wenn die Aktualisierung zu einem bestimmten Zeitpunkt gemacht wird. Sonst muss ja auch heute abgefragt werden...

EDIT: Das war auf meine Idee bezogen...

[CoolTux]

Eine Tomorrow Prüfung war auch jetzt mein letzter Gedankenansatz und ich denke ich werde ihn beibehalten. Es muß also zwingend ein tomorrow Reading im Urlaubs oder Feiertags Device vorhanden sein.

Zwei Devices können wieder über eine structure abgebildet werden. Dafür ist sie da.

[Beta-User]

An sich fand ich die 3:05-Uhr Variante auch mal ok.

Jetzt würde ich sagen, dass auf jeden Fall nach Ablauf des Spät-Timers die Zeit für den nächsten Tag gleich richtig berechnet (und angezeigt) werden sollte, um kmjEjufu's Einwand zu berücksichtigen. Das erfordert aber dann m.E. eine recht umfangreiche Prüfung vorneweg, es sei denn, man würde schlicht immer den frühesten Termin aus allen Angaben nehmen, dann bei dessen Ablauf die Bedingung ($we) prüfen und ggf. den nächsten setzen.

Für ganz flexibel Lösungen wie sie z.B. für schichtende Menschen erforderlich sind, wäre dann aber vermutlich eine sinnvolle Handhabung der Residents anzuraten - bei asleep findet ja keine Fahrt statt; das kann man über einen ical-Kalender recht gut steuern, ohne immer eine Vielzahl von Attributen zu ändern.

Zwei Devices können wieder über eine structure abgebildet werden. Dafür ist sie da.

Dafür ist m.E. das Attribut in global da, oder etwa nicht? Es macht m.E. keinen Sinn, jeden User für dieselbe Funktionalität eine Sonderlocke bauen zu lassen. Das Modul kann m.E. bequem einmal zu Tagesbeginn (oder bei der ersten erforderlichen Prüfung des Tages) prüfen, ob morgen $we wahr sein wird und ein zusätzlicher optionaler Urlaubs-Dummy ein tomorrow-Reading hat. Eines wahr, alles wahr. Keine Magie, kein zusätzliches Device, super Service .

Just my2ct.

EDIT: ggf. auch mehrere Urlaubs-Dummys mit beliebigen Readingnamen: "Device:Reading,Device2:Readingb,..." Ist eine einfache "foreach" mit einem split.

[kjmEjfu]

Eine Tomorrow Prüfung war auch jetzt mein letzter Gedankenansatz und ich denke ich werde ihn beibehalten. Es muß also zwingend ein tomorrow Reading im Urlaubs oder Feiertags Device vorhanden sein.

Hmm, das würde aber bedeuten, man benötigt auf jeden Fall pro betroffener Person auch ein Urlaubsdevice. Ich glaube, es gibt viele Dinge, für die man das Residents-Modul mal erweitern könnte 

Im Moment steuere ich, Clunis Code, einfach nur das jeweilige Reading über einen Kalender. Dadurch kann ich auch, wenn z.B. ein Kind krank ist und daher daheim bleibt, einfach im Kalender was eintragen und das entsprechende Notify sorgt für eine spätere Rollofahrt.
Das kann ich auch von unterwegs per Handy machen.
Am Holiday-Device was zu ändern, ist etwas umständlicher und hat einen geringeren WAF.

[CoolTux]

Persönlich verstehe ich das mit dem anders fahren am WE oder im Urlaub eh nicht. Zu mindest nicht da wo Schlafräume sind und das wichtig wäre.
Nun habe ich persönlich auch nur Innenrollos. Keine Ahnung ob es wichtig ist das im Wohnzimmer oder der Küche die Rollos am WE bis zur frühsten Fahrzeit für WE unten bleiben und nicht mit dem Sonnenaufgang wie sonst auch immer auf fahren.

Es sollte wenn dann aber sich eh nichts ändern denke ich. Es sollte reichen wenn Du im Kalender den Eintrag machst.

[Cluni]

Ich glaube so ein Außenpanzer ist etwas geräuschintensiver, als ein Innenrollo. Davon darf bei uns zu Hause keiner zu früh hoch gehen... [emoji23] [emoji85] [emoji86]


Gesendet von iPhone mit Tapatalk

[CoolTux]

Ich glaube so ein Außenpanzer ist etwas geräuschintensiver, als ein Innenrollo. Davon darf bei uns zu Hause keiner zu früh hoch gehen... [emoji23] [emoji85] [emoji86]


Gesendet von iPhone mit Tapatalk

Das Argument leuchtet mir ein.
Dann muß nur dafür gesorgt werden das die Kalenderdummys entsprechend mit 0 oder 1 versorgt werden.

[Beta-User]

(wieder mal zu langsam beim tippen, aber da fertig...)

Persönlich verstehe ich das mit dem anders fahren am WE oder im Urlaub eh nicht.

Am WE (bzw. an Feiertagen) hat es etwas damit zu tun, dass Außenrollläden etwas lauter sind als Innenrollos: Man stört die Nachbarn und die noch schlafenden Bewohner einfach per default später. Das ist daher m.E. sinnvoll, insbesondere, wenn man nicht noch eine Ladung Residents generieren will, nur um diese Funktionalität darüber hinzubiegen.

Urlaub: Ist ähnlich, nur dass hier sinnvoller Weise auch noch die Frage des Aufenthaltsorts eine Rolle spielt. Da würde ich also sagen, dass diese Frage auf der Ebene der Residents abgefrühstückt werden sollte. Dass ich das gerne so haben will, dass (lokale Schul-)Ferien wie ein Feiertag zu behandeln sein sollen, ist eine Sonderlocke, die aber von holiday2we ausdrücklich so vorgesehen ist. Jedenfalls sind mehrere holiday-Dateien für holiday2we kein Sonderfall.

Hmm, das würde aber bedeuten, man benötigt auf jeden Fall pro betroffener Person auch ein Urlaubsdevice.

Hmm, ob man das pro Resident braucht? Aber der Gedanke ist jedenfalls nicht ganz von der Hand zu weisen, dass individuelle morgige Besonderheiten berücksichtig werden sollten.
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.

Ich glaube, es gibt viele Dinge, für die man das Residents-Modul mal erweitern könnte 

Jup, z.B. Angaben zur IP des Smartphone und den Telegram-User; darüber versuche ich grade neben den anderen Dingen im Rahmen dieses Tests die Anwesenheit zu steuern bzw. zu manipulieren. Ist aber nicht so ganz trivial, das sehr flexibel zu gestalten...

Am Holiday-Device was zu ändern, ist etwas umständlicher und hat einen geringeren WAF.

Mit holiday-Device war ein holiday nach commandref gemeint, nicht irgendein Dummy. Der ist in der Regel einheitlich pro Bundesland (für Weihnachten,, Ostern usw.) und ändert sich praktisch nie.
Neulich habe ich dann noch ein notify gebastelt, das aus dem ical-Ferienkalender jeden Freitag eine jeweils aktuelle holiday-Datei generiert. Das gilt dann aber für's ganze Haus.

Manuell in diesen Dateien rumzumalen war nie die Intention.

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.