[73_AutoShuttersControl.pm] Neues Modul zum automatisierten steuern von Rolläden

[CoolTux]

Hallo CoolTux,

ich fahre meine Rollos gerade ASC_autoAstroModeEvening CIVIL das bedeutet für heute 17:58Uhr runter fahren.

Das ist meiner Frau zu spät es ist schon richtig dunkel draußen bei dem Wetter. REAL wäre 17:21Uhr das ist zu früh *grml*

Gibt es eine Möglichkeit für einen offset? Oder habe ich eine Funktion übersehen die das "Wetter" also die Bewölkung mit einbezieht bei der Zeitberechnung?

Hallo Tim,

Ein einbeziehen von Bewölkung gibt es nicht. Du kannst HORIZON nehmen und Dich dann mit den ASC_autoAstroModeMorningHorizon versuchen ran zu tasten an den Wert der Euch gefällt.


Grüße

[CoolTux]

Was mir noch ganz verrückt ein fallt. Du lässt ASC_autoAstroModeEvening CIVIL und probierst dann mit dem Privacy Attributen zu arbeiten. Dann machst die privacyPos entweder 60 oder 70 Prozent oder halt eben ganze 100 Prozent.

[CoolTux]

Noch mal ein zwei Worte zum Thema Dokumentation. Ich denke im Wiki wären Anwendungsbeispiele ganz gut aufgehoben.
Gerade die Sache mit dem Privacy. Wozu kann man es verwenden?
Dann auch SelfDefense. Das bei einem absent nur da die Rollläden geschlossen werden wo das Fenster vergessen wurde zu schließen.
Beim wechsel in gone wird nur an den makierten Terassentüren der Rollladen runter gefahren.


Grüße

[majestro84]

Ich kann gerne ein Beispiel für privacy schreiben.
Vielleicht schaffe ich es heute Abend.
Gruß Alex

[JHo]

Ein einbeziehen von Bewölkung gibt es nicht. Du kannst HORIZON nehmen und Dich dann mit den ASC_autoAstroModeMorningHorizon versuchen ran zu tasten an den Wert der Euch gefällt.

Wäre auch meine Frage gewesen, um hier etwas freier definierbar agieren zu können. Astro oder Twilight, und eben welches Reading genommen wird als Freitext, wie beim Fenstersensor.

Fenstersensor ist meine eigentliche Frage: welches Reading mit welchen Status wird hier vorausgesetzt? Mein Testfenster mit Max! (State opened / closed) bewirkt nichts...

Grüße,
Jan

[CoolTux]

Wäre auch meine Frage gewesen, um hier etwas freier definierbar agieren zu können. Astro oder Twilight, und eben welches Reading genommen wird als Freitext, wie beim Fenstersensor.

Fenstersensor ist meine eigentliche Frage: welches Reading mit welchen Status wird hier vorausgesetzt? Mein Testfenster mit Max! (State opened / closed) bewirkt nichts...

Grüße,
Jan

STATE mit open und closed

Hier könnte ein Eventmapping helfen.

[Beta-User]

Noch mal ein zwei Worte zum Thema Dokumentation. Ich denke im Wiki wären Anwendungsbeispiele ganz gut aufgehoben.

Hmm, wenn ich dazu komme, kommt demnächst mal eine Wiki-Überarbeitung.

Orientieren würde ich mich an meinem gestrigen Post als eine Art Einrichtungsleitfaden. Wenn da jemand andere Ideen für die Strukturierung hat: Her damit .

Dabei werden dann vermutlich gewisse Leerstellen bleiben, die dann aufzufüllen wären.

Leider muss ich alle Attribute in den Rollläden mit default Werten setzten, da ich ansonsten keine Attribute verteilt bekommen habe. Kann mich erinnern da ganz am Anfang Probleme mit gehabt zu haben.

Ok, das leuchtet ein, auch wenn mir das Ergebnis nicht gefällt. So ist es - jedenfalls in meiner Wahrnehmung - erst mal ein ziemlicher "Attribut-Overkill"; es sind 51 (!) Attribute, wenn ich richtig gezählt habe. Leider fällt mir auch nichts ein, um dieses "das erschlägt einen ja"-Gefühl zu verhindern; alles, was mir dazu auf die Schnelle einfällt (stufenweises Ausrollen, z.B. Beschattung nur, wenn auch im Moduldevice aktiv usw., Auslagern in eine eigene Konfigurationsfile, Konfiguration am ASC-Device selbst), wäre auch mit massiven Eingriffen in den code verbunden. Hmm, unbefriedigend, aber kaum zu ändern...

Das mit Device:Reading nun zu ändern wäre glaube zu viel des guten. Ich könnte es schnell ändern im Code aber dann müssten alle Attribute angepasst werden.

Das ist mir klar. Wäre eine Frage in die Runde, ob das - im Interesse zukünftiger Einsteiger - akzeptabel wäre? Leider sind wir sehr schnell von Test in Produktiv, sonst müßten die Tester-User das halt akzeptieren. Alleine das mit Device:Reading wären 3 Attribute weniger.
Ich würde aber angesichts der schieren Masse ggf. aber gleich weiter gehen. So könnte man m.E. auch die AutoAstroModes zusammenfassen: "Morning/Generell[:Horizon Evening:Horizon]". Wäre nicht mehr so einfach per ReadingsGroup zu ändern, aber m.E. ist das auch eher eine sehr statische Sache, anders als z.B. Zeiten.
Noch statischer ist die Direction, auch hier würde ein Attribut mit optionalen Winkelangaben nach links und rechts reichen.
Ähnliches gilt für die Mode_Up/Mode_Down-Sache: Da würde ich auch unterstellen, dass kaum ein User hier die Logik unterschiedlich gestalten will, und wenn, könnte man es über eine zweite Angabe ermöglichen.
Überschlägig betrachtet, könnte man so wenigstens 10-15 Attribute "einsparen".

