AutoShuttersControl: Privacy morgens beim Aufstehen

Begonnen von cbl, 27 Juni 2020, 13:58:06

Vorheriges Thema - Nächstes Thema

cbl

Hallo,

ich bereite gerade (endlich) den Umstieg auf AutoShuttersControl vor. Das Modul ist großartig und macht die ganze Rolladensteuerung wesentlich übersichtlicher als meine bisherige Bastelei mit verschiedenen DOIFs. Aktuell lasse ich anstelle der richtigen Rollos noch Dummies "fahren". Sobald alles wie gewünscht funktioniert, werde ich die dann durch die richtigen Aktoren ersetzen.

Eine Funktion, die für den WAF sehr wichtig ist, fehlt noch. Dafür habe ich im Modul bislang keine Lösung gefunden:
Wenn wir morgens aufstehen (in der Sprache von ASC zwischen ASC_Time_Up_Early und ASC_Time_Up_Late), fahren aktuell die Rolladen im Erdgeschoss auf eine Lamellenposition (70%), so dass ein wenig Tageslicht von außen reinkommt und man im Sommerhalbjahr kein Licht benötigt.

Im Modul habe ich bislang nur ASC_Privacy* gefunden, womit man fixe Werte vor/nach dem Öffnen/Schließen angeben kann. Eine Abhängigkeit von anderen Sensoren gibt es hier bislang nicht, oder? Oder hat jemand schon ähnliches innerhalb des Moduls hinbekommen?
Ich kann natürlich auch weiterhin zu diesem Zweck mein DOIF weiterverwenden. Für ASC ist das dann wie manuelles Fahren.


Viele Grüße
Christian

CoolTux

Wenn Du Morgens mit Brightness statt Astro fährst kannst Du auch einen Brightnesswert mit an geben.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

cbl

Meine Beschreibung war nicht präzise:
Die Lamellenposition wird getriggert durch unser Aufstehen. Wenn also Bewegung ins Haus kommt (ROOMMATE ist dann "wach"), wird die Privacy Position angefahren. Das ist unabhängig von der Helligkeit.
Würde vorher gefahren, würden mindestens die Kinder von den fahrenden Rollladen geweckt.

CoolTux

Das würde ich einfach weiterhin über eine eigene Steuerung laufen lassen, oder Du könntest eventuell mit dem Attribut ASC_ExternalTrigger arbeiten.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

cbl

Vielen Dank für den Hinweis zu ASC_ExternalTrigger. Das Attribut hatte ich übersehen. Das liest sich so, dass ich das genau für meine Zwecke verwenden muss. Mir ist nur noch nicht der Zusammenhang zu weiteren Fahraufträgen klar. Dominiert ein aktives ASC_ExternalTrigger (also reading-Wert "on") alle anderen Fahraufträge? Oder würde ein morgendlicher Fahrbefehl oder auch ein Beschattungsauftrag, der zeitlich nach dem "On" dieses Triggers kommt, normal ausgeführt.

Noch eine Frage zum externen Steuern, wenn das mit dem ExternalTrigger nicht reicht:
Sehe ich richtig, dass ich dann die Sperre nach manueller Fahrt mit bedacht setzen muss, da diese externe Steuerung dann aus Sicht des Moduls ja auch eine manuelle Fahrt ist? Die Beschreibung im Wiki ist zu "ASC_blockASCDrivesAfterManual" nicht so ganz eindeutig. Bedeutet "...und sich der Rollladen auf eine unbekannte (nicht in den Attributen anderweitig konfigurierte) Position befindet", dass ein manuelles Fahren (z.B. durch meine externe Steuerung) auf eine dem Modul bekannte Position (z.B. die Shading Position) nicht als manuell gewertet wird? Das käme mir hier sehr entgegen.


CoolTux

#5
Sorry, diesmal etwas später.

Ich empfehle es so zu belassen wie Du es aktuell hast, also DOIF, und wir schauen mal irgendwann wie man das sauberer machen kann. Ich finde das ganze auf jeden Fall Sinnvoll.



Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net