[73_AutoShuttersControl.pm] Rolllos automatisiert steuern - Version 0.6.x

[CoolTux]

Wie kann ich dann erreichen, dass ich für das Rollo im Schlafzimmer auch nach dem aufstehen noch einen Privacy Modus habe für eine gewisse Zeit und die anderen Rollos nach dem aufstehen hochgehen? Ich finde es unlogisch, dass man nur abends seine Privatsphäre braucht

Dann müssen wir schauen das wir da was bauen 

Kannst du nicht mal einen Tagesablauf beschreiben, so wie du ihn dir typischerweise beim programmieren vorgestellt hast? Das würde mir helfen deine Denkweise etwas besser zu verstehen.

Wird nichts bringen. Die meisten Umstzungen wurden auf Anforderung von Usern gemacht. Ich selbst verwende ausschließlich Astro Up Down und Beschattung. Nicht mal Fensterkontakte. Obwohl ich sie eingebunden habe im ASC.

Also ist ASC_Time_Up_WE_Holiday eigentlich ein Ersatz für ASC_Time_Up_Early am Wochenende? Das leuchtet mir irgendwie so gar nicht ein. Was mache ich denn, wenn ich nun doch zu den Wochenzeiten aufwache und entsprechend doch früher aufstehe? Ich muss doch nur den Fall abdecken, dass ich später aufstehe und somit die Zeit, an der der Rollladen spätestens hochgefahren wird, nach hinten schieben. Ich denke nochmal drüber nach, aber so direkt erleuchtet bin ich (noch) nicht 

So ist es. Es war gewünscht das frühstes der Brightnesswert ausgewertet werden soll wenn Holiday erreicht ist.

Wenn ich (zusätzlich) mit einer Markise beschatte, dann ist diese aber nachts eingefahren und soll ausgefahren werden, egal ob ich noch schlafe oder nicht. Da hat es eine höhere Priorität die Wohnung vor noch mehr Wärme zu schützen und es hilft nicht zu warten, bis ich aufgestanden bin _und_ die Astro Zeiten überschritten sind.

Eigentlich wollte ich Dir hier was schreiben bis mir bewusst wurde das Du den ganzen Morgens Abends fahren Schnulli gar nicht brauchst. Du brauchst nur Beschattung.
Das muss ich mir anschauen. In wie weit man da was machen kann. Denke aber eigentlich kannst Du da hart Zeiten in das Rolllo Device eingeben die Bewusst früher und später sind.
Und sagst global er soll aber darauf zum Beispiel Morgens nicht fahren, aber Abends. So fährt sie Abends rein aber Morgens nicht raus. Aber Beschattung sollte dann gehen.

"Nachts sind die Rollos eh unten" stimmt so auch nicht, im Gegenteil: Wenn es richtig warm ist, dann ist das Fenster weit offen und steht auf ComfortPosition, damit die Luft richtig gut durchwehen kann. Die Beschattungsposition ist aber viel weiter unten und muss auch unbedingt dann angefahren werden, wenn beschattet werden soll - egal ob da noch wer schläft oder nicht.

Und auch das geht. Setzte einfach die Zeiten entsprechend früh. Die Rolllos fahren dann nicht weil ja die Roommates noch schlafen aber für das Rolllo ist dann schon Tag.

[CoolTux]

Ich muss sagen, dass ich derzeit auch etwas LOST bin, was aufgrund welcher Einstellung wie funktioniert.
Vorhin wurde mein Rollo im Bad (manuell geschlossen) beim automatischen Kippen des Fensters ein Stück hochgefahren und nach wieder schließen ganz geöffnet.
Ich vermute, dass das durch das Comfort auf on im Modul passiert ist. Im Rollo selbst habe ich aber nichts dergleichen definiert und ich dachte, dass geht nur zusammen mit der ComfortOpen_Pos? Das wäre mir auch logischer, da ich das Verhalten eigentlich nicht an jedem Fenster will.
Woher zieht er sich die Fahrposition? Die Doku schweigt sich dazu aus.

Es gibt default Werte welche dann verwendet werden.
Ich habe gerade einmal geschaut. Ich habe das Comfort Open nicht mit dem Attribut ASC_Ventilate_Window_Open verknüpft. Das habe ich nur bei einem twostate Sensor so gemacht.
Soll er denn gar nicht fahren bei einem Fensterevent?

[volschin]

Ventilate hatte ich noch garnicht auf dem Schirm. Mir erschließt sich aber auch der Unterschied zwischen Ventilate und Comfort nicht (weder mit Wiki noch mit Doku).

