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

[CoolTux]

Das muss ich mir noch mal im Code genau anschauen. Ich glaube hier fehlt uns so eine Auswertung ob Tag oder Nacht ist. Ich denke es ist so das egal was ist er den letzten Fahrbefehl der nicht gemacht werden konnte sturr ab arbeitet. Der kann auch noch von vor 3 Tagen gewesen sein. Das sollten wir versuchen besser zu machen. Ich schaue es mir explizit noch mal an.

[CoolTux]

Was mir noch ein fällt. Die Terrassentür war aber nicht offen oder? Sonst hätte der Rolladen da nicht fahren dürfen.

[FunkOdyssey]

Nee. Die Türen waren alle zu. Spielt aber auch keine Rolle, da ich hier keine Sensoren hinterlegt habe.
Ganz normal: morgen hoch / abends nix

[CoolTux]

Aber partyMode war bei diesen Rollladen auf on gestellt? Also das Attribut?
Dann sollten wir versuchen aus zu werten ob hoch oder runter erwünscht ist. Wie gesagt ich denke er macht einfach nur sturr den letzten Fahrbefehl. Da müssen wir noch bisschen was vernünftiges schaffen.

[FunkOdyssey]

Aber partyMode war bei diesen Rollladen auf on gestellt? Also das Attribut?

Ja. Das ist korrekt.

Wie gesagt ich denke er macht einfach nur sturr den letzten Fahrbefehl.

Den letzten?
Bei meinem Problem #1 fuhren die Jalousien runter. Mitten am Tag. Also war es hier der nächste Befehl.
Bei Problem #2 stimmt es mit der "letzten Ausführung".



Ich sehe es gerade im Quellcode (wieder), dass du ja bereits einen Workaround eingebaut hattest. Also Ergebnis der Probleme am Jahresanfang hattest du mit IsDay() versucht, ein paar Bugs zu vermeiden.

[CoolTux]

Ja. Das ist korrekt.
Den letzten?
Bei meinem Problem #1 fuhren die Jalousien runter. Mitten am Tag. Also war es hier der nächste Befehl.
Bei Problem #2 stimmt es mit der "letzten Ausführung".

Den nächsten Befehl gibt es nicht. Er speichert nur einen Fahrbefehl den er nicht abarbeiten kann.

[FunkOdyssey]

Wird diese "Speicherung" eventuell nicht geleert?
Keine Ahnung wie ich mich ausdrücken soll, aber muss man diese Art Cache vielleicht "clearen". (geiler Satz).

Ich hatte den PartyModus ganz sicher seit dem 1.1.2019 nicht mehr aktiv. Und ich sehe keinen Grund wieso die Jalousien am Tag (und außerhalb aller konfigurierten Zeiten) runterfahren.

[CoolTux]

Wird diese "Speicherung" eventuell nicht geleert?
Keine Ahnung wie ich mich ausdrücken soll, aber muss man diese Art Cache vielleicht "clearen". (geiler Satz).

Ich hatte den PartyModus ganz sicher seit dem 1.1.2019 nicht mehr aktiv. Und ich sehe keinen Grund wieso die Jalousien am Tag (und außerhalb aller konfigurierten Zeiten) runterfahren.

Auf jeden Fall muss das überarbeitet werden. Dazu muss ich mir das aber genau anschauen.

[throbin]

Ja es ist Absicht. Ich versuche unnötige Events zu vermeiden. Bisher gab es keinen Anwendungsfall für ein Event. Wir können gerne versuchen es zu ändern und dann einmal schauen was die Auslastung an geht.

Hm, verstehe. Ich würde es jedoch darauf ankommen lassen, eventuell könnte man die Events über ein Attribut (pro Device...) aktivieren. Hilfreich wäre das schon zu sehen, was die Astro-Berechnung für Fahrzeiten ermittelt. Ich kann es dann gerne mal anhand 10 Devices testen. Bis jetzt lasse ich das ganze mit DOIFs auf einem Pi3 laufen, da gibt es keine Performance-Probleme.

[FunkOdyssey]

Auf jeden Fall muss das überarbeitet werden. Dazu muss ich mir das aber genau anschauen.

Gestern hätte ich mir ein Disable wieder gewünscht. 😄
So eine Art Notbremse - außerhalb der ASC=0 Variante. 😊

[CoolTux]

So, nachdem in letzter Zeit andere Dinge in FHEM Vorrang hatten, habe ich neulich nach einiger Zeit "ASC-Abstinenz" dann mal auf die aktuelle Version upgedated.