Btw.: Bei einigen "before"-Attributen fehlt ein "e". Ist nur ein Schönheitsfehler, aber auch den könnte man in dem Zuge bereinigen.

Wind fehlt in der Tat nocht, sollte aber relativ einfach ein zu bauen gehen. Schaue ich mir gerne in nächster Zeit an.

Das wäre super, aber dann nochmal mind. ein Attribut mehr...

Um es gleich vorweg zu sagen. ASC_brightnessMinVal und ASC_brightnessMaxVal haben mit der Beschattung gar nichts zu tun.
Das Astro oder Twilight Modul (je nach dem welches als erstes gefunden wird bei einer automatischen Suche) wird verwendet um die Sonnenposition zu erkennen.
Azimut und Elevation. Der eigentliche Trigger ist aber in der Tat Brightness. Nur wenn sich der Brightness Wert ändert werden Azimut, Elevation, Temperatur und die Ein und Ausfallswinkel Ausgelesen und/oder Berechnet und basierend auf diesen Werten entschieden ob shading in oder shading out.

Ok, also sind die beiden brightness-Attribute nur erforderlich/bzw. werden nur verwendet, wenn morgens oder abends nach brightness gefahren wird. (tbd: in Doku klarstellen)

Hmm, das mit der Sonnenposition ist jetzt irgendwie auch unspezifisch. Im Moment habe ich kein Astro- oder Twilight-Modul definiert. Ich gehe mal davon aus, dass ASC nicht im Hintergrund einfach irgendein anderes Modul läd. Ergo kann die Beschattung nicht funktionieren, oder? Also ist Vorbedingung für die Beschattung: Definiere eines der beiden. Mache ich daher bei Gelegenheit (Astro, das scheint genauer zu sein und hat keine (abschaltbare, ist klar) Abhängigkeit zu yahoo).

Hier geht es nur darum [...]

Thx, das kommt dann bei Gelegenheit in die Doku, ggf. dann wenn ich das eine oder andere auch angetestet habe .

Was Telco angeht: gerne...
Insbesondere würde mich interessieren, wie andere das mit den vielen Attributen beurteilen. Ist schon klar, dass man sich eigentlich nur einmalig da durchwursteln muß, aber ich habe eine grundsätzliche Abneigung gegen Module, die einen mit einer Unzahl von Einstellmöglichkeiten erschlagen, ohne einen roten Faden zu liefern, wie. (Der fehlt mir z.B. auch bei der REDIDENTS-Familie, da mache ich lieber ein paar Dummys, die ich sonst auch eher meide...).

[dk3572]

Hallo CoolTux,

du hattest eine angepasste Datei hier zum Download bereitgestellt.
Wie sehe ich ob diese Anpassungen mit in ein Update eingeflossen sind?
Ich hatte nämlich ASC vom Update ausgeschlossen.

Danke und VG
Dieter

[CoolTux]

Gute Frage. Müsste glaube 0.4.0.3 sein die hier angehängt ist. Also bitte mal das Internal VERSION anschauen.

[dk3572]

Ich habe Version 0.4.0.3.
Das ist die von dir hier im Forum angehängte.
Die Frage ist ja, ob du die Änderungen schon in das Update mit übernommen hast.

[CoolTux]

Sorry. Nein habe ich noch nicht 

[Beta-User]

3. Schritt:
Festlegen der Fensterkontakte
Von der Einrichtung her nachvollziehbar; unklar ist mir noch, ob auf meine Three-state richtig reagiert wird - habe das mit der neuen Version bisher nur bewußt im Schlafzimmer getestet, da ging der Rollladen beim Fenster-auf nicht hoch; kann aber auch am Status das Roommate-Devices gelegen haben. Muß ich selbst noch testen.

So, kurzer update dazu: Bei den Threestate wird scheinbar nur auf tilted reagiert. Hat das einen tieferen Grund?
Im Prinzip ist meine persönliche Erwartung: Ich mache _irgendwie_ das Fenster auf, daher soll der Rollladen auch nach oben (wir haben hier ein paar spezielle Beschläge, da stimmt auch das mit tilted/open teilweise nicht ganz...).

Wunsch wäre, dass hier beide Events berücksichtigt werden. Einwände oder bereits anderweitig ausdiskutiert?

[dk3572]

Ok, danke, dann lasse ich es weiterhin vom Update ausgeschlossen.
Kurze Info wäre sehr nett 
Danke und schönen Abend noch.
Dieter

[CoolTux]

So, kurzer update dazu: Bei den Threestate wird scheinbar nur auf tilted reagiert. Hat das einen tieferen Grund?
Im Prinzip ist meine persönliche Erwartung: Ich mache _irgendwie_ das Fenster auf, daher soll der Rollladen auch nach oben (wir haben hier ein paar spezielle Beschläge, da stimmt auch das mit tilted/open teilweise nicht ganz...).

Wunsch wäre, dass hier beide Events berücksichtigt werden. Einwände oder bereits anderweitig ausdiskutiert?

Das sollte auch funktionieren. Dazu muss das Attribut
ASC_autoShuttersControlComfort
im ASC on sein.


Grüße

[CoolTux]

Wäre auch meine Frage gewesen, um hier etwas freier definierbar agieren zu können. Astro oder Twilight, und eben welches Reading genommen wird als Freitext, wie beim Fenstersensor.

Fenstersensor ist meine eigentliche Frage: welches Reading mit welchen Status wird hier vorausgesetzt? Mein Testfenster mit Max! (State opened / closed) bewirkt nichts...

Grüße,
Jan

ASC Unterstützt nun auch Fensterkontakte von Max mit opened und closed im STATE