[Typ1er]

jeweils Nachts:
Ventilate = Fenster auf Kipp (threestate Fensterkontakt)
Comfort = Fenster weit auf  (threestate Fensterkontakt)

[volschin]

Ok, ich habe im Bad einen twostate mit closed und tilted. Da hat dann vermutlich das Ventilate angeschlagen, dass ich aber nicht konfiguriert habe. Da muss ich mal forschen.

[Loredo]

Ok, ich habe im Bad einen twostate mit closed und tilted. Da hat dann vermutlich das Ventilate angeschlagen, dass ich aber nicht konfiguriert habe. Da muss ich mal forschen.

Das solltest du wohl umkonfigurieren. Ich habe früher auch einige Fenster, die ich nur mit einem Sensor versehen hatte und das Fenster immer nur kippe, als "tilted" umgeschrieben. Aber das macht logisch gesehen keinen Sinn, weil es eben auch bei "open" dann als "tilted" dort stehen würde, es aber dann eben "open" ist. Wenn man nicht zwischen "titled" und "open" unterscheiden kann - sprich einen twostate Sensor hat - dann macht es keinen Sinn so zu tun als ob. Es ist dann besser davon auszugehen, dass das Fenster komplett offen ist, auch wenn es das vielleicht nicht ist. Wenn man diese Unterscheidung wirklich haben will, dann muss man eben einen zweiten Sensor montieren und sich über ein structure einen threestate Sensor daraus bauen (so mache ich das bei meinen Fenstertüren). Für die Darstellung in FHEMWEB kann man ja für "open" trotzdem ein gekipptes Symbol nehmen, wenn es einem darum geht. Die Amis kennen mit ihren ganzen Assistenten eh kein threestate, für die gibt es nur schwarz oder weiß (und ja, sie staunen immer welch tolle Technik die auf dem alten Kontinent so haben, wenn sie hier sind *fgg*).

[volschin]

Bei mir ist das nur ein virtueller HM-Sensor, da ich am Fenster eine WinMatic habe. Den virtuellen Sensor brauche ich auch für die Heizung.

[Loredo]

ASC_autoAstroModeEveningHorizon
Kannst du entfernen, du verwendest ASC_autoAstroModeEvening mit Wert HORIZON doch gar nicht.

Schon richtig, aber dann sollte es doch auch nicht greifen und man kann es einfach lassen?

Wenn du frühs mit Brightness arbeitest und Holiday aktiv ist muss die Zeit für Holiday vor der Zeit von UpLate stehen. Sonst funktioniert es nicht.

Ich bin wirklich verwirrt, weshalb nicht allein "Brightness" den Unterschied zwischen Tag/Nacht bestimmt und Astro da überhaupt noch was zu sagen hat. Außer eben, wenn ich trotz Tag noch ein klein wenig später fahren will. Irgendwie wird da kein Schuh draus. Ich habe jetzt mal sämtliche Early/Late und Holiday Attribute gelöscht und auf Standard gesetzt in der Hoffnung, dass sich dann einfach alles so verhält wie gewünscht. Mich irritiert irgendwie, dass man das nicht mit Prioritäten miteinander verknüpfen kann, es erscheint mir ziemlich starr. Ich kann aber auch nicht genau sagen, was ich anders wollen würde, weil mir die Gesamtlogik noch immer nicht klar ist. Klar hast du immer nur einzelne Anforderungen umgesetzt, die du selbst nie hattest. Irgendwie spielen die einzelnen Anforderungen aber nicht logisch zusammen (für mich). Ich würds ja so gerne verstehen und auch Vorschläge machen, wie man dann alle Use Cases sinnvoll verknüpft - dafür muss ich aber erstmal verstehen, was da ist und wie es interagiert. Schwierig, auch weil es so schwer nachzustellen ist :-/ Ich muss wohl mal ein Testsystem aufsetzen, wo ich per Systemzeit andere Tageszeiten habe. Aber immer die Schaltzeiten dann noch so zu setzen ist halt auch schwer. Verstehe daher auch, dass es für dich auch nicht so einfach ist das zu programmieren und zu testen. Zumal irgendwie alle ein anderes Verständnis und dann auch andere Anforderungen haben. Aber zumindest zum selben Verständnis sollten wir kommen, dann klappt der Rest auch besser