Orientiert habe ich mich dabei vorrangig am Wiki und der commandref_DE, weil ich das u.a. auch dazu nutzen wollte, die Doku "einsteigerfreundlicher" zu machen.

Dabei sind mir zum einen einige Dinge aufgefallen bzw. noch unklar, manches finde ich auch unnötig bzw. unübersichtlich. Vielleicht könnte man das für zukünftige Einsteiger in das Thema etwas verbessern, daher hab ich alles (neben meinen eigentlichen Fragen) mal aufgeschrieben. Das folgende ist teilweise auch als Gedankenstütze gedacht, daher geht es ggf. etwas durcheinander:

1. Nach dem Anlegen des ASC-Grunddevices und dem Einbinden der einzelnen Rollläden sind an allen beiteiligten Rollläden sehr (sehr!) viele Attribute verteilt.
Mindestens zunächst benötigt man aber nur einen Bruchteil davon bzw. in vielen Fällen kann ASC eigentlich ohne weiteres mit den Defaults betrieben werden.
Anregung:
a) Nur verteilen (also schon mit Inhalt füllen), was für den "Grundbetrieb" wirklich erforderlich ist. Der Rest muß nicht vorbelegt werden, das Modul könnte intern genausogut dieselben Werte nutzen, wenn nichts da ist (und tut es vermultich bereits). M.E. würden im ersten Angang reichen: ASC_Closed_Pos, ASC_Open_Pos, ASC_Time_Down_Early, ASC_Time_Down_Late, ASC_Time_Up_Early, ASC_Time_Up_Late, ASC_Time_Up_WE_Holiday.
Sogar bei den Zeiten könnte es sein, dass man einen Standard zentral festlegen kann, so dass man das an den einzelnen Rollläden evtl. gar nicht bräuchte.

So ist jedenfalls nicht so recht klar, wie das Verhältnis der zentralen Vorgaben zu denen in den Rollläden ist. M.E. wäre es intuitiver zu verstehen, wenn man _grundsätzlich und in allen Fällen_ erst die zentralen Einstellungen vornimmt und dann nur die Abweichungen an den einzelnen Rollläden festlegt.

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.
Die globalen Werte im ASC Device gelten so lange bis Werte für das selbe Attribut in den Rolllädendevices verteilt werden.

b) Es mag uns zwar selbstverständlich vorkommen, was es mit REAL, CIVIL etc. auf sich hat, aber ein kurzer Satz in der Doku, dass mit den Zeitvorgaben und ggf. diesen Angaben iVm. den global-Einstellungen im Hintergrund sunrise_EL bemüht wird und man dort nachsehen sollte, wenn man was zu diesen Parametern sucht, kann eigentlich nicht schaden...
Das immer wieder gerne gefragte Thema "holiday2we" wird in der cref erwähnt (reicht!), im Wiki wäre hier ein etwas längerer Hinweis (auch zur Verwendung eines Dummy mit "tomorrow") evtl. hilfreich.

c) Dass die Schreibweise device[:reading] die Zahl der erforderlichen Attribute reduzieren könnte, traue ich mich kaum mehr zu schreiben, aber ist es wirklich in jedem Fall erforderlich, jeweils extra ein Attribut zu setzen, wenn state verwendet werden soll...

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.

2. Schritt:
Festlegen der Roomates etc.; sollte soweit klar sein, cref ist an sich ok, das Wiki enthält dazu einige weitere Angaben, das ganze ist aber nicht im Sinne einer "Schritt-für-Schritt-Anleitung" ausgeführt: Das mit den Residents (und den Readings) findet sich (nur) im Zusammenhang mit den Voraussetzungen (sollte "man" ergänzen, oder?).

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.

4. Wind
Ähm, bin nicht auf dem letzten Stand, aber sollte das nicht integriert werden? Passende Attribute finde ich aber keine...
(Ich habe hier 4 Außenjalousien, die ich bei unterschiedlichen Windgeschwindigkeiten gerne komplett einfahren würde; im Moment macht das noch ein separates notify).

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