Entweder Du entfernst im ASC brightnesUpDown da Du ja diese Werte auch in den Rolllos drin hast oder du löscht die Werte aus den Rolllos. Aber nur die Werte. Also 350:270. Sonst wäre es doppelt. Stört nicht ist aber unsinnig.

Also so wie ich das im Log gelesen habe, brauchte ich die Helligkeitswerte auch in den Rollo Devices, weil die Brightness sonst immer 0 war. Dann ist mir aufgefallen, dass in der commandRef die Werte für ASC_BrightnessSensor auch nicht als optional ausgewiesen sind, weshalb ich sie hinzugefügt hatte. Danach war im Debug Log auch der Brightness Wert nicht mehr 0.

Aber nochmal: Selbst wenn es keinen Sinn macht etwas doppelt zu konfigurieren, warum stellt das eine Gefahr für die Programmlogik dar? Wenn du mir das hier so schreibst denke ich halt sofort, dass da was in der Logik nicht passen könnte. Ich finde mich aber nach wie vor nicht im Code zurecht und tue mich schwer das selbst nachzuschauen.

AntiFreez Pos kann weg da du ja hart eingestellt hast. Da bewegt sich eh nichts.

Hm, schön wäre eigentlich, wenn man die Bediensperre setzen könnte, er aber trotzdem vorher noch ein letztes Mal auf die Freeze Position fahren würde.
Auch hier verstehe ich wohl den ursprünglichen Use Case nicht. Bei mir wollte ich eben bei der Markise erreichen, dass sie nicht mehr bedient werden kann, aber für den Fall, dass sie noch nicht eingefahren ist, sollte sie zuvor noch eingefahren werden.

Dann müssen wir schauen das wir da was bauen 

Ja, wäre schon toll. Aber irgendwie muss erstmal das grundsätzliche laufen, vorher bringt das ja auch alles nix es noch komplizierter zu machen. Irgendwie will man (ich) aber auch gleich alle Funktionen auf einmal nutzen und nicht nur so halb - ein Teufelskreis. 

Wird nichts bringen. Die meisten Umstzungen wurden auf Anforderung von Usern gemacht. Ich selbst verwende ausschließlich Astro Up Down und Beschattung. Nicht mal Fensterkontakte. Obwohl ich sie eingebunden habe im ASC.

Das verstehe ich. Irgendwie ist es aber dann doof, dass man die ursprüngliche Anforderung nicht so leicht nachlesen kann. Die ganzen Threads einzeln durchzugehen ist sehr mühselig und ob es was fürs Verständnis bringt ist dann auch ungewiss. Hättest du Anforderer mal verpflichten sollen nur gegen Doku was zu implementieren - nun sind sie auf und davon und updaten wahrscheinlich das Modul auf ewig auch nicht, weil ihre kleine Welt nun in Ordnung ist, hahaha 

So ist es. Es war gewünscht das frühstes der Brightnesswert ausgewertet werden soll wenn Holiday erreicht ist.

Komischer Ansatz 
Ohne auch "Late" nach hinten zu verlegen macht das für mich irgendwie nicht viel Sinn. Der Anforderer war gewiss kein richtiger Spätaufsteher, sondern eine Lärche, die sich 'ne Stunde mehr Schlaf gönnt, hihi 

Eigentlich wollte ich Dir hier was schreiben bis mir bewusst wurde das Du den ganzen Morgens Abends fahren Schnulli gar nicht brauchst. Du brauchst nur Beschattung.Das muss ich mir anschauen. In wie weit man da was machen kann. Denke aber eigentlich kannst Du da hart Zeiten in das Rolllo Device eingeben die Bewusst früher und später sind.Und sagst global er soll aber darauf zum Beispiel Morgens nicht fahren, aber Abends. So fährt sie Abends rein aber Morgens nicht raus. Aber Beschattung sollte dann gehen.

Im Grunde brauche ich nur Beschattung, ja. Aber die Crux ist, dass die Beschattung abends zumindest im Falle der Markise nicht zwangsläufig mit Sonnenuntergang beendet sein muss bzw. die Markise eigentlich noch solange ausgefahren bleiben kann, bis ich den Tag für beendet erkläre (Late Werte?) oder ich die Balkontür nicht mehr voll geöffnet habe. Hintergrund ist, dass eine Markise nicht nur zur Beschattung dient, sondern abends auch ein wohligeres Gefühl draußen gibt und auch die Wärme ein klein wenig hält, falls es ansonsten draußen schon kühler wäre.

Die Angabe von Zeiten ist auch so eine Sache. Du hattest mir ja gesagt, dass ich an der Logik "Pos_Down" ist ausgefahren, "Pos_Up" ist eingefahren, nichts ändern darf. Nun ist aber in der Logik gleichzeitig verankert, dass mit "Up_Late" erst der Tag beginnt, aber bei der Markise mit der "Up Fahrt" eigentlich der Tag aufhört und nicht beginnt. Das meinte ich damit, dass bei einer Markise die Logik, dass man nachts runter (sprich raus) fährt und tagsüber hoch (sprich rein), genau umgekehrt ist. So wie du die Markise von mir gesehen hast, habe ich die Up Zeiten vom morgen in den Abend verlegt. Das hat aber zur Folge, dass die Markise den ganzen Tag denkt es wäre noch (Astro)Nacht und deshalb erst gar nicht fährt und auch nicht beschattet. Das ist ein Dilemma :-/
Hoffe ich habe das soweit richtig analysiert.

Und auch das geht. Setzte einfach die Zeiten entsprechend früh. Die Rolllos fahren dann nicht weil ja die Roommates noch schlafen aber für das Rolllo ist dann schon Tag.

Ok, ja wenn man sich auf den Roommate Status verlässt, dann geht das so.
Aber nur mal theoretisch angenommen, dass ich vergessen habe den Roommate auf schlafen zu stellen, dann werde ich morgens mit Sonnenaufgang von einem hochfahrenden Rollo geweckt - sehr doof als Spätaufsteher 
Deshalb wollte ich hier eigentlich gerne einen doppelten Boden haben. Wenn der Roommate auf asleep war und nach awoken/home geht, dann ist alles gut. Wenn der Roommate aber zum Sonnenaufgang noch "home" vom Vortag ist, dann ist es keine gute Idee einfach so die Rollläden zu öffnen. Das kann ich dann mit setzen der Zeiten abfangen, aber wie gesagt, dann funktioniert es nicht mehr gescheit, wenn der Roommate doch auf asleep war und nach dem aufstehen die Rollläden außer im Schlafzimmer hochgehen sollen.

[CoolTux]

Schon richtig, aber dann sollte es doch auch nicht greifen und man kann es einfach lassen?

Ja kann man. Stört auch nicht

Ich bin wirklich verwirrt, weshalb nicht allein "Brightness" den Unterschied zwischen Tag/Nacht bestimmt und Astro da überhaupt noch was zu sagen hat. Außer eben, wenn ich trotz Tag noch ein klein wenig später fahren will. Irgendwie wird da kein Schuh draus. Ich habe jetzt mal sämtliche Early/Late und Holiday Attribute gelöscht und auf Standard gesetzt in der Hoffnung, dass sich dann einfach alles so verhält wie gewünscht. Mich irritiert irgendwie, dass man das nicht mit Prioritäten miteinander verknüpfen kann, es erscheint mir ziemlich starr. Ich kann aber auch nicht genau sagen, was ich anders wollen würde, weil mir die Gesamtlogik noch immer nicht klar ist. Klar hast du immer nur einzelne Anforderungen umgesetzt, die du selbst nie hattest. Irgendwie spielen die einzelnen Anforderungen aber nicht logisch zusammen (für mich). Ich würds ja so gerne verstehen und auch Vorschläge machen, wie man dann alle Use Cases sinnvoll verknüpft - dafür muss ich aber erstmal verstehen, was da ist und wie es interagiert. Schwierig, auch weil es so schwer nachzustellen ist :-/ Ich muss wohl mal ein Testsystem aufsetzen, wo ich per Systemzeit andere Tageszeiten habe. Aber immer die Schaltzeiten dann noch so zu setzen ist halt auch schwer. Verstehe daher auch, dass es für dich auch nicht so einfach ist das zu programmieren und zu testen. Zumal irgendwie alle ein anderes Verständnis und dann auch andere Anforderungen haben. Aber zumindest zum selben Verständnis sollten wir kommen, dann klappt der Rest auch besser

Alleine nur durch die Brightness Angaben zu fahren empfand ich als un-effektiv. Was ist wenn wegen Sonnenfinsternis oder sehr dunklen Wolken am Tag mal der Schwellwert unterschritten wird. Daher wollte ich Zeitgrenzen setzen und empfand die Idee die vorhanden Attribute für Zeitangaben zu verwenden ganz gut.

Also so wie ich das im Log gelesen habe, brauchte ich die Helligkeitswerte auch in den Rollo Devices, weil die Brightness sonst immer 0 war. Dann ist mir aufgefallen, dass in der commandRef die Werte für ASC_BrightnessSensor auch nicht als optional ausgewiesen sind, weshalb ich sie hinzugefügt hatte. Danach war im Debug Log auch der Brightness Wert nicht mehr 0.