5. Beschattung
Dann wollte ich mich also an den eigentlichen neuen Teil machen, die Beschattung.
Wie die ganzen Attribute ineinandergreifen, steht scheinbar nirgends. M.E. ein dringliches todo.
a) Da finde ich ziemlich zentral ein "ASC_twilightDevice", ohne dass hier irgendwo (cref/Wiki) mehr erläutert wäre, als dass man es irgendwie im Rahmen der Beschattung benötigt. Sehr aufschlußreich... Da es nicht irgendwas mit Brightness heißt, scheint es sich um was anderes zu handeln ("Informationen zum Sonnenstand"). Aber woher werden dann die Helligkeitsschwellen bedient, die man zentral bzw. an den Rollläden einstellen kann? OK, gesehen, das wird wieder (nur) verteilt an allen einzelnen Rollläden festgelegt. Hm, aber warum das? (Ich habe derzeit eigentlich nur einen Lieferanten für Brightness; es würde mir daher ausreichen, wenn der für alle zentral festlegbar wäre).
Daher die Frage zu ASC_twilightDevice: Für was wird es noch verwendet und wie im Rahmen der Beschattung?
Hab's also erst mal weggelassen, zumal das ausnahmsweise keine explizite Angabe eines Readingsnamens vorsah und es auch irgendwie ungut an das aktuell nicht funktionierende "twilight"-Modul anzuknüpfen scheint.

b) Dann habe ich also erst mal die Winkelangaben gemacht. An sich selbsterklärend, aber was mache ich mit den Fenstern auf der Nordseite?
Auf Risiko haben die jetzt also erst mal alle einen Wert in der Nähe von 0, aber immer noch die Varianz von +/- 85°. Paßt das, oder sollte ich das ändern (so dass keine Werte <0° rauskommen können)?!? Oder gar das Attribut bei den Nordfenstern ganz löschen?

c) Ok, dann gibt es eine Reihe weiterer "ASC_Shading.*"-Attribute. Die sind irgendwie vorbelegt, allerdings wäre es vermutlich hilfreich, wenn wir im Wiki ggf. erklären, wie die Werte zu verstehen sind und diese zusammenwirken.

d) Letztlich scheinen die ASC_brightnessMinVal-etc.-Attribute die eigentich entscheidenen Angaben zu sein. Aber wie wirkt das alles jetzt zusammen?
Ein paar erläuternde Worte wären hilfreich, sonst muß ich doch Quellcode lesen oder einfach testen...

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.

6. Sonstiges
Dann gibt's da noch ein paar weitere Features, die zwar in der cref bzw. im Wiki erwähnt sind, deren Bedeutung sich mir aber nicht auf die Schnelle erschließt, so dass ich nicht beurteilen kann, ob und wie ich das anwende (-n will):
a) Privacy: Ist (praktisch) nur in der cref drin.
Möchte jemand ein Anwendungsbeispiel im Wiki ergänzen, damit man besser nachvollziehen kann, was die beiden Attribute bewirken?

Hier geht es nur darum eine bestimmte Zeit vor dem eigentlichen schließen der Rollläden diese schon mal auf sagen wir 50% zu fahren. Ein Anwendungsfall war gewesen das die Rollläden zur Straße hin mit viel Fußgängerverkehr waren und Abends schon vor dem schließen dieser das Licht drin an ging. Somit konnte man gut rein schauen.

b) BlockingTime
In welchem Zusammenhang wirkt sich das jeweils aus, wann sollte/kann man das verwenden?

Das verwendet sich von alleine. Nach einer manuellen Fahrt wird eine vom ASC Modul initiierte Fahrt ausgesetzt. Das geschieht so lange bis die im Attribute angegebene Zeit überschritten ist, eine dann vom ASC Modul initiierte Fahrt wird durchgeführt.
Genau so wird ein hochfahren eines Rollos durch das ASC Modul nicht mehr ausgeführt wenn es innerhalb der Zeit von ASC_BlockingTime_beforNightClose und das runterfahren wird nicht mehr erfolgen wenn es innerhalb von ASC_BlockingTime_beforDayOpen ist.
Beispiel: Meine Tochter geht früh aus Haus und Ihre Rollos sind nicht hoch gefahren. Diese fahren auch nicht mehr hoch da die ausschließlich bei home (anwesend) fahren sollen. Nun kommt sie am Nachmittag um 16:23 Uhr nach Hause, eigentlich sollten nun die Rollos fahren. Doch die Sonnenuntergangsfahrt (schließen) wäre schon 16:51 Uhr und damit innerhalb der 3600 ASC_BlockingTime_beforNightClose. Die Rollos bleiben also unten. Es lohnt sich für die paar Minuten einfach nicht mehr.

c) wiggle
(OK, das ist klar, man kann mit einem "set <ASC-Device> wiggle" alle Rollladen mit einem entsprechenden Attribut zu einer kurzen Fahrt veranlassen. Gehe mal davon aus, dass um den Wert in Richtung closed gefahren wird, und dann nach Ablauf der Minute wieder um denselben Wert zurück.) Steht nur noch nichts im Wiki zu...

Fast. Es wird geschaut wo der Rollladen steht und dann wird in die Richtung gefahren wo er den meisten Weg hat. Wenn also zu 70% geschlossen ist, wird er hoch fahren.