Aber nochmal: Selbst wenn es keinen Sinn macht etwas doppelt zu konfigurieren, warum stellt das eine Gefahr für die Programmlogik dar? Wenn du mir das hier so schreibst denke ich halt sofort, dass da was in der Logik nicht passen könnte. Ich finde mich aber nach wie vor nicht im Code zurecht und tue mich schwer das selbst nachzuschauen.

Es stellt keine Gefahr da, ist halt nur doppelt. Und wenn es nicht funktioniert mit Brightness Schwellen nur im ASC Device dann ist da noch ein Fehler drin

Hm, schön wäre eigentlich, wenn man die Bediensperre setzen könnte, er aber trotzdem vorher noch ein letztes Mal auf die Freeze Position fahren würde.
Auch hier verstehe ich wohl den ursprünglichen Use Case nicht. Bei mir wollte ich eben bei der Markise erreichen, dass sie nicht mehr bedient werden kann, aber für den Fall, dass sie noch nicht eingefahren ist, sollte sie zuvor noch eingefahren werden.

Dann müsstest Du das bitte mit eigenen Mitteln tun, Du weißt ja wie das ist. Jeder hat so seine speziellen Wünsche. Alles kann man nicht abdecken. Dafür ist selbst dieses Modul nicht geschaffen.

Ja, wäre schon toll. Aber irgendwie muss erstmal das grundsätzliche laufen, vorher bringt das ja auch alles nix es noch komplizierter zu machen. Irgendwie will man (ich) aber auch gleich alle Funktionen auf einmal nutzen und nicht nur so halb - ein Teufelskreis. 

Das verstehe ich. Irgendwie ist es aber dann doof, dass man die ursprüngliche Anforderung nicht so leicht nachlesen kann. Die ganzen Threads einzeln durchzugehen ist sehr mühselig und ob es was fürs Verständnis bringt ist dann auch ungewiss. Hättest du Anforderer mal verpflichten sollen nur gegen Doku was zu implementieren - nun sind sie auf und davon und updaten wahrscheinlich das Modul auf ewig auch nicht, weil ihre kleine Welt nun in Ordnung ist, hahaha 

Komischer Ansatz 
Ohne auch "Late" nach hinten zu verlegen macht das für mich irgendwie nicht viel Sinn. Der Anforderer war gewiss kein richtiger Spätaufsteher, sondern eine Lärche, die sich 'ne Stunde mehr Schlaf gönnt, hihi 

Im Grunde brauche ich nur Beschattung, ja. Aber die Crux ist, dass die Beschattung abends zumindest im Falle der Markise nicht zwangsläufig mit Sonnenuntergang beendet sein muss bzw. die Markise eigentlich noch solange ausgefahren bleiben kann, bis ich den Tag für beendet erkläre (Late Werte?) oder ich die Balkontür nicht mehr voll geöffnet habe. Hintergrund ist, dass eine Markise nicht nur zur Beschattung dient, sondern abends auch ein wohligeres Gefühl draußen gibt und auch die Wärme ein klein wenig hält, falls es ansonsten draußen schon kühler wäre.

Die Angabe von Zeiten ist auch so eine Sache. Du hattest mir ja gesagt, dass ich an der Logik "Pos_Down" ist ausgefahren, "Pos_Up" ist eingefahren, nichts ändern darf. Nun ist aber in der Logik gleichzeitig verankert, dass mit "Up_Late" erst der Tag beginnt, aber bei der Markise mit der "Up Fahrt" eigentlich der Tag aufhört und nicht beginnt. Das meinte ich damit, dass bei einer Markise die Logik, dass man nachts runter (sprich raus) fährt und tagsüber hoch (sprich rein), genau umgekehrt ist. So wie du die Markise von mir gesehen hast, habe ich die Up Zeiten vom morgen in den Abend verlegt. Das hat aber zur Folge, dass die Markise den ganzen Tag denkt es wäre noch (Astro)Nacht und deshalb erst gar nicht fährt und auch nicht beschattet. Das ist ein Dilemma :-/
Hoffe ich habe das soweit richtig analysiert.

Ok, ja wenn man sich auf den Roommate Status verlässt, dann geht das so.
Aber nur mal theoretisch angenommen, dass ich vergessen habe den Roommate auf schlafen zu stellen, dann werde ich morgens mit Sonnenaufgang von einem hochfahrenden Rollo geweckt - sehr doof als Spätaufsteher 
Deshalb wollte ich hier eigentlich gerne einen doppelten Boden haben. Wenn der Roommate auf asleep war und nach awoken/home geht, dann ist alles gut. Wenn der Roommate aber zum Sonnenaufgang noch "home" vom Vortag ist, dann ist es keine gute Idee einfach so die Rollläden zu öffnen. Das kann ich dann mit setzen der Zeiten abfangen, aber wie gesagt, dann funktioniert es nicht mehr gescheit, wenn der Roommate doch auf asleep war und nach dem aufstehen die Rollläden außer im Schlafzimmer hochgehen sollen.

Wie gesagt, alles kann und soll das Modul nicht abfangen. Ich finde es schon anstrengend mir Gedanken machen zu müssen  wegen nicht korrekt gesetzten Positionen von Rolllos. Sowas sollte im eigentlichen Rolllo Modul abgefangen werden.
Meine Meinung.

[Loredo]

Noch eine Verständnisfrage:


Wofür genau sind RainProtection und WindProtection gedacht? Bei einer Markise möchte ich natürlich in beiden Fällen, dass sie rein fährt (also zu Up_Pos).


Die ursprüngliche Idee für RainProtection hingegen ist wahrscheinlich, dass man bei Rollläden diese _schließt_ (also zu Down_Pos), WENN ein Fenster offen ist (threestate=open, nicht =tilted). Zumindest fällt mir kein Grund ein, warum ein Rollladen nicht nass werden dürfte. Dass man eine Beschattung bei Regen deaktiviert und der Rollladen dann deswegen hochgefahren wird, steht auf einem anderen Blatt


Bei WindProtection hingegen ist der Use Case bei Markise und Rollo tatsächlich endlich mal identisch: Auch ein Rollo soll dann hochgefahren werden, damit es nicht kaputt geht (ob das nötig ist, kann ja jeder selbst je Rollo einstellen; ich brauchs nur bei der Markise).


Soweit richtig oder liege ich schon wieder daneben?

[CoolTux]

Noch eine Verständnisfrage:


Wofür genau sind RainProtection und WindProtection gedacht? Bei einer Markise möchte ich natürlich in beiden Fällen, dass sie rein fährt (also zu Up_Pos).


Die ursprüngliche Idee für RainProtection hingegen ist wahrscheinlich, dass man bei Rollläden diese _schließt_ (also zu Down_Pos), WENN ein Fenster offen ist (threestate=open, nicht =tilted). Zumindest fällt mir kein Grund ein, warum ein Rollladen nicht nass werden dürfte. Dass man eine Beschattung bei Regen deaktiviert und der Rollladen dann deswegen hochgefahren wird, steht auf einem anderen Blatt


Bei WindProtection hingegen ist der Use Case bei Markise und Rollo tatsächlich endlich mal identisch: Auch ein Rollo soll dann hochgefahren werden, damit es nicht kaputt geht (ob das nötig ist, kann ja jeder selbst je Rollo einstellen; ich brauchs nur bei der Markise).


Soweit richtig oder liege ich schon wieder daneben?

Damit setzt man die Protection in oder off. Default ist on, aber es gibt auch Leute die einige nicht vor Regen schützen wollen.

[Loredo]

Damit setzt man die Protection in oder off. Default ist on, aber es gibt auch Leute die einige nicht vor Regen schützen wollen.

Diese Antwort verstehe ich nicht. Es gibt Leute, die eine Markise nicht vor Regen schützen wollen und sie dafür nicht einfahren, sondern eher noch ausfahren wollen?

[CoolTux]

Du machst da den selben Fehler wie ich.
Du denkst nur an Deine Markise. Die meisten machen aber Rolllos. Hihi.
Es gibt also Leute die einige Rolllos nicht schützen wollen/müssen.

[Loredo]

Nee, ich versuche gerade den Rollo Use Case zu verstehen um dann ableiten zu können, ob das so direkt für die Markise auch passt oder eben nicht.
Meine Vermutung ist, dass es nicht passt, aber dafür brauche ich erst die Bestätigung oder Verneinung, ob ich den Rollo Use Case überhaupt erstmal richtig verstanden habe.


Ich will verstehen, in welche Richtung das Rollo bei RainProtection gefahren wird - hoch oder runter? Und nur bei Fenster auf oder ist das egal?

[CoolTux]

Er fährt dann in die ClosedPosition