Hoffe ich konnte ein wenig helfen. Wir wollen/müssen eh mal eine Telko/Webinar bezüglich ASC machen.


Grüße

[CoolTux]

Ok das war einfach mit dem nachschauen und ich habe das doch nicht sooo simple gemacht. Er schaut schon noch ein wenig nach wie der Stand der Dinge ist.

Code Auswählen Erweitern


if ( not IsDay( $hash, $shuttersDev )
            and $shutters->getModeDown ne 'off' )
        {
            if ( CheckIfShuttersWindowRecOpen($shuttersDev) == 2
                and $shutters->getSubTyp eq 'threestate' )
            {
                Log3( $name, 4,
"AutoShuttersControl ($name) - EventProcessingPartyMode Fenster offen"
                );
                $shutters->setDelayCmd( $shutters->getClosedPos );
                Log3( $name, 4,
"AutoShuttersControl ($name) - EventProcessingPartyMode - Spring in ShuttersCommandDelaySet"
                );
            }
            else {
                Log3( $name, 4,
"AutoShuttersControl ($name) - EventProcessingPartyMode Fenster nicht offen"
                );
                $shutters->setLastDrive('drive after party mode');
                ShuttersCommandSet(
                    $hash,
                    $shuttersDev,
                    (
                        CheckIfShuttersWindowRecOpen($shuttersDev) == 0
                        ? $shutters->getClosedPos
                        : $shutters->getVentilatePos
                    )
                );
            }
        }
        elsif ( IsDay( $hash, $shuttersDev ) ) {
            $shutters->setLastDrive('drive after party mode');
            ShuttersCommandSet( $hash, $shuttersDev, $shutters->getDelayCmd );
        }


Ich gehe davon aus das bei Dir das hier zugeschlagen hat

Code Auswählen Erweitern


elsif ( IsDay( $hash, $shuttersDev ) ) {
            $shutters->setLastDrive('drive after party mode');
            ShuttersCommandSet( $hash, $shuttersDev, $shutters->getDelayCmd );
        }


Aber dann frage ich mich wieso da noch was im DelayCmd drin war.

Code Auswählen Erweitern


else {
        $shutters->setDriveCmd($posValue);
        $shutters->setDelayCmd('none')
          if ( $shutters->getDelayCmd ne 'none' )
          ; # setzt den Wert auf none da der Rolladen nun gesteuert werden kann.
        $ascDev->setLastPosReading;
        Log3( $name, 4,
"AutoShuttersControl ($name) - ShuttersCommandSet setDriveCmd wird aufgerufen"
        );


Sobald es keinen Grund mehr gibt die Fahrt zu verzögern, wird der Status für die Verzögerung gelöscht.

Code Auswählen Erweitern


$shutters->setDelayCmd('none')
          if ( $shutters->getDelayCmd ne 'none' )


Auf gut Deutsch. Ich habe keine Ahnung woher die Fahrbefehle kommen sollten als Du aus versehen set partyMode off gemacht hast. Werde aber dies in Zukunft abfangen.

[stefanpf]

So, endlich eine unverfälschte Rückmeldung:
Funktioniert alles wie erwartet / es soll 
Vielen Dank noch einmal für die schnelle Hilfe!

Nicht, dass ich es brauchen würde,
aber könnte/müsste nicht konsequenterweise das Upmode Pendant von

Code Auswählen Erweitern

and IsAfterShuttersTimeBlocking( $hash, $shuttersDev )
          and ($shutters->getModeDown eq $homemode
            or (    $shutters->getModeDown eq 'absent'
                and $homemode eq 'gone' )
            or $shutters->getModeDown eq 'always') )


In Der Nähe von Zeile 847 bzw. 859 eingefügt werden?

[CoolTux]

So, endlich eine unverfälschte Rückmeldung:
Funktioniert alles wie erwartet / es soll 
Vielen Dank noch einmal für die schnelle Hilfe!

Nicht, dass ich es brauchen würde,
aber könnte/müsste nicht konsequenterweise das Upmode Pendant von

Code Auswählen Erweitern

and IsAfterShuttersTimeBlocking( $hash, $shuttersDev )
          and ($shutters->getModeDown eq $homemode
            or (    $shutters->getModeDown eq 'absent'
                and $homemode eq 'gone' )
            or $shutters->getModeDown eq 'always') )


In Der Nähe von Zeile 847 bzw. 859 eingefügt werden?

Freut mich das es nun geht.

Was das abfragen vom Upmode an geht. So lange keiner es brauch reden wir nicht darüber 

[HoTi]

